http://bugzilla.opensuse.org/show_bug.cgi?id=1095096 Bug ID: 1095096 Summary: Leap 42.3: update broke boot with encrypted partitions on NVMe Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: openSUSE 42.3 Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: dariusz.ostolski@gmail.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- Created attachment 771738 --> http://bugzilla.opensuse.org/attachment.cgi?id=771738&action=edit Emergency shell with broken cryptsetup After latest updates my laptop won't boot anymore. Needless to say I've chosen Leap due to stability and this is somehow disappointing that it's second time during last 12 months when my machine cannot boot because of updates. I have LVM encrypted nvme disk. The culprit of this is difference between what contents of /etc/crypttab and /dev/disk/by-id/ directory (see attachment). How to fix that (based on https://bugzilla.opensuse.org/show_bug.cgi?id=1063249 and https://bugzilla.opensuse.org/show_bug.cgi?id=904987): 1. Wait for emergency shell 2. Decrypt *all* encrypted drives/partitions (you quite possibly only have one) that are part of your system. The lsblk command may be helpful, or you may find these under paths like /dev/nvme*, or it may be easier to look at the symlinks under /dev/disk/by-id/ (be aware there are likely lots of duplicates, pointing to the same drive/partition, in this location). Run cryptsetup for each one: cryptsetup open <device> <some-unique-name> For example: cryptsetup open /dev/nvme0n1p2 name1 <some-unique-name> needs to be different for each device, obviously. :-) Enter the normal passphrase for each device when prompted. 3a. If you are using LVM, run: lvm_scan lvm lvscan lvm vgchange -ay lvm lvdisplay Verify you can see all your logical volumes. Note the "LV Path" of each logical volume. Mount the logical volume that corresponds to the / filesystem for your system on /mnt. It may have an "LV Name" of root, or it may not. Use the "LV Path" to mount it: mount <lv-path> /mnt For example: mount /dev/system/root /mnt 3b. If you ARE NOT using LVM, mount the drive/partition that corresponds to the / filesystem for your system on /mnt: mount <device> /mnt For example: mount /dev/nvme0n1p2 /mnt 4. (probably unneeded!) If you have a very unusual setup where /etc is on a separate filesystem from /, mount it: mount /mnt/etc For example: mount /dev/system/etc /mnt/etc 5. Prepare and enter a chroot environment for your system: mount -t proc none /mnt/proc mount --rbind /dev /mnt/dev mount --rbind /sys /mnt/sys chroot /mnt /bin/bash 6. Mount the remaining filesystems (if any) using information from your system's /etc/fstab file: mount -a 7. Edit /etc/crypttab to fix the entry that is no longer created by udev because of this bug. Replace: /dev/disk/by-id/nvme-20xxxxxxx With: /dev/disk/by-id/nvme-eui.0 8. (May be optional) I'm not sure if this is required but I've executed /usr/lib/systemd/system-generators/systemd-cryptsetup-generator 9. Regenerate the initramfs boot images with dracut. dracut -f -- You are receiving this mail because: You are on the CC list for the bug.