text plugin: mountall status clobbers passphrase prompt

[swmike]

Hello.

I have two machines with crypted /home (one machine, this is directly on a partition) and the other with crypted /home (on md) and / (using alternate install method in 8.04 or 8.10). I have since upgraded these to 9.10 and 10.04 respectively, and the 10.04 machines was running 9.10 at one point. Both of them worked perfectly in 9.04 in respect to the passphrase was asked correctly and the boot procedure worked properly.

On all these machines, the entering of passphrase at boot works very badly. Booting without "quiet" and "splash" yields the possibility to enter it blindly in the boot process, because the request for passphrase doesn't seem to be in the right place in the bootup process (at least for crypted /home). With the machine with just crypted /home, I have to type it multiple times (blindly) and after a few attempts it works. Sometimes I have to drop to shell to do it manually and then resuming the boot process.

With the 10.04 machine I also had the problem that when running with splash and quiet, if the md the crypted volume resided on didn't come up correctly, this wasn't even detected at all and the boot process would just wait endlessly without asking to drop to rescue mode.

My crypted volumes are properly entered in /etc/crypttab:

sdb1_crypt /dev/disk/by-uuid/b23e9d57-2ecf-4411-bcbd-23ca39e924e5 none luks
md0_crypt /dev/md0 none luks

My guess is that crypted volumes (either directly on partitions or on md) isn't part of the verification process for releases? I can supply more information if needed, but I think it'll be pretty easy to reproduce, just create a partition on the system, "cryptsetup luksFormat" it, enter it in /etc/crypttab, start it manually, create an fs on the /dev/mapper/<volume> , and then put this in /etc/fstab. Then start to induce problems in the boot process and see what happens.

I can provide more information as needed, I can create a video as well if needed.

[swmike (ubuntu-s-plass)]

Basically this is done according to the following guide:

https://help.ubuntu.com/community/EncryptedFilesystemHowto3

Here's how to reproduce (even though this reproduction is actually worse than what I've seen before, now I'm afraid of rebooting my karmic box because it won't come up again):

Installed karmic alpha 2, and then dist-upgraded everything.

apt-get install mdadm
apt-get install cryptsetup
mdadm --create --level=1 --raid-devices=2 /dev/md0 /dev/sdb1 missing
cryptsetup luksFormat /dev/md0
cryptsetup luksOpen /dev/md0 md0_crypt
mkfs.ext3 /dev/mapper/md0_crypt
mkdir /t

/etc/crypttab:
# <target name> <source device> <key file> <options>
md0_crypt /dev/md0 none luks

# /etc/fstab: add this
/dev/mapper/md0_crypt /t ext3 defaults 0 2

/etc/mdadm/mdadm.conf add this (change uuid):
ARRAY /dev/md0 level=raid1 num-device=2 UUID=c0357b84:18cb2297:8282d032:d2636449

That results in it just waiting for the volume, doesn't ask for the crypt password. Then if you press esc, it drops to regular console and you're allowed to enter the passphrase (cosmetically broken, but seems to work to enter the passphrase).

Then after the crypted volume has been opened, nothing more happens. Won't even go to rescue mode if that's chosen.

Will attach PNGs from the boot process.

[swmike (ubuntu-s-plass)]

What is shown when just booting straight up with the configuration.

[swmike (ubuntu-s-plass)]

After pressing ESC, or when removing "quiet splash" from grub.

[swmike (ubuntu-s-plass)]

After entering the passphrase nothing more happens, doesn't matter if one tries rescue mode or not.

[swmike (ubuntu-s-plass)]

Even when failing the passphrase, nothing more happens, not even when trying to go to rescue mode.

I had to boot live usb in the virtual machine to remove the /t-entry from fstab to be able to get to the machine again so I could get the information needed.

[Steve Langasek (vorlon)]

Thank you for taking the time to report this bug and help to improve Ubuntu.

The behavior shown in comment #3 appears to be a bug in plymouth's text plugin: when two processes (mountall and cryptsetup) are talking to plymouth at the same time, plymouth fails to correctly display the passphrase prompt, seemingly (based on what I catch sight of as things flash by) because the prompt gets overwritten by the mountall message. If I hit the spacebar the prompt is re-rendered, but some of the keypresses also appear not to be registered correctly perhaps because they're being eaten on behalf of mountall.

This bug is not reproducible with the default 'script' plugin used by the Ubuntu theme (which requires a framebuffer renderer), nor is it reproducible when mounting the root partition in the initramfs because cryptsetup is the only thing talking to plymouth at that point.

Setting importance to 'medium' because it's expected that we won't have to use the text plugin for lucid on most hardware once the framebuffer renderer is ported to work with the default VGA16 framebuffer.

[Steve Langasek (vorlon)]

> With the 10.04 machine I also had the problem that when running with
> splash and quiet, if the md the crypted volume resided on didn't come up
> correctly, this wasn't even detected at all and the boot process would
> just wait endlessly without asking to drop to rescue mode.

In this case you should see on your screen a line that reads '[SM]'. If you press 'S', boot will continue without mounting the file system ("skip"). If you press 'M', you will be given a recovery shell ("maintenance").

Unfortunately this isn't the least bit discoverable right now; I think that's a mountall bug, because users are given no hints as to the meaning of that line on the screen.

[swmike (ubuntu-s-plass)]

Thanks for the excellent analysis of where the problem lies.

I would also like to add that on one machine I have /home on a md->cryptsetup->lvm(pv/vg/lv)-xfs volume, just so whoever does the testing includes this scenario in the testing before release. I can verify myself if needed.

Thanks again to everybody involved!

[Steve Langasek (vorlon)]

I've tested this with plymouth 0.8.1-1, and it looks like both prompts will now display correctly at the same time. So I think the plymouth task can be considered fixed.

[Scott James Remnant (Canonical) (canonical-scott)]

Marking mountall task as fixed, I assume it was open because "[SM]" was hard to understand - and that's obviously long-since fixed

[swmike (ubuntu-s-plass)]

I'd just like to add that as far as I can see, this is completely fixed in 10.04 and works beautifully, but it's still a problem in 9.10 (which is not a problem for me personally).