Bug 1024240 - Full disk encrypted Tumbleweed installation unbootable since update approx. 1 week ago
Full disk encrypted Tumbleweed installation unbootable since update approx. 1...
Status: RESOLVED DUPLICATE of bug 904987
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 All
: P5 - None : Critical (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-08 10:34 UTC by Joost W
Modified: 2017-02-08 14:44 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joost W 2017-02-08 10:34:31 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build Identifier: 

Hello everybody,

since a YAST/Zypper update approx 7-9 days ago, my otherwise solid tumbleweed installation on an XPS13 9560 is left in an unbootable state.

As far as I can see, problems start on boot with

systemd-escape: invalid option -- '5'
Failed to start systemd-cryptsetup@lusk.service: Unit systemd-cryptsetup@lusk.service not found.

Wait a few minutes, then repeating

Warning: dracut-initqueue timeout - starting timeout scripts.
...

Disk setup is on a  NVME SSD with GPT partition 1 as a vfat EFI partition, Part. 2 is btrfs /boot, Part. 3 is LUKS encrpyted / with LVM underneath giving /,/swap and /home after successfull decryption.

After dropping in dracut rescue shell, somewhat successfull boot is possible with

cryptsetup luksOpen /dev/nvme...p3 /crypt
lvm vgchange -a y
exit

though I believe I skipped swap with this as a side effect/ommitance.
After trying to solve this for literally hours, all I came up with is that I have an empty /etc/crypttab (0 bytes) in my initrd, as opposed to a one liner on the booted root system (and also on another notebook still on kernel 4.8.x, as it was not updated for a couple of months). Copying the system crypttab in the initrd did not help though.

I belive this is a critical bug, at least for me it sure is :-(
Very willing to give further info and try solutions, thanks a lot,

Joost


Reproducible: Always

Steps to Reproduce:
1. Boot
2. Boot sequence stuck as noted above.
3.
Comment 1 Joost W 2017-02-08 13:40:11 UTC
Two further notes:

- adding the system /etc/crypttab manually to the initrd via xz ... | cpio unpacking and repacking does not help; still not asking for pw/booting though verified that the crypttab made it in the initrd

- due to some kind of small change or ommitance, I am not able to boot anymore via any way, also not with the manual steps outlined above (though the boot process continues, the desktop does not come up and switching to a text console/login is not working, the computer is only reacting to ctrl-alt-del and rebooting).

So right now I'm out of ideas.
Comment 2 Daniel Molkentin 2017-02-08 14:44:24 UTC
As noted by the reporter, this is a duplicate of #904987.

*** This bug has been marked as a duplicate of bug 904987 ***