I recently fought with a StorageTek 2510 for a couple days trying to get it hooked up to a server running RHEL 4 (then 5). I won’t replicate the documentation provided by Sun, or other tutorials but I will tell how I solved the incredibly stupid problem I was having.
I successfully set the array up and presented it to a Solaris 10 host, which was able to see and use it, so I knew the array worked. I moved it to a RHEL 4.8 i386 host (later RHEL 5.5 ×64) and was able to manage it out-of-band with the CAM software, but could not for the life of me get the target discovery to work. Everything was set up just like on the Solaris host, and I did make the required changes on the array for the new host, but I was always presented with:
iscsid: discovery login to 192.168.130.101 rejected: initiator error (02/0b)
The array’s firmware was at the latest, and so was iscsi-initiator-utils. I fiddled with the options in iscsi.conf thinking the spoken protocol just needed to be tweaked, to no avail. I tried telling the array that the data host was Solaris, Windows, even Irix, but that made no difference. I undid and redid my entire configuration. I retested with a Solaris data host – still worked there.
Recently one of my AIX 5.3 systems started failing to boot with the following messages:
fsck: Performing read-only processing does not produce dependable results. + mount /tmp mount: /dev/hd3 on /tmp: Device busy + [ 1 -ne 0 ] + loopled 0x518 /TMP MNT FAILED
The problem turned out to be that /etc/inittab was corrupted. This, of course, has nothing to do with the error message. In my case, the contents of the file had been duplicated into itself.
Another problem I ran into with only obscure search results:
alucard@fileserver:~$ ssh aix04
alucard@aix04's password:
Last unsuccessful login: Fri May 15 15:28:28 EDT 2009 on ssh from fileserver
Last login: Tue Jun 16 10:31:45 EDT 2009 on /dev/pts/0 from fileserver
Could not chdir to home directory /home/alucard: Permission denied
/bin/ksh: Permission denied
Connection to aix04 closed.
The solution in my case was:
chmod a+rx /
/ had permissions 0644 when they need to be 0755 to allow anyone but root to log in.
I just ran into this problem: a Linux machine stuck very shortly after “Decompressing kernel…”, prompting me to enter a runlevel. Problem being that it wasn’t accepting any keyboard input from my USB keyboards and the system doesn’t have a PS/2 port. My Google search didn’t help much, so let me put this out there: check /etc/inittab. In my case, it was a one-line file clobbered by a pre-alpha quality product install. I was booted off of a rescue CD and once I copied /etc/inittab from another Linux system, it booted just fine off of the hard drive. So there you have it – if you’re getting “Enter runlevel” when booting when you’re not supposed to, check the health of /etc/inittab, especially the initdefault line.
id:3:initdefault:
At tape archives, at least.
Someone at Sun has packaged up Sun Studio 12 using GNU tar, leading to pain fun when trying to install on a stock Solaris 10 system. There are many of errors like:
tar: ././@LongLink: typeflag 'L' not recognized, converting to regular file
x ././@LongLink, 116 bytes, 1 tape blocks
x install-sparc-S2/java-sparc-S2/packages/SUNWj5dmo/reloc/jdk/instances/jdk1.5.0/demo/applets/ArcTest, 0 bytes, 0 tape blocks
And then finally:
If you’re a poor chump like myself who needs to install Solaris DiskSuite on Solaris 7 but does not have the install media (Easy Access Server 2.0/3.0), never fear. While DiskSuite 4.1 does not work (it’s for 32-bit Solaris 6), and 4.2.1 from the Solaris 8 disks does not work (not made for Solaris 7!), the version of 4.2.1 you can find on the web does. Make sure to install the 64-bit package as well. And btw – here is the site I used to learn how-to.