Recently, I bought a GuruPlug Plus specifically for use as a router. I wanted to use less watts than a desktop machine, but have a little more power to run applications than on my favorite commercial-router-firmware, Tomato. So when the dual-interface GuruPlugs came out, I bought one.
Lesson one: buy the JTAG board too if you are going to mess around with the kernel, or in any way render the thing unbootable. Unlike its predecessor the SheevaPlug, the GuruPlug does not have debugging built in, so you’ll need to buy the JTAG board to debug the boot process.
Lesson two: The PlugComputer wiki and forums are invaluable. I also used this guy’s notes for help with the Debian setup.
Just spent an hour troubleshooting why I couldn’t SSH into a RHEL 5.4 machine.
Symptoms:
- Can’t SSH in, even as root; login succeeds but before a shell is opened, it exits. Running SSHD in debug mode on the server, the following is printed on the client:
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: