September 22, 2006

Quickly: DRAC III/XT and CentOS 4

I administer a server at a colo. This server is a Dell server with a DRAC out-of-band management card. First, the good: the card lets you control power to the server, gives some monitoring I believe, and gives you remote access to the (non-GUI, unless you install their helper software which is basically VNC) console. Finally, it has a remote floppy feature: you can upload a floppy image to the card and it’ll boot off of it. With these sorts of features, the only reason I’d need someone at the colo to touch the box is if I have a hardware failure of some sort—and I can troubleshoot the problem that much easier with ability to see the POST, go into BIOS, and boot diagnostics floppies if I so desired. I’ve already used the remote console/floppy features to upgrade RHEL 3 to CentOS 4 and to move the software from 2 separate disks to software RAID 1.

Now, the bad: fucker is hard to get working. The colocation facility I use had some problems with it in the beginning. Specifically it seems to choose random ports to upload the floppy image with, so their firewall was blocking it. Also, assigning the user name and password to log into the DRAC web interface was apparently a little difficult for them to get right and to integrate with their all-encompassing provisioning (I’ll call it) system.

Furthermore, fucker doesn’t work with Linux. I swear it did at one point in time, but that’s not true today with Firefox 1.5 and Sun Java 1.5 on Fedora Core 5. I couldn’t get it to work in Windows with the same Firefox/Java, either. Of course, the only thing that ended up working was IE (also with Sun Java, oddly). Well, in truth, the first time I tried to load the DRAC remote console (== Java applet that looks like VNC under the hood to me) applet, my XP VM (running in VMware) did a BSOD. It worked fine after a reboot of XP.

But when I say “it doesn’t work with Linux,” it doesn’t just stop there. At this point I’m more murky about whether I’m blaming the DRAC card or Linux, though. (Maybe I should blame both.) First of all, though, let me say this: my server BIOS also has a “console redirection” feature. This is the typical feature you’re used to seeing where it redirects the console out the serial port. The DRAC has nothing to do with this feature, nothing to do with the serial port. Just turn it off (unless you really want to use the serial port; my colo box has nothing hanging off the serial port AFAIK, and certainly nothing I have access to). The DRAC intercepts the video card and keyboard, uh, “subsystems” directly. Somehow.

Aaaanyway, so I boot the system, I see everything I should in the DRAC remote console. I can enter and interact with the BIOS. I can interact with Grub. I can see the kernel booting, see all the init scripts running. But my keystrokes seem to have no effect once the kernel boots. I press enter, nothing happens on the screen. strace and other means of snooping on various ttys shows nothing coming in. This is very strange, since as I mentioned I used the DRAC in the past to good effect.

The problem? It was working in kernel 2.4 (RHEL 3). Turns out, something in kernel 2.6 breaks the DRAC. The solution is to add i8042.dumbkbd=1 to the kernel command line. i8042 is apparently the driver (and probably the chipset) that handles the PS/2 keyboard and mouse communication. I note I didn’t see anything during boot from the kernel that led me to believe it had any problem interacting with the keyboard; I even got the little serio: line saying it found the keyboard. Other people have reported serious input problems with the DRAC and this option but it seems to work great for me.

So is the DRAC a shitty keyboard emulator? Possibly. I’m still of the opinion that they should have made sure the basic peripherals like PS/2 keyboard and PS/2 mouse (see my previous rants about mouse breaking through my KVM) keep working, but (A) that’s a lot of (buggy!) hardware to test with, and (B) it’s free so submit a patch or shut up, I guess.

Final note: research leads me to believe that others have this problem, but for a different reason. I suspect the DRAC 5, and maybe DRAC 4 cards, emulate a USB keyboard. So you need to make sure the USB HID modules get loaded for your DRAC keyboard to work under those circumstances.

Comments (3)

  1. November 19, 2006

    [...] i8042.dumbkbd=1 is necessary on the DRAC as I have explained before. nfsroot tells the kernel first what path to mount (the server IP is given later), then NFS options. Despite nfsroot.txt seeming to say that any option you can give when mounting an NFS mount point normally can be given here, I found at least one that didn’t (mountvers=3; rw is not accepted either, though I don’t think that’s a mount option specific to NFS). Further, when the kernel sees an option it doesn’t recognize, it stops parsing. So make sure it doesn’t bitch about any of your NFS options. (In my case, I had something like …rw,tcp. I always ended up with UDP, until I realized I needed to take rw out.) Note that I’ve forced NFS over TCP, since I’m going to be doing NFS over the Internet. I also left rsize/wsize to 1024 because I’m not terribly concerned about performance. [...]

  2. September 24, 2007

    [...] Also, for people like me on a DRAC III, you’ll want to comment out any bootsplash or hiddenmenu lines, you don’t need any serial console (I commented out both serial and terminal lines for GRUB and also removed console=… parameters to the kernel). You may want to bump up the timeout. Additionally, DRAC III users will need to add i8042.dumbkbd=1 to the kernel “command line.” [...]

  3. May 18, 2012
    Søren K said...

    wow – thanks a lot for the tip! It saved me a 1 hour trip in the middle of the night! :)