[SOLVED] System unable to unlock encrypted partition

alba4k · 2026-03-18 09:35:13

While trying to debug a different (unrelated!) issue, Iadded

modprobe.blacklist=tpm_tis,tpm

to my kernel parameters. However, my system is now unable to boot, even after removing it and running "mkinitcpio -P" (as I have a uki built by mkinitcpio) and the boot is stuck on "a start job is running for /dev/mapper/luks" and "a start job is running for (UUID path)"

I have tried wiping and re-enrolling the TPM, but that shouldn't matter as it's working just fine from the live arch install medium.

I have also tried removing

tpm2-device=auto

from my luks options, which also didn't help.

I really have no idea what could be causing this issue, as everything should be working fine (and is working fine, as I can mount that partition from the live env) but isn't

So now whenever I try to boot all I see is this

Last edited by alba4k (2026-04-04 10:55:15)

virtual_ghost · 2026-03-18 10:10:22

How does your HOOKS line in mkinitcpio.conf look currently?
ensure your /etc/mkinitcpio.d/linux.preset (or whichever kernel you use) is actually pointing to the correct EFI destination. If it's rebuilding a file in /boot/ but your motherboard is booting a stale UKI from /efi/EFI/Linux/, your changes won't take effect.

Last edited by virtual_ghost (2026-03-18 10:10:52)

alba4k · 2026-03-18 10:22:51

The uki is being updated, according to objcopy and to the fact that I later disabled the splash from it.

My hooks look like this:

HOOKS=(systemd autodetect microcode kms keyboard modconf block sd-encrypt filedystems)

5hridhyan · 2026-03-18 10:30:08

did you typed the hooks manually in the post? or is it copy-paste? if copy-pasted, then you have a typo, it should be filesystems not filedsystem.
also try adding `sd-vconsole` after `keyboard` in your hooks, ensures that if it fails again, you can actually type in the emergency shell to check logs...

Edit:
also like while in the Live env/chroot, check if you have any files in /etc/modprobe.d/ that you might have created during debugging,I guess even if you removed the kernel parameter, a .conf file in that directory will be baked into the Uki by the modconf hook...

Last edited by 5hridhyan (2026-03-18 10:30:59)

alba4k · 2026-03-18 11:18:08

yeah the filesystems thing is just a typo (as I can't easily copy paste from the live)

There are no new configs in /etc/modprobe.d and the uki doesn't contain that blacklist

seth · 2026-03-18 14:21:29

From the install iso (no/before chroot)

lsblk -f | curl -F 'file=@-' https://0x0.st

Can you still open the luks container from there?

In doubt try to explicitly add "nvme" to the MODULES array

alba4k · 2026-03-18 18:22:40

Yes I can still open (and mount) the partition, both with the tpm wiped (and thus by using my passworr) and with it enrolled (and thus with no need for any password)

All UUIDs should be fine as I did not touch them anywhere, but here you go: https://0x0.st/P91K.txt

adding nvme to MODULES did not help tho

alba4k · 2026-03-18 18:32:02

Uhm, I'm getting this after trying to clear the TPM from the bios:

https://quickshare.samsungcloud.com/gvngFq8nBG7j

seth · 2026-03-18 21:00:03

after trying to clear the TPM from the bios:

Stop flailing around, you're gonna end up running into a disaster.
It's not the TPM - the nvme partition doesn't show up.
Can you still open the luks container w/ the password?

What is on nvme0n1p3 (looks like you might have two ESPs)?
Remove the "quiet" parameter and add "ignore_loglevel" instead (don't use "debug", systemd will spam the system into oblivion)

alba4k · 2026-03-23 18:48:52

Hey, sorry for the late response, I've been a bit busy

the partition is just fine, I could open it at all times. I'm guessing the issue is I forgot to wipe it (as I got both slot 1 and 2 being wiped when now trying). I've now re-enrolled and it unlocks fine uisng the tpm again, so no disaster for the time being.

The second ESP is for Windows, that's intentional

using ignore_loglevel: https://quickshare.samsungcloud.com/bNan4XaQRafs

If nothing works, I might consider removing everything kernel-related and starting over, but I'm not sure that'd fix everything or if I would need to re-make the partition (which might be a bit more annoying)

seth · 2026-03-23 21:41:12

Does the debug_shell or init=/bin/sh allow you to login and obtain the full journal so we get to see what happens during the first 2.7 seconds and maybe even lsblk and lspci?
https://wiki.archlinux.org/title/Genera … ery_shells

alba4k · 2026-03-23 21:48:01

I can try but can't say I have high hopes. how would the kernel find /bin/sh if it can't even access the disk?

seth · 2026-03-23 21:51:44

In the initramfs

alba4k · 2026-03-25 11:32:37

I can get the following journal while in the chroot, probably containing the last good boot: https://0x0.st/Pfeo.txt

No luck with the sh init though? it still seems to launch systemd?

seth · 2026-03-25 13:28:48

That will unfortunately not tell us why the nvme isn't detected in the current boot.
Add "rootdelay=10 boot_delay=50" to the kernel parameters, the first one will just unconditionally wait 10s before trying to mount the root partition, the second one will stall every message by 50ms what's too fast for you, but you should be able to record the boot process on a (phone) camera.
For that use a tripod, if you do do not have a tripod, makeshift one out of books: -\_
Otherwise the text will likely be still too fast for readable handheld recording.

You can try only "rootdelay=10" first, if that makes the nvme show up in time there's no reason to slow down the boot afterwards.

alba4k · 2026-03-30 15:01:37

That just seems to make the boot hang at the "XPS" screen, I get no output at all

However, it's getting past POST, as I see the "Secured with Dell Safe BIOS" screen

Using just "rootdelay=10" seems to make no difference (I.e. I get the usual output and the system still doesn't mount the drive. I didn't notice if it actually took 10s longer or not to get to that point tho)

seth · 2026-03-30 15:08:44

https://wiki.archlinux.org/title/Genera … l_messages
The boot_delay will significantly slow down the boot process, whether you see the messages or not (eg. if there's a quiet parameter)
There're gonna be >2k lines in a boot, so there'll be > 100s of pure delay on a 50ms interval

alba4k · 2026-04-01 17:38:31

https://quickshare.samsungcloud.com/ec6uaFvjEkYf

you're right, something happened after 7 minutes or so

the video came out quite blurry (dark room as there were too many reflections otherwise) but every single line should be readable if you catch the right frame ?

let me know if you need anything else!

Last edited by alba4k (2026-04-01 17:39:54)

seth · 2026-04-01 19:54:57

The nvme shows up…

All UUIDs should be fine

Yes "should" …

The UUID is 65122208-30dd-4061-b3d3-be44937ebbf4 but your waiting for 65122209-30dd-4061-b3d3-be44937ebbf4

alba4k · 2026-04-01 20:23:05

Yeah, that was it. I guess I'll go get an eye and brain transplant tomorrow

I checked that so many times that I probably ended up getting tunnel vision and missed it over and over. should've just sent the codeine to begin with...

Thank you so much for the pair of fresh eyes and sorry for the wasted time.. I really have no clue when/how I changed that, as I doubt the uuid changed out of the blue haha

Last edited by alba4k (2026-04-01 20:23:19)

seth · 2026-04-01 20:27:51

sorry for the wasted time.

You learned
* how to produce more kernel messages
* how to slow down kernel messages
* how to makeshift a tripod
* about shouldland (I HOPE!)
No time was wasted

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

alba4k · 2026-04-01 21:09:09

I guess I did

Back to trying to fix that reboot-after-suspend, I guess

btw, if I may, I know it's a bit off topic but is this your job? Since I noticed you seem to be very active in these forums

Last edited by alba4k (2026-04-01 21:13:51)

seth · 2026-04-01 21:36:57

Personal entertainment.
It's more productive than watching TV or solving sudokus to keep your brain away from the news.
I'm not paid or employed to do this.

Arch Linux

#1 2026-03-18 09:35:13

[SOLVED] System unable to unlock encrypted partition

#2 2026-03-18 10:10:22

Re: [SOLVED] System unable to unlock encrypted partition

#3 2026-03-18 10:22:51

Re: [SOLVED] System unable to unlock encrypted partition

#4 2026-03-18 10:30:08

Re: [SOLVED] System unable to unlock encrypted partition

#5 2026-03-18 11:18:08

Re: [SOLVED] System unable to unlock encrypted partition

#6 2026-03-18 14:21:29

Re: [SOLVED] System unable to unlock encrypted partition

#7 2026-03-18 18:22:40

Re: [SOLVED] System unable to unlock encrypted partition

#8 2026-03-18 18:32:02

Re: [SOLVED] System unable to unlock encrypted partition

#9 2026-03-18 21:00:03

Re: [SOLVED] System unable to unlock encrypted partition

#10 2026-03-23 18:48:52

Re: [SOLVED] System unable to unlock encrypted partition

#11 2026-03-23 21:41:12

Re: [SOLVED] System unable to unlock encrypted partition

#12 2026-03-23 21:48:01

Re: [SOLVED] System unable to unlock encrypted partition

#13 2026-03-23 21:51:44

Re: [SOLVED] System unable to unlock encrypted partition

#14 2026-03-25 11:32:37

Re: [SOLVED] System unable to unlock encrypted partition

#15 2026-03-25 13:28:48

Re: [SOLVED] System unable to unlock encrypted partition

#16 2026-03-30 15:01:37

Re: [SOLVED] System unable to unlock encrypted partition

#17 2026-03-30 15:08:44

Re: [SOLVED] System unable to unlock encrypted partition

#18 2026-04-01 17:38:31

Re: [SOLVED] System unable to unlock encrypted partition

#19 2026-04-01 19:54:57

Re: [SOLVED] System unable to unlock encrypted partition

#20 2026-04-01 20:23:05

Re: [SOLVED] System unable to unlock encrypted partition

#21 2026-04-01 20:27:51

Re: [SOLVED] System unable to unlock encrypted partition

#22 2026-04-01 21:09:09

Re: [SOLVED] System unable to unlock encrypted partition

#23 2026-04-01 21:36:57

Re: [SOLVED] System unable to unlock encrypted partition

Board footer