Dell CS24-SC Remote KVM on Linux

A little less than a year ago I picked up an old Dell CS24-SC 1U server from EBay. It's got a ton of power - dual quad core, 24 GB of RAM, 4 146 GB 15k SAS drives, and an integrated BMC. That last is something I've struggled with though. Because this is a server, I really don't want to leave a keyboard and mouse plugged in to it all the time. Unfortunately, I haven't been able to get the remote KVM functionality working. Until now, that is.

The biggest problem I ran into was that the RKVM Java app provided is 32-bit. Since my desktop is 64-bit, I was having trouble with some of the bundled libraries not loading. This was easily solved by downloading a 32-bit Fedora image and loading it into my local OpenStack installation. I booted it up, installed LXDE, and configured it to boot to graphical mode (you can find instructions on all of those things via the Googles). I also had to install Firefox and IcedTea-Web since this was a minimal cloud image I started with.

With all of that done, I loaded up the VNC console for the instance, fired up the browser, and visited the BMC page. Clicked the remote access button and...another error. Well, shoot.

It turns out that the easiest way to debug problems with this thing is to download the jnlp file that is presented by the BMC and try running it locally with javaws. That will provide console output to help you know what's wrong (the error message dialogs in the application itself are, to put it charitably, worthless). In this case, it turned out I was missing libstdc++.so.5. A little more googling, and I found that I needed to install compat-libstdc++-33 on Fedora to provide that library.

So I tried the jnlp file again...and still failed. Turns out it's a problem to run the jnlp when you aren't logged in to the web console (or something - I didn't spend much time debugging this). I tried again from the web page, running the jnlp directly with IcedTea, and holy cow this isn't completely broken!

One problem remaining - I only had the K of KVM. I could type from the application and have it show up on the server screen, but I had no video or mouse control. Not all that useful. I tried updating the BMC and BIOS using the fantastic files provided by Rob Willis but still no luck (see below for some details on the firmware/BIOS update process). I poked around the user manual included in the firmware update archive and finally ran across some settings in the (strangely enough) Hotkey Setup page of the BMC web interface (see attached image). After clicking both Cursor modes, setting the Video Quality to High, and restarting the RKVM app I had full control.

There's still some weirdness in the Fedora installer because it has mouse acceleration enabled, which the aforementioned manual correctly tells you to disable. It's not a huge deal though - you can still control the mouse fine, it just doesn't line up with your local cursor most of the time. Most importantly to me, you can get into the BIOS remotely. Since I find even the latest BIOS pretty flaky (it likes to re-default to PXE booting first), that's huge.

Getting this working should let me reduce my keyboard count by one and allow me to not leave a spare monitor permanently plugged in to the server. Since there was a lot involved in the process I thought I'd write this up so hopefully someone else can benefit.

BMC firmware and BIOS updating

• The firmware-only download didn't work for me. I got a checksum error when I tried to use it. The file from the full download worked fine.
• The BIOS update feature in the web console didn't work in any way I was comfortable with. Even though it takes a file as input, it still looks for the BIOS ROM on USB/floppy. That didn't seem right, so I passed on updating that way.
• Instead I created a FreeDOS USB stick using unetbootin and copied the BIOS files to it. I booted the USB stick, switched to C:, ran the F.BAT file and everything worked as expected. Edit: I should also note that I made a backup of the BIOS using the AFUDOS tool's /O option: AFUDOS.EXE origbios.rom /O In theory that provides you a recovery scenario in case things go pear-shaped, though I fortunately didn't have to try it. :-)