One of those days, I was reminded why I prefer Debian and Redhat based Linux distributions over Novell/SUSE ones. Not that Novell/SUSE is not doing a good job, but in some parts that special last touch is missing to get things working easily as expected. After upgrading our openSUSE Buildservice (OBS) host from openSUSE 11.1 to 11.2 and finally rebooting, the system was not able to decrypt it’s own root partition after entering the correct password.

The error shown on screen pointed towards missing modules inside the initial ram-disk. But how to find out which ones are missing? Using GRML from our network boot system was not the best solution in that case, as most of the crypto stuff is inside their kernel and not loaded as modules like openSUSE does. So that the list you get by calling cat /proc/crypto is not as complete as needed by openSUSE.

Finally I tried booting a 11.2 netinstaller ISO. The automatic repair functions all failed due to the lack of automatic crypto device handling (That is suprising, as 11.2 supports crypted root devices referred to their release notes). Switching to a rescue shell and manually attaching the crypted LVM root partition worked:

cryptsetup luksOpen /dev/sda2 root
/etc/init.d/lvm start

made the root device available at /dev/mapper/root. With

cat /proc/crypto | grep module | awk '{print $3}' | tr "\n" " "

you get a nice list of modules you need to add to the file /etc/sysconfig/kernel as additional values of INITRD_MODULES variable in order to create an initrd, which is able to boot the system from an encrypted LVM root device, with mkinitrd.

Just to make this story complete, a short overview of recreating the initrd in the chroot`ed rescue environment:

mount /dev/mapper/root /mnt
mount /dev/sda1 /mnt/boot
for i in dev proc sys; do mount --bind /$i /mnt/$i; done
chroot /mnt
mkinitrd -f kpartx

I am not sure whether kpartx is really needed, but putting it into the initrd can never be a bad idea.