I have the same issue with Snapshot 20241118 when trying to boot in normal mode. In emergency mode I can unlock the root and swap partition though.
Then provide full output as root of
journalctl -b --no-pager --full
after booting. Upload to https://paste.opensuse.org/
Same request for journalctl output.
Here you go: openSUSE Paste
This log shows:
Nov 22 07:06:44 linux-1720 dracut-cmdline[345]: Using kernel command line parameters: rd.driver.pre=btrfs rd.luks.uuid=luks-307e597f-1fcf-43eb-84c1-3ab10753f428 rd.luks.uuid=luks-47c59d9d-e683-42b5-9b74-0a8d6f27de81 resume=UUID=a2573e90-5199-42d0-8679-5bff1fdd0c2b root=UUID=8e37d786-0beb-468e-9ca7-de0f51222d3b rootfstype=btrfs rootflags=rw,relatime,ssd,space_cache,subvolid=3259,subvol=/@/.snapshots/1215/snapshot,subvol=@/.snapshots/1215/snapshot BOOT_IMAGE=/vmlinuz-6.11.8-1-default root=UUID=8e37d786-0beb-468e-9ca7-de0f51222d3b single
Nov 22 07:06:45 linux-1720 systemd-escape[440]: Input 'luks-307e597f-1fcf-43eb-84c1-3ab10753f428' is not an absolute file system path, escaping is likely not going to be reversible.
Nov 22 07:06:45 linux-1720 systemd-escape[451]: Input 'luks-47c59d9d-e683-42b5-9b74-0a8d6f27de81' is not an absolute file system path, escaping is likely not going to be reversible.
Not sure the second two lines indicate some kind of problem but I search for the UUID’s (307e5… and 47c59…) in the rest of the log and could not find them. That does not look good.
Can you check if these UUID’s are in the output of lsblk -o +UUID when the system is successfully running with the work-around.
Nov 22 07:06:45 linux-1720 systemd[1]: Starting Cryptography Setup for cr_swap...
...
Nov 22 07:08:15 linux-1720 systemd-tty-ask-password-agent[744]: Failed to query password: Operation canceled
Nov 22 07:08:15 linux-1720 systemd-cryptsetup[735]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/47c59d9d-e683-42b5-9b74-0a8d6f27de81.
Nov 22 07:08:15 linux-1720 systemd-tty-ask-password-agent[744]: Invalid password file /run/systemd/ask-password/ask.3B67I6
Nov 22 07:08:15 linux-1720 systemd-tty-ask-password-agent[744]: Failed to process password: Bad message
Nov 22 07:08:15 linux-1720 systemd-cryptsetup[737]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/307e597f-1fcf-43eb-84c1-3ab10753f428.
Nov 22 07:08:16 linux-1720 systemd-cryptsetup[737]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Nov 22 07:08:16 linux-1720 systemd-cryptsetup[735]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Nov 22 07:08:20 linux-1720 systemd-cryptsetup[737]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/307e597f-1fcf-43eb-84c1-3ab10753f428.
Nov 22 07:08:22 linux-1720 kernel: Key type trusted registered
Nov 22 07:08:22 linux-1720 systemd[1]: Finished Cryptography Setup for cr_swap.
It seems that two devices fail to use password initially and then two devices succeed. One of them must be your swap. Can you post
lsblk -f
According to logs, there was no emergency mode, boot was successful. Interesting would be log when you stop in emergency mode.
Thats the output of lsblk -o +UUID:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS UUID
sda 8:0 0 465,8G 0 disk 4f85b718-baa6-439f-aac6-be853aaa00b9
└─cr_mnt_sda 254:2 0 465,8G 0 crypt /mnt/sda c3e9d0a2-3502-45ee-86b0-1ead5988cadc
nvme0n1 259:0 0 1,8T 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot/efi 42B2-6467
├─nvme0n1p2 259:2 0 1,8T 0 part 47c59d9d-e683-42b5-9b74-0a8d6f27de81
│ └─cr_root 254:1 0 1,8T 0 crypt /var 8e37d786-0beb-468e-9ca7-de0f51222d3b
│ /home
│ /root
│ /srv
│ /usr/local
│ /opt
│ /.snapshots
│ /
├─nvme0n1p3 259:3 0 2G 0 part 307e597f-1fcf-43eb-84c1-3ab10753f428
│ └─cr_swap 254:0 0 2G 0 crypt [SWAP] a2573e90-5199-42d0-8679-5bff1fdd0c2b
└─nvme0n1p4 259:4 0 1G 0 part /boot 6cf736d3-2c1c-4a2d-9aa0-cdf82e76f320
The UUID s which fail exist: nvme0n1p2 and nvme0n1p3. I’ll try to get the output of journalctl in emergency mode later.
OK, so your swap is on 307e597f-1fcf-43eb-84c1-3ab10753f428 as suspected and apparently it succeeds (even if not for the first time). You boot with single kernel parameter, but it only affects what happens after switch to the real root, while unlocking happens in initrd already. It is still strange that systemd-tty-ask-password-agent is active (it should be mutually exclusive with Plymouth). There is no log entry about starting it. It is possible that there is some race condition between the two.
Here are the outputs, @arvidjaar:
-
/home decrypted and mounted (not logged in as user yet, just decrypted /home with the password I used when asked on booting and mounted)
I think thia issue ia related to the Plymouth issue reported by other users. This would explain why the Boot works in recovery mode. So reverting to the Plymouth Version before snapshot 20241118 or disabeling plymouth may fix this issue.
It seem like more and more users getting the same problem as mine not only on tumbleweed but also on MicroOS and Leap as well. And it seem like the plymouth is the blame here. Well I’ll wait till this coming Wednesday to update again and pray this issue got resolve before Wednesday.
Updated to Tumbleweed’s snapshot 20241121, rebooted and the problem remains.
Thanks for the heads up!
1 Like
So, I had the same problem (swap wouldn’t decrypt). I got to the emergency terminal and then checked to see if the service was running: systemctl status systemd-cryptsetup@cr_swap.service
It showed that it failed.
Started the service and it let me put in my pass in the terminal. Then exit to continue boot. And now I’m back into my laptop.
Relevant section of the log:
Nov 23 21:12:09 txtechnician-hp-suse kernel: input: Dell Dell USB Keyboard Hub as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:413C:2002.0006/input/input30
Nov 23 21:12:09 txtechnician-hp-suse kernel: hid-generic 0003:413C:2002.0006: input,hidraw5: USB HID v1.10 Keyboard [Dell Dell USB Keyboard Hub] on usb-0000:00:14.0-2.1/input0
Nov 23 21:12:09 txtechnician-hp-suse kernel: input: Dell Dell USB Keyboard Hub Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:413C:2002.0007/input/input31
Nov 23 21:12:09 txtechnician-hp-suse kernel: input: Dell Dell USB Keyboard Hub System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:413C:2002.0007/input/input32
Nov 23 21:12:09 txtechnician-hp-suse kernel: hid-generic 0003:413C:2002.0007: input,hidraw6: USB HID v1.10 Device [Dell Dell USB Keyboard Hub] on usb-0000:00:14.0-2.1/input1
Nov 23 21:12:09 txtechnician-hp-suse kernel: usbcore: registered new interface driver usbhid
Nov 23 21:12:09 txtechnician-hp-suse kernel: usbhid: USB HID core driver
Nov 23 21:12:10 txtechnician-hp-suse kernel: Key type trusted registered
Nov 23 21:12:10 txtechnician-hp-suse systemd[1]: Found device /dev/disk/by-uuid/3a7b156c-e1fb-4f2b-a985-53eaf2ad5169.
Nov 23 21:12:10 txtechnician-hp-suse systemd[1]: Finished Cryptography Setup for cr_root.
Nov 23 21:12:10 txtechnician-hp-suse systemd[1]: Reached target Initrd Root Device.
Nov 23 21:12:16 txtechnician-hp-suse systemd-cryptsetup[681]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/5418ce3b-80cb-43b6-a380-3be6c4f6283c.
Nov 23 21:12:18 txtechnician-hp-suse systemd-cryptsetup[681]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Nov 23 21:12:40 txtechnician-hp-suse systemd-cryptsetup[681]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/5418ce3b-80cb-43b6-a380-3be6c4f6283c.
Nov 23 21:12:42 txtechnician-hp-suse systemd-cryptsetup[681]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Nov 23 21:13:42 txtechnician-hp-suse systemd-cryptsetup[681]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/5418ce3b-80cb-43b6-a380-3be6c4f6283c.
Nov 23 21:13:44 txtechnician-hp-suse systemd-cryptsetup[681]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Nov 23 21:13:44 txtechnician-hp-suse systemd-cryptsetup[681]: Too many attempts to activate; giving up.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: systemd-cryptsetup@cr_swap.service: Main process exited, code=exited, status=1/FAILURE
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: systemd-cryptsetup@cr_swap.service: Failed with result 'exit-code'.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: Failed to start Cryptography Setup for cr_swap.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: Dependency failed for Local Encrypted Volumes.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: systemd-cryptsetup@cr_swap.service: Consumed 6.368s CPU time.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: run-credentials-systemd\x2dcryptsetup\x40cr_swap.service.mount: Deactivated successfully.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: Reached target System Initialization.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: Reached target Basic System.
Nov 23 21:13:44 txtechnician-hp-suse systemd[1]: System is tainted: unmerged-bin
The only thing that stands out is
Nov 22 17:02:30 localhost systemd[1]: plymouth-start.service: Deactivated successfully.
Nov 22 17:02:30 localhost systemd[1]: plymouth-start.service: Unit process 356 (plymouthd) remains running after unit stopped.
...
Nov 22 17:02:37 localhost systemd[1]: plymouth-start.service: Found left-over process 356 (plymouthd) in control group while starting unit. Ignoring.
Nov 22 17:02:37 localhost systemd[1]: plymouth-start.service: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Nov 22 17:02:37 localhost systemd[1]: Starting Show Plymouth Boot Screen...
I do not have this warning on my Tumbleweed VMs. It is possible that there are two plymouthd processes that somehow conflict. That will not explain swap issues (swap should usually be decrypted in initrd).
I think I already asked this without any response - could anybody who does have this problem try booting with plymouth.enable=0 kernel parameter to test, whether the problem is in Plymouth or somewhere else.
1 Like
Adding plymouth.enable=0 lets me normally boot my system, as does removing splash=silentand quiet`. So disabling plymouth works until a updated version of plymouth is available.
1 Like
That’s nice and that might (no, I’m pretty sure) fix my problem as well since rolling back fix my issue where plymouth is on older version. But I’ll wait till wednesday since that’s day I do my weekly updates and hope before that time comes our problems will get fixed
Same problem here after updating to the latest snapshot, last update before that was ~ 2weeks before. The work-around to disable plymouth for boot also works for me.
Had a look in Bugzilla and found:
- Bug 1233669 - Boot screen not showing password prompt
- Bug 1233373 - unlocking luks volumes leaves hanging systemd-tty-ask-password-agent
Saw the last log before the problem and the log with the problem and diffed the after removing the time-stamps and that revealed:
systemd-coredump[585]: Process 411 (plymouthd) of user 0 terminated abnormally with signal 11/SEGV, processing...
systemd-coredump[585]: Failed to connect to coredump service: No such file or directory
systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: plymouth-start.service: Failed with result 'core-dump'.
Not sure if anybody else is seeing this SGEV segmentation fault?
OK. Then it is Plymouth bug and is something for bug report. Not sure whether it is already reported.
It is about Plymouth crash, not about Plymouth failing to pass the LUKS password to the systemd.