If you are not familiar with this kind of setup, it basically works with:
- a non-encrypted /boot with kernel and initramfs
- initramfs contains required modules (aes, lvm, etc.) and a few scripts to mount the filesystem: in this case, a script to ask for the password, decrypt the LVM and mount the root filesystem
The failure comes from the new (11.04) initramfs. Hopefully the upgrade left the previous kernel and initramfs intact, so I could boot on the older one to fix it.
To investigate why it fails to boot with the new initramfs, just compare it with the old one.
Extract initrd images (initramfs format) to current directory:
gzip -d < initrd.img | cpio -i --make-directoriesCreate initrd image (initramfs format) from current directory:
find . | cpio -H newc -o | gzip -c -9 > initrd.imgIf you prefer, here are two helper scripts: initrd-extract.sh & initrd-create.sh.
Recurse diff showed - among other things - a different scripts/local-top/cryptroot. This is an initramfs-tools script from package cryptsetup. Weird, no bug report yet.
A quick solution is to extract new initramfs, replace the new cryptroot script with the old one - extracted from the old initramfs - and repack. A more permanent solution is to copy the old cryptroot script (extracted from the old initramfs or from the old package) to /usr/share/initramfs-tools/scripts/local-top/cryptroot, and generate it again with:
update-initramfs -tuck <target kernel version>(t: takeover, u: update, c: create, k: kernel version)
Anyway, it is always good to know how to work with initramfs images. And they can be fun use, for instance see how SliTaz use it to have a fully featured desktop running in RAM and in less than 30MB (disk, not RAM).
Also, I am sure you know that the kernel can drop you to /bin/sh at the root filesystem init with parameter "init=/bin/sh" (it is a convenient way to reset a root password), but did you know it can do the same with the initrd? "rdinit=/bin/sh" drops you to /bin/sh inside your initramfs.