Boot from LUKS device freezes after password entry

Nocte

Hey all
lately I am encountering a bit of a strange behavior which seams to be similar to this one. I am using an dell xps 13 with Solus for about 4 years now. The SSD inside has been LUKS encrypted from the beginning. when I am starting the laptop after seeing the DELL logo I am asked for the password to decrypt the SSD. as soon as i enter it the screen freezes and nothing is happening anymore. I have validated the password being correct by trying to enter a wrong one which does not cause a freeze. Also after 3 tries some systemd-cryptsetup process dies or something and I have do reboot (probably intended behavior?)
Furthermore what i find quite interesting is that i am still able to boot normally when choosing an ancient 4.9 Linux kernel.

Has anyone encounter similar issues or any hints for debugging?

Best regards

greengem70

Same issue. Note you can boot from a SolusLiveCD to manually mount/unlock the LUKS partition to retrieve any data - pending a fix. The partition is readable... but doesn't seem to be bootable.

Nocte

thx greengem70
i also noticed that it is not really a LUKS issue as it still can be decrypted and mointed as usual when using a live environment or much older kernel.

still i am curious what is happening here. i already figured out that supposedly systemd-boot should be working after the encryption.
btw. i think i am properly using an EFI boot but i disabled secure boot. does this may cause any issues?

greengem70

For me, it is something in the mandatory updates... no other changes. Went back to a snapshot ... fine... install 500odd Mb of mandatory updates and it fails. Have repeated and the updates definitely are the issue. Not updating for now.

Staudey

greengem70 For me, it is something in the mandatory updates... no other changes.

Please install all updates, not just the mandatory ones, especially after a new installation. The ability to pick and choose updates has been remove in newer versions anyway, because it does more harm than good.

greengem70

Just looking through the updates...
OS Prober 1.79-6
Grub2 2.04-29
Might be related ... the volume is intact (readable). But does not boot.

greengem70

Staudey Yes - already the case. The only updates I have are the mandatory ones.

Nocte

reporting back after some tinkering with the rollback. thx @Staudey .
sadly it did not produce the result i hoped for. and actually i do not remember having done an update just before the issue came to be.

current state: booting with latest kernel still broken.

maybe someone does recognize any issue in the boot config?

 $ cat /boot/loader/entries/Solus-current-5.14.16-205.conf 
title Solus 4.3 Fortitude
linux /EFI/com.solus-project/kernel-com.solus-project.current.5.14.16-205
initrd /EFI/com.solus-project/initrd-com.solus-project.current.5.14.16-205
options root=UUID=1bf8fb62-8695-463b-8577-a0de85f400e8 rd.luks.uuid=d1751b22-4c17-49e9-ac3f-48aeed57a26f quiet loglevel=3 splash systemd.show_status=false rw radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 resume=UUID=6c1b8fc1-408e-4d89-ba9e-b541831ab374

 $ lsblk -o name,uuid | tail -n 6
nvme0n1                                       
├─nvme0n1p1                                   F8A5-4541
└─nvme0n1p2                                   d1751b22-4c17-49e9-ac3f-48aeed57a26f
  └─luks-d1751b22-4c17-49e9-ac3f-48aeed57a26f 9M3glA-CUeH-pXj8-P85i-cZUm-8LsQ-N2XnKq
    ├─SolusSystem-Swap                        c7efcdb6-b27b-4b8b-a553-87cdd00409ab
    └─SolusSystem-Root                        1bf8fb62-8695-463b-8577-a0de85f400e8

sorry that i am just guessing here...

ReillyBrogan

When you're at the screen for kernel/boot option selection hit e and then edit the command line to remove the quiet and splash options. Then change loglevel=3 to loglevel=5 and systemd.show_status=false to systemd.show_status=true

Also, the most recent kernel is 5.14.21-210, not 5.14.16-205, so your system is indeed not on the latest kernel. If you updated by mounting your drive from another system note that you also need to mount the boot partition to /boot and then run usysconf run -f after you run updates in order to update your boot partition.

Nocte

well...
especially the systemd config made visible what really is happening behind the scene. and it turns out that it was trying to find a device UUID=6c1b8fc1-408e-4d89-ba9e-b541831ab374 at some remote target. but it does not exist as lsblk shows. i had the idea before that this resume thing might be something wired. but the actual fun part is that while systemd tries to find the device it does so with a timeout out of no limit...

so conclusion:

i messed up myself
the solution is astonishingly simple as soon as one sees what goes on

i am happy to report :

$ uname -r
5.14.21-210.current

its running and thanks a lot for all the input !

greengem70

I was on an older kernel (somehow the updates had not been applied).

sudo eopkg install linux-current
sudo clr-boot-manager update
still booting to old kernel so did a...
sudo eopkg install --reinstall linux-current
now on 5.14.21.210 reboots fine. Not done any other updates.

applied mandatory updates and boom... hangs again. I am on the latest kernel. Selecting alternate boot entry and booting to 5.14.7.198 also hangs.