Since, at my company, we have built and are scaling our architecture, we often have to add and reformat servers. In addition, we use Debian pretty much exclusively. Generally, I am quite happy with the quality of Dell’s PowerEdge series. I won’t speak to their desktop workstations, but their servers are quite powerful, stable (haven’t had a failure as of yet, knock on wood), and come with a lot of nice extra features.
Debian is not an officially supported OS (and I don’t see why not). It’s either Windows, RedHat Linux or SUSE Linux. While RedHat Linux (including CentOS) and Novells SUSE Linux Enterprise Server are respectable server operating systems, we’ve settled on Debian because we’ve generally had a good experience with it and the community support for Debian far outweighs any other Linux distro that I’m aware of. Good community support means faster access to knowledge and fixes. That is just a fact of life and I see that, moving forward, this will make it harder for so-called enterprise products to compete with their limited resources. On the other hand, the downside to this is that you need an active IT staff, willing to commit time to managing quirks and solving problems on their own, without having any corporate support. This works well for us. We like more control.
Nevertheless, this post isn’t about the virtues of running one server OS over another. This is a post about a problem that has plagued us for a little while. Generally, Debian has an astounding support for all sorts of hardware, including server hardware, but occasionally there will be something that doesn’t quite work the way you want it to. In our case, it was using Debian (Etch & Lenny) on Dell PowerEdge 1950/2950 servers with the integrated PERC 5/i raid controller. The specific problem is that during the install process (using the netinstall cd, although I believe it should apply to all other install methods), the installer gets the SCSI drive assignment order all wrong, resulting in an un-bootable operating system once the install is complete and you reboot it.
If you are simply installing it without LVM, this should not cause too much of a headache. You just change the root drive in grub, boot it up, change /etc/fstab & /boot/grub/menu.1st and reboot. But the problem comes when you use LVM, and especially, as in our case, LVM + Luks encryption. Doing so will drop your system to BusyBox, with a system that would not boot and requires some massaging to get working. So, this post describes our solution, so that if anyone else hits this problem with their PERC 5/i raid controller, this should hopefully help them.
First things first, I will assume you have installed Debian Lenny at this point with LVM + encryption (in our case, the installer installed the boot partition into /dev/sdb1 and the encrypted volume group into /dev/sdb2) and you have rebooted only to be dumped to BusyBox with an error saying that such and such volume group could not be found. The next thing you need to do is unlock your encrypted drive.
I shall also assume that /dev/sda1 is your plain ext2 boot partition, while /dev/sda2 is your encrypted partition at this point.
The next thing you need to do is run:
# cryptsetup luksOpen /dev/sda2 sda2_crypt
This will ask you for your encrypted password and will then unlock the partition.
The next thing you need to do is initialize the LVM volumes:
lvm> vgchange -a y <VOLUME-GROUP>
<VOLUME-GROUP> is the name of the volume group on your system. If you are unsure what it is, run “vgs” and it should list it. Usually it is something akin to your hostname, so if you hostname is “SRV1”, it would likely also be “SRV1”.
Now, all you have to do is exit the lvm console with the command “exit“.
Everything should be set up correctly now to continue your boot from BusyBox, so type “exit” again. Your system should resume booting. Don’t worry about any errors you get. You might get a warning about not being about to mount your boot partition and to enter your password to enter maintenance mode. This shouldn’t be necessary, though. Just press CONTROL+D on your keyboard to continue.
Finally, you should hit a normal login prompt. Login as your root user. Now we will be editing a few files to adjust everything.
First, edit “/etc/fstab“:
/dev/sdb1 /boot ext2 defaults 0 2
/dev/sda1 /boot ext2 defaults 0 2
Next up, you need to edit “/etc/crypttab“:
sdb2_crypt /dev/sdb2 none luks
sda2_crypt /dev/sda2 none luks
Finally, we need to edit “/boot/grub/device.map“, but the /boot partition isn’t mounted yet, so type:
# mount -t ext2 /dev/sda1 /boot
Now edit the file “/boot/grub/device.map“:
Finally, that’s it for editing things. You just need to run a final command to update your boot image. Run this:
# update-initramfs -u
That’s it, really. Now you can reboot your system and see how it should finally pick everything up automagically, prompt you for your encryption password and boot into Debian without any headaches.
If anyone wants a more in-depth explanation as to what is going on and why, leave me a comment and I’ll be happy to fill you in on the details.
Please note, you might have to repeat this process again if APT ever upgrades your kernel, so be aware of this.
Filed under: Uncategorized