Bug 462540

So we've talked about adding a 3-try-and-give-up approach.

Really, we should mark what partitions are required for a usable system (/, /home) and what ones are optional (/opt, /srv, etc)

A ctrl-d escape hatch isn't a bad idea, though.

I don't think a scheme of marking partitions is going to be tenable.

First, how will you know where the "required" partitions lie?  On my laptop, sda3 is a LUKS-encrypted LVM partition. How would you know the logical volumes that LVM partition contains?  For that matter, what if I had multiple encrypted LVM partitions, and have logical volumes that span them?

Trying to cache that information in /boot (e.g., at system shutdown time) is just asking for stale information.  (E.g., what happens if I make LVM changes, but the system crashes and thus boots with stale cached information?)

Furthermore, I will point out that for some people, the names of the logical volumes themselves might be treated as sensitive information.  If you cache that information in /boot, you may be subverting someone's security profile.

Second, depending on my environment, I might not actually *want* to unlock all encrypted partitions.  E.g., I might have encrypted partitions that use different keys and have different levels of sensitivity.  The boot process can't make the determination of what partitions are appropriate to decrypt at any given time; I have to do it.

I can understand that you want to make the process of unlocking encrypted volumes a user-friendly as possible.  But trying to figure out which partitions are "required" is bound to fail.  You need to trust the user to make that determination at boot time, by unlocking partitions that should be unlocked, and using Ctrl-D (or whatever mechanism) to skip unlocking partitions that shouldn't be unlocked.

My point was just that we shouldn't continue boot if continuing boot is going to result in the machine crashing immediately there after.

For instance, we shouldn't continue boot if we can't decrypt / because without / we can't boot.

I think most partitions probably should be optional, so it could be just "/" that is required or maybe "anything in initrd" and possibly "/home"

We can make ctrl-d always continue, though, even for things that are doomed to fail.

Everything else we'll give a 3 tries and give up approach i guess.  Sound good?

I think continuing to attempt to find the "/" filesystem isn't unreasonable, but that's going to be tricky, as initrd must re-scan for md devices and LVM volumes (activating any that are found) after every time an encrypted volume is successfully unlocked.

However, this bug is really mkinitrd's fault, not plymouth's. I cracked open my initrd and found this in init:

...
echo Setting up disk encryption: /dev/sda3
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda3 luks-sda3"
echo Setting up disk encryption: /dev/sda2
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda2 swap"
...

But:

$ grep /dev/sda2 /etc/crypttab 
swap       /dev/sda2  /dev/urandom  swap,cipher=aes-cbc-essiv:sha256

In other words, mkinitrd did the wrong thing; it never should have added the lines invoking plymouth to unlock /dev/sda2, because it's glaringly obvious from /etc/crypttab that no one will have a key to unlock it.

Should I open another bug against mkinitrd, or do you want to reassign this one?

Also, I have no issues with the "try 3 times and give up; Ctrl-D always continues" approach; that seems perfectly reasonable.

separate bug please.  I'll use this bug for tracking the 3-tries and give up / ctrl-d issue.

So the 3-tries-and-bail bits landed a while ago.

I haven't done the ctrl-d bits, yet.

I'd like to track that upstream, since it's not crucial to get done for F10 initial release and we're coming down to the wire now.

I think it's reasonable to track the Ctrl-D bits upstream, yes.

(I didn't file a bug against mkinitrd, because someone already noticed and fixed it.)