initrd no longer activating encrypted filesystems

[Martin Meyer]

I'm running a setup with encrypted LVM on my laptop. Until very recently, I was prompted for the passphrase to the encrypted partition (/dev/sda2) early during the boot process, and once it was opened my volume group (vg00) was activated automatically. Boot would continue normally until the login screen.

Starting about 2 weeks ago, I stopped being asked for the passphrase. I'm dropped to a busybox prompt telling me that the root filesystem can't be found, but it never even tried to open the encrypted partition. Two simple commands ('cryptsetup luksOpen /dev/sda2 main' and 'lvm vgchange -a y vg00') fix the issue.

So why am I not being prompted for the passphrase like I used to be? Nothing is actually missing from the initrd, and I actually am prompted for the passphrase later (far too late) in the boot process. I just press enter several times until it gives up and everything continues normally past that.

[Martin Meyer (elreydetodo)]

I should mention that the laptop in question is running Jaunty, so the packages involved are changing frequently. My initrd has been regenerated a number of times since the problem started, and the kernel has been updated at least twice.

My guess is that the order of the stuff run in the initrd has been changed, and now the cryptsetup portion happens too late in the process.

[Martin Meyer (elreydetodo)]

My issue could be related to (or the same as) bug #287879. Since that is now resolved I'll update tonight to indicate if this has resolved my issue. I got that package update last night but haven't rebooted the laptop yet.

[Martin Meyer (elreydetodo)]

Even after updating for the package fix referred to in bug #287879 my issue is still not fixed. I could really use some help debugging this!

Here's my current state:

Every time I boot my system, I'm dropped to an initrd busybox prompt with a notice that my root device can't be found. The root device can't be found because the initrd hasn't bothered to try opening my luks-encrypted partition yet. A simple "cryptsetup luksOpen..." from the prompt will unlock the partiton, then my LVM volumes are automatically found and activated. I've typed one command and pressed ctrl+d and everything continues roughly as usual.

After I've manually unlocked my encrypted partition, I'm actually asked for the passphrase for it a few seconds later (even though it's already unlocked). This says to me that the cryptsetup stuff in the initrd is happening far too late.

Help!

[Aaron C. de Bruyn (darkpixel2k)]

I have what appears to be a related issue. I was originally getting the busybox prompt, but running cryptsetup luksOpen... wouldn't fix the problem. I ran the recovery CD, chrooted, and did an apt-get upgrade. After recent updates installed (about 10 minutes before I posted this) I rebooted. Now I get the same busybox prompt, but running cryptsetup says "key slot 0 unlocked" and the disk has bee thrashing since... Never get automatically prompted for a password.

[Martin Meyer (elreydetodo)]

You're experiencing a new and fantastic bug introduces in the recent update to udev 138-1. Check out bug 332270.

[Martin Meyer (elreydetodo)]

bug 319982 and bug 287879 have been fixed now and I'm still not prompted for my encryption passphrase at boot. After reading over comments by other people in those bugs, I've noticed that my initrd does not contain a file "conf/conf.d/cryptroot". This file seems to be what tells the initrd which devices to try to unlock.

Each time my initrd is generated I get two warnings about invalid lines:

$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-2.6.29-020629rc5-generic
cryptsetup: WARNING: invalid line in /etc/crypttab -
cryptsetup: WARNING: invalid line in /etc/crypttab -
update-initramfs: Generating /boot/initrd.img-2.6.28-8-generic
...

My /etc/crypttab looks like this:

sda2_crypt /dev/disk/by-uuid/52fd0ccb-c1b7-4786-b242-b0c39b83d643 none luks

Why does it say invalid line twice? And why is this line invalid now but wasn't before mid-January when this started happening? What does a valid line look like now? Mine seems to be in agreement with what the man page for crypttab says. Note that I haven't modified this file myself - something must have changed in how this file is parsed.

Can *someone* please give me some suggestions?!

[Martin Meyer (elreydetodo)]

ha-HA! The problem seems to be that underscore is no longer a valid character for the device name. I changed "sda2_crypt" to "root" and everything works beautifully!

Now for the bad part. What the heck happened here?! WHY did "sda2_crypt" stop being a valid target name? That name was picked for my by default by the Hardy installer. If people upgrading to Jaunty with encrypted filesystems are going to experience this kind of breakage then there needs to be a guide somewhere or an automatic migration as part of the package upgrade!

Can anyone identify exactly when this was broken?

Which package / script / binary is responsible for parsing the crypttab file?

WHY would _ make the entire line invalid in crypttab?

Does anyone reading this actually care about this problem?

[JochenRueter (joschi-fliegergruppe-donzdorf)]

I experienced the same issue, after a fresh reinstall of Jaunty yesterday. I also had my encrypted lvm partition created by an earlier ubuntu release and it was named sda5_crypt. The script which is responsible for parsing crypttab seems to be in /usr/share/initramfs-tools/hooks/cryptsetup . Bug 332950 finally helped me out, I replaced the mentioned script with a patched version, which at least gave a more descriptive error message.

[Martin Meyer (elreydetodo)]

I've just checked on my recently-built Karmic laptop to see if this is still a problem. I think it is not. The /etc/crypttab generated automatically as part of the Karmic installation contains an _ in the device name, so I suspect this was probably fixed by a new release of whatever package reads that file.

I suggest closing this bug.