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.
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:
The UPS in question: a F6B\C900-UNV.
I used to use the Bulldog Plus (3.01.18) software, but since my upgrade of this particular machine to Debian Lenny, the upsd process started taking up 30% CPU all the time.
Getting it to work with nut is easy! You just need the magic.
I’m sick this weekend and don’t feel like writing much, so I’ll be brief. I’ll be doing a fresh install of Debian Squeeze (currently testing), found here, because my old install is getting broken, and I want to write down how I get things working on my Thinkpad R61 this time, both for myself and Google. I have a full-disk backup on my UltraBay hard drive. I’ll be going with the x64 version this time, and will be installing Lenny first, then upgrading, because I already have a Lenny CD, the torrent of the weekly squeeze images is unregistered, jigdo tells me “Aaargh – 0 files could not be downloaded. This should not happen!”, and HTTP goes at 50KB/s. I’ll limit this to Thinkpad-specific things.
Install: No issue. I chose to do it wired rather than load iwlwifi at install time.
Video: worked fine out of the box with the Intel driver.