One of my customers is in a very unhappy situation: He bought a piece of proprietary software that runs on RedHat’s Enterprise Linux 3, and now the company he bought it from is no longer available. What’s worse, they’ve tied their software to a USB copy protection dongle that uses a homemade Linux kernel module that only works on Linux 2.4.
This customer’s entire business depends on this piece of software. And now the server it’s running on is slowly falling apart, entire CPUs have burned due to failing fans, and there’s a proprietary RAID controller doing dangerous things to old and strange SCSI disks that have been unavailable on the market for several years already.
So they can’t upgrade their software or hardware. They have to watch as the old system collapses bit by bit.
You’d think you could just virtualize the server, but I ran into a couple of snags:
- The software runs only on RedHat Enterprise Linux 3, release 2003. That’s ten years ago, just in case you’re not counting.
- The software depends on a hardware dongle that only works with certain versions of Linux 2.4. It doesn’t work on any 2.6 or 3.x kernels, so simply using a modern version of CentOS is out of the question.
- Using RHEL 3 means you can’t really transfer the system to modern hardware, since RHEL 3 doesn’t even support SATA.
- Even if you do manage to find some hardware with ATA disks, who’d want that, it would be almost as old as the server it’s replacing!
I ended up creating a blank virtual machine in VirtualBox (so the customer can control it via GUI), and using a live CD to do these special things:
Create an ext3 filesystem that RHEL 3 can mount. That means using only 128 byte inodes and getting rid of some special features:
mkfs.ext2 -j -I 128 -L / /dev/hda1
Notice the label “/”, which RedHat really likes to have. Then disable the features RHEL 3 can’t deal with:
debugfs -w /dev/hda1 debugfs 1.40.8 (13-Mar-2008) debugfs: features -ext_attr -resize_inode -dir_index +large_file +needs_recovery Filesystem features: has_journal filetype needs_recovery sparse_super large_file debugfs: quit
Thanks, this article, for the hint.
As next step, I SCP’d all the files from the physical server to the root of the new virtual hard disk. Then I adapted /etc/fstab to point at the new hda1 (it used to point at sda1, the RAID device exported via SCSI on the hardware server).
Finally, I booted Super Grub 2 Disk, selected the legacy Grub 1 configuration from the hard drive, booted into the new virtual hard drive, adapted /boot/grub/grub.cfg and device.map to point at the new devices, ran grub-install. And so I had RHEL 3 running virtualized.
If you ever need to do data archaeology of this kind, maybe this article is useful for you.
The final step is to install an up to date GNU/Linux distribution on brand new hardware for my customer, put Virtual Box and that VM on there and pass the USB copy protection dongle through to the guest system.