One of my client's clients is installing a major upgrade to their accounting system. For some reason I fail to understand, they insist on running it in a VM under VMWare.

So I have this huge HP rack mount server that sounds like a jet engine when it starts up, and like an air conditioner when it's running. It came to me with a VM set up for Linux.

Now Debian Lenny, the Linux we want to use, installs and runs just fine in the VM.

Just fine. Just fine. Just fine.

There's only one tiny problem. We need to use a Digi port server on the network, with Digi RealPort drivers on the server. The tiny problem is that Lenny uses the 2.6.26 kernel - the ONLY kernel revision Digi won't and can't support. RealPort won't compile or run under 2.6.26 because it has a defective tty layer.

So I've always simply compiled the 2.6.28.7 kernel and installed away. So I did that in the VM. Worked slick, Digi compiled, installed and worked. Cool.

...

Except no CDROM drive - udev saw no drive even with the CDROM dedicated to the VM at power-on, so it set up no /dev/hda driver.

It turns out the CDROM drive only works with the installed instance. Even compiling the exact same kernel with the exact same .config - you will not get the CDROM.

Hours of Internet research came up with no answer. Everybody just presumes all you have to do is attach the CDROM at power-on.

So I tried installing stuff from the CD booted on the 2.6.26 kernel intending to reboot under 2.6.28 after installing. Didn't work. Stuff saw the .28 kernel and saw that the booted OS wasn't .28 and bombed out.

Next I downloaded a custom net install iso that installed the 2.6.28.7 kernel. CD worked fine and RealPort compiled fine but wouldn't install - apparently it didn't like the 64-bit kernel somehow, and 64-bit was all that install offered.

I've downloaded a 2.6.30 custom install CD that says it has i386, but if that doesn't work, I'm going to have to tell the client it's up to VMWare to come up with a solution - I' burned out on this.

PS. The VM Client edit module lies about how much disk space is available, and if you expand a virtual disk a little too far - it's pretty much delete the virtual disk, make a new one and start over.

Also, when doing an install you have to delete all existing partitions and start from blank or the partitioning gets all confused and the install blows up with copious red screens.

Also, Debian (any kernel) sees the USB root and hub but can't detect anything you plug into a USB port. Fortunately that isn't really needed on this machine.

All efforts had ended in failure. I had a call put in to the ultimate client to see who I should call at VMWare to try to get their help in resolving this mess - but no answer came back today.

"Well", I thought, "I understand you can actually uninstall udev and go back to the old fashioned /dev with a zillion drivers listed in it". So I decided to do that.

I set up to do the exact same routine I'd done the first few times, except after recompiling the 2.6.28.7 kernel I'd uninstall udev and see if I had a cdrom on reboot.

I did a fresh clean install of 5.0.4 with the defective 2.6.26 kernel. Then I set up my kernel stuff, did the menuconfig, compiled and installed the 2.6.28.7 kernel just like I'd done before.

Then I rebooted. First thing I did was "ls /dev/hd*" to confirm the CDROM wasn't there . . . . ls returned "hda"

AAAAAAAAaaaaaaaaaggggh!!

Why was it there now and it wasn't there the last 10 times I did the exact same thing?

I hate when this happens - because there's no (practical) way to know why. Can it even be done again?

My client said, "I don't give a shit - it's working - finish it up and ship it to me!"