Kubuntu 15.04 vivid: black screen with pam_mount luks

[Stefan]

I've been running Kubuntu 14.10 on my lenovo yoga 2 13. without problems (except Wifi). Now I've installed Kubuntu 15.04 vivid. Grub didn't run and didn't complain, I had to run 'update-grub' from old installation (14.10), but that's not the issue of this post.

I had my home partition encrypted with luks and mount it on login with pam_mount. But on 15.04 this does not work any more: it ends in a black screen. I can switch to console with <CTRL><ALT><F1> and log in, partition is unencrypted and mounted. I didn't find any hints in dmesg or syslog. The entry in /etc/security/pam_mount.conf.xml is:
<volume fstype="crypt" path="/dev/sda9" mountpoint="/home" options="fsck,relatime" />

I can only login to KDE with LUKS mounted by the following procedure:
- comment out the line in pam_mount.conf.xml
- boot to KDE login screen
- switch to terminal with <CTRL><ALT><F1>
- log in (LUKS partition is mounted)
- comment in the line in pam_mount.conf.xml
- switch back to KDE login with <CTRL><ALT><F7>
- login

Stefan

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1448404/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Karl May (may-ka38)]

Similar issue.

System: Kubuntu 15.04. Upgraded via from 14.04->14.10->15.04 via package manager.

Setting: Whole hard disk is managed via lvm. Home partition is encrypted and mounted into /home/"user"/.

Issue: Black screen when booting. After pressing any key, kubuntu was asking for the password of the encrypted home partition well before the actual login page appeared. Home partition is an encrypted and managed via lvm.

Solution: I hided the file "crypttab" in "/etc/". Now everything works fine.

Cheers

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stefan (alter-depp)]

@Karl May: what do you mean by 'I hided the file "crypttab" in "/etc/"?
I can't find such a file. Only "locate crypttab" tells me, that such a file should exist.
Stefan

[Karl May (may-ka38)]

@Stefan
I did "mv crypttab .crypttab"

[Karl May (may-ka38)]

severe problem:

With kernel 3.19.0-16 and 3.19.0-15 boot is not possible any longer. At boot, kubuntu is NOT asking for any password to decrypt the fully encrypted hard disk. In turn, after some seconds the error message "ALERT! /dev/mapper/kubuntu--vg-root does not exist. Dropping to shell!" occurs and kubuntu drops to BusyBox built-in shell.

Note that this does not happen when booting with kernel 3.13.0-51

[Dave Jones (waveform)]

I also see this with a fresh install of Ubuntu 15.04 on my netbook (Toshiba NB550D). Installation was a straight-forward "use whole disk for Ubuntu, and encrypt everything". On boot, screen goes black. Entering the encryption password "blind" continues the boot successfully (login screen appears and everything's fine). The workaround of switching terminals with Ctrl+Alt+F1 then Ctrl+Alt+F7 also works, causing the password prompt to appear.

I haven't tried fiddling with crypttab as I seem to recall that's the file that records what to do with mounted volumes at boot (though I presume it'll actually get used in the creation of an initrd in this case as the file itself wouldn't be readable until the encrypted volume is mounted ... Catch-22 and all that). Anyway, fiddling with it sounds like a bad idea all round so I'll stick with the terminal switch workaround for now.