Comment 12 for bug 1506139

Revision history for this message
Hadmut Danisch (hadmut) wrote :

OK, I've finally found the problem(s). Was a bunch of little nasty problems, that's why it was difficult to debug.

1)

The 15.10 beta installer had filled /etc/initramfs-tools/conf.d/resume with

RESUME=UUID=a18e9ec9-1255-4dda-8298-8e10bdbe6835

which is never updated after first installation. Since I had to repair the swap device several times, this was not correct anymore, and furthermore /usr/share/initramfs-tools/hooks/cryptroot can't deal with it. It's important that

RESUME=sda2_crypt

is entered.

2) That's why /usr/share/initramfs-tools/hooks/cryptroot did not mention the device in /conf/conf.d/cryptroot of the initramfs.

Once it is correctly mentioned in this file (after fixing bug 1), the password is fetched and the device is opened at the initramfs phase, i.e. before systemd takes control. This works well.

3) If sda2_crypt is not mentioned in the initramfs' /conf/conf.d/cryptroot, it is not opened while initramfs has control. But then, once systemd takes control, systemd tries to open it since it is listed in /etc/crypttab.

But this does not work, since both systemd and plymouthd have bugs. plymouthd can go into an endlesss loop or completey fail, depending whether you have splash/graphical boot or textual.

Once bug 1 and 2 are solved, this issue does not occur anymore.

4) But then, system hangs while booting for another reason. systemd still tries to create a swap device and hangs forever. I could not reliably figure out why, but it looks as if it waits for systemd-cryptsetup for to do some things which it doesn't do since the crypt device is already open.

Solution: remove the swap option in /etc/crypttab

5) Finally seems to work.

Just for the notes: systemd (and plymouth) is so buggy and intransparent that it is far from beeing production-ready.

That cost me several evenings of work and headache.