I was pondering what to do about disk encryption on an unattended server. If you want an uninterrupted boot sequence, you can’t use full root disk encryption or it will ask you for your passphrase during init.

You can apparently do some fudge to put dropbear (mini SSH daemon and shell) into your initrd, so you can enter your passphrase over SSH, but that seemed hacky. I’d rather a serial console on a terminal server, for those servers with serial ports or LOM’s.

So I created a Fedora 12 virtual machine to play with my options. I decided to not encrypt the entire boot drive, only the /home partition, and then have a second backup drive entirely encrypted, neither of which are mounted at boot. That way you can use the machine as a remote server, reboot it, power off and back on using Wake-On-Lan, even allow other users to login; and when you have physical access you can use cryptsetup+mount to open your $HOME and backup partitions.

However, no matter what I tried, I kept getting prompted on boot for the passphrase, even though the fstab and crypttab were empty. Upon closer inspection of the files within initrd, it seems that the way of detecting root drive encryption and creating a passphrase prompt is not very picky. The routine ignores the fact that your backup drive does not have the bootable flag set, and is not the boot drive in the fstab or BIOS for that matter, and just assumes that if the entire drive is encrypted it must need opening to allow booting!

Short of recreating my initrd upon every new kernel install (don’t get me started on how shite dracut is compared to mkinitrd) the only way around it I found is to add the kernel parameter rd_NO_LUKS to the /boot/grub/menu.lst

I also header from one of the Fedora devs, that they’re going to move to upstart instead of init (see previous post) by Fedora 14. Hopefully the Ubuntu devs will have fixed the bugs by then!