Bug 1024240

Summary:	Full disk encrypted Tumbleweed installation unbootable since update approx. 1 week ago
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Joost W <joostw>
Component:	Basesystem	Assignee:	E-mail List <bnc-team-screening>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Critical
Priority:	P5 - None	CC:	daniel
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	All
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

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 ***