Comment # 32 on bug 904987 from Chris Scheible

Hi,

I hit the same issue after applying the latest patches to OpenSuse 42.2 two
weeks ago on my system (HP Spetre 13 w/ NVME SSD). The system is configured
with LUKS encrypted system LVM, only /boot is unencrypted. The encrypted LVM
setup was done by the OpenSuse installer when I provisioned the system.

The symptom for me was exactly the same as in the other bug reports: no
password prompt for unlocking and mounting the rootfs logical volume during
boot.

The root cause that I found on the system was that the OpenSuse patch update
automagically renamed the partitions in /dev/disk/by-id/ . However, the update
neither rebuilt the /etc/crypttab with the new partition names nor rebuilt the
initrd.

To get the system working again, I used the following procedure:

* Boot into emergency shell from grub menu (add '1' to end of kernel boot
line), the shell with the boot output just errors out after not finding the
rootfs and tells me to rebuild the initrd... 
* Selected emergency shell with ALT+F7 (shouldn't the emergency shell prompt
open on the same shell as the boot messages?)
* dracut emergency shell /etc/crypttab contained old /dev/disk/by-id/ partition
...

* Booted rescue system from USB stick and setup chroot environment. Did the
following in the chroot environment:

ls -l /dev/disk/by-id/
(find partition with the encrypted physical volume for the system LVM)
cryptsetup luksOpen /dev/nvme0n1p9 
lvscan
cp /etc/crypttab /etc/crypttab.old
vi /etc/crypttab
(replaced the wrong /dev/disk/by-id/... path with the absolute partition path
/dev/nvme0n1p9)
mkinitrd
(rebuilt initrd, copies the new /etc/crypptab to initrd filesystem)
exit chroot
reboot

==> system now asks for password to unlock encrypted partition and boots as
expected after password entry.