I've been doing almost the same exact thing for a while, except on Arch and with a different EDID than my actual display drive my handheld that I stream to is 16:10 rather than 16:9 like my actual monitor. After a couple of months something changed (maybe a kernel update, although I never fully tracked it down) where the kernel no longer respects the parameter about which display to use for the initial LUKS decrypt and tries to use the fake display no matter that, which prevents me from unlocking it until after a timeout of a few minutes. I've made this somewhat less annoying by setting up unlocking via ssh on a local IP so that I can just initiate a reboot and then do other things around the house without having to wait around next to it until it times out and falls back to the real display, but it would be really nice to not need to wait in the times when I don't have any need to do anything else for a few minutes. Did you ever happen to run into this timeout issue, and if so, do you know how to fix it?

▲

BatteryMountain a day ago | parent [-]

If you have a tpm (or virtual tpm), you can enroll your passphrase for auto unlock. When sealing the tpm slot, you can decide how much should be sealed: kernel version, drivers, firmware updates, hardware changes etc.. meaning a kernel update can break the seal and ask for passphrase if you included kernel version in the seal. You can set it so the kernel/driver updates won't break your tpm seals. It's usually just one command to reseal the tpm values and the auto-unlock should work again, but it wastes time like you experienced. I use systemd-cryptenroll and a couple boot args.

If you have claude code installed (or ssh access for it), you can ask it to investigate your entire boot chain. It can find and fix it in 5 minutes.

	▲	saghm 18 hours ago \| parent [-]
		I'm not sure if I'm misunderstanding what you're suggesting, but my issue isn't that I want unlocking to be even more streamlined (since I'm fine with what I have and don't want fully auto unlock); it's just that I don't want the timeout that somehow started happening before it's even letting me manually unlock. And yeah, I did try out various LLMs (including Claude) when it first started happening, but none of them were able to point me towards anything definitive about the cause, let alone the fix. In general I think it might be worth giving someone asking a question about something like this the benefit of the doubt about whether they've tried it, especially if you have outsized assumptions about how likely they are to solve problems. My experience is that when someone mentions having an issue, telling them "just ask Claude/Codex/etc." doesn't tend to end up being a very valuable contribution to discussions; people who are open to using LLMs for things will almost definitely have already done so, and people who haven't already are a lot more likely no to have done so for other reasons than the idea not having occurred to them. It's pretty hard to go more than even a few minutes into any sort of discussion about tech nowadays without someone bringing them up, so I think it's a pretty safe assumption that most people are well aware of them and considered them for whatever problem they're having. To be clear, I'm not trying to berate you or anything but genuinely give feedback that might be helpful for you when trying to give advice on things like this in the future. Trying to give advice in a way that people will be receptive to can be difficult, especially when they're strangers on the internet, but I also think it's a a valuable way to spend time compared to a lot of other ways to spend time online, so I think it's worthwhile to invest time and effort into figuring out the best ways of doing it.