This is irritating...
We've got four new Dell R410 servers at work. Natch, I want 'em working with serial consoles so I don't have to sit in the server room. Three of them worked; the fourth did not, despite having identical BIOS/Grub settings.
The symptom was quite maddening: After getting past the various BIOS checks, the Grub menu would not appear unless you sat there and typed something. After that, you'd get the usual Grub entries and could boot as usual. If you did not hit a key, the machine would just hang -- no response to keypresses at all, and you'd have to power cycle.
I spent a stupid amount of time comparing BIOS and Grub settings but was unable to find anything different. Finally today I typed "grub console timeout serial dell" into Google and found this bug in Launchpad, with this comment as the last one:
Having the same hanging issue at the Grub 1.5 stage on brand new R200 Dell servers running OpenSuse 10.3. The terminal timeout is set to 10 and we get 10 press any key to continue messages and then a full system hang requiring a hard reboot.
If we do press any key on a connected console (using Dell's Serial Over Lan) or locally before then end of the timeout then it boots fine so seems to be a bug in continuing at the end of the wait time.
Removing the terminal line from /boot/grub/menu.1st seems to fix the issue on our servers. The console in this case is sent by BMC to both the local screen and the remote console with no timeout so works a treat. This may only work with Dell's BMC/SOL but thought I'd mention it in case anyone else has spent a day getting frustrated with this like we have.
This worked a treat, with the added bit of weirdness that I had two "terminal" lines:
terminal --timeout=2 serial console
serial --unit=0 --speed=9600
default=0
timeout=5
serial --unit=1 --speed=115200
terminal --timeout=5 serial console
and now I have one:
terminal --timeout=2 serial console
serial --unit=0 --speed=9600
default=0
timeout=5
serial --unit=1 --speed=115200
# terminal --timeout=5 serial console
Yes, I know that's redundant, but again: it worked on the other three machines.
I don't know if this is a problem with Grub, with Dell's firmware or something else, but Gott in himmell I hate bugs like this.
I installed RT at work a couple days ago using pkgsrc. This was the first time I'd ever used pkgsrc, and I have to say I'm impressed. Yes, it's just like a portable ports tree — but it's just like a portable ports tree, and I'm starting to think that's a very, very powerful idea.
RT went well except for the final install, where it complained and died. Fortunately, it turned out to be susceptible to exactly the sort of one-line patch that I have an affinity for. Not as cool as correcting Theo de Raadt's code, mind you :-) but still a good feeling.
Ah...RT, I've missed you.
Arghh. For weeks now, I've been trying to track down why a couple of XP laptops have had random print jobs drop to the floor. I finally got to the point last week where I could reliably duplicate the problem (print four emails from Outlook in quick succession; only three show up, no error on the printer), and today I spent six hours figuring out where the hell the problem was. (I didn't intend to spend that long, but the combination of vociferous complaints and sheer bull-headedness got to me.)
For no particularly good reason, the laptop in question is set to print to the local HP 4200 using IPP. When I looked at the traffic in Ethereal, I noticed that the failing job had a subtly different response to the print job submission from the printer, and at the end the TCP stream was only closed by the laptop -- the printer ACKed right away but did not FIN its end. Aha! Firmware bug!
The printer repair guy who's been working with me to try and fix this stopped by to take a look, and decided to call HP support. Their response: Don't Do That, Then. Apparently, IPP is a weird protocol to use for a LAN and I should really print to port 9100 like everyone else.
Okay, yes, this worked, and it was a stupid amount of time to spend on this problem. But it irritates me that they weren't interested in (what I think is) a firmware bug, and that I'll never probably never get to the bottom of what was going on. Although I'm pretty sure that the JetDirect card just uses an embedded ARM processor; I could just try looking at the firmware with a disassembler...:-)
In other news, something's going subtly wrong with the WRT54G; the
bridging of OpenVPN's tap0 interface and the external ethernet
interface has stopped working. The internal ethernet interface still
works, and if you SSH in that way and run ifconfig vlan0 down ;
ifconfig vlan0 up the external interface starts working again. I'm
also having problems with the wireless interface. I suspect the
bridging may be involved there, too, since it's bridged with the
internal ethernet. However, I only have my wife's iBook to test with,
so I can't be sure it's not a problem with that.
And my OpenBSD 3.9 CDs are in. Hurray! Time to finally get this firewall off my desktop machine.