Arch Linux

Have experienced the same issue with just ext4 on top of LUKS

mkinitpcio:
base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystems

minimal kernel options:
rw luks.name=b8c28c67-aeda-4255-b5e4-4c8265a1811a=root root=/dev/mapper/root

I receive a passphrase prompt on 233 but not on 234, in which systemd-cryptsetup@root.service fails instantly, dumping me to emergency mode (which strangely does not give me a shell).

I don't an emergency shell either, just a dead end. Regrettably, I'm extremely busy until Wednesday and cannot debug this further, but it's worth mentioning that this has also been discussed in arch-general today too.

Same issue occurred for me as well; took me completely by surprise. Frustratingly enough, I was also not presented with an emergency shell nor access the system journal. I'm glad I had an Arch Live USB drive on hand and I still had the older systemd-233.75-3 package in cache. For the record, I am also running ext4 with systemd-cryptsetup on top of LUKS.

Even after chrooting into the dead machine, I could not find any trace of what went wrong with systemd-cryptsetup. Hope someone else might have better luck debugging this.

There's no trace after chrooting because journald never gets to persist anything -- because your disk can't even get mounted! (I kinda looked through journalctl a while before I realized this).

TBH, I've absolute no idea how to debug this, since it's purely happening inside the rd environment.

Could you try adding the timeout parameter to crypttab or luks.options try the values 30s 0s and 0 please.

Prepended the timeout to the kernel options. Values of '30s' and '0s' work normally, '0' fails as before

Eg:
rw luks.options=timeout=30s luks.name=b8c28c67-aeda-4255-b5e4-4c8265a1811a=root root=/dev/mapper/root

Perhaps ask upstream if the change to default behavior was intentional or accidental.
It is not mentioned in the NEWS file for 234 and the documentation matches 233's behavior not 234.

Since there's nothing about it in the news, I've posted an issue upstream:

https://github.com/systemd/systemd/issues/6381

I'm not personally using crypttab, so the timeout used should be the default, not one specified by me. Is the default simply "not working"?

From the reports the default behavior if kernel options is used instead of crypttab has changed from 233 to 234.
If crypttab is used without specifying the timeout option the behavior is the same between 233 and 234.
man 5 crypttab
timeout=
Specifies the timeout for querying for a password. If no unit is
specified, seconds is used. Supported units are s, ms, us, min, h,
d. A timeout of 0 waits indefinitely (which is the default).
This documentation appears accurate apart from the case of 234 using kernel options again going from reports.

Should be fixed by https://github.com/systemd/systemd/commit/4a06cbf8387555c7c04a1ee6f0c5a6f858bf4b19 or merge including doc change
https://github.com/systemd/systemd/commit/e758bc9132305b4398471bf7002ccd8b45b2b5a4

Pushed 234.0-3 backporting this change to [testing]. Leaving closing the issue to Christian.

Thanks Bartłomiej!

I've just hit this issue with systemd 234.11-1 . Adding luks.options=timeout=30s to my cmdline made it possible to boot the system again.

Same here, systemd 234.11-1 fails to boot from an encrypted root partition (meaning there is no password prompt) without luks.options=timeout=30s in the kernel commandline.

I guess that you are using regular encrypt hook, non sd-encrypt?

I'm using a systemd-based mkinitcpio with sd-encrypt.

For me:
HOOKS="base systemd autodetect modconf block keyboard sd-encrypt sd-lvm2 filesystems fsck"

What does /etc/crypttab.initramfs look like? What kernel parameters do you use?

There is no /etc/crypttab.initramfs on my system (or should this file be in the initrd?)

Kernel Commandline looks like this:
rd.luks.uuid=c3078eb3-9f67-4ae0-ae2c-32bbcd9eedf7 rd.lvm.lv=xps13/arch.root rd.lvm.lv=xps13/arch.swap luks.options=timeout=30s resume=UUID=ce9a6eec-b6ef-48fc-a107-9ee030578c41 root=UUID=fcb4a880-b970-46e0-8e62-063e935eccc3 elevator=noop ipv6.disable=1 pcie_aspm=force rw quiet loglevel=3 systemd.show_status=false nvme_core.default_ps_max_latency_us=180000

[edit]To clarify: The luks.options=timeout=30s was added as a workaround to get a booting system again, it wasn't there in my original kernel commandline.[/edit]

And for the sake of completeness here are my initrd hooks:
HOOKS="systemd autodetect modconf block keyboard keymap sd-encrypt sd-lvm2 filesystems fsck"

It works for you because you're using `luks.options=timeout=30s`. The problem is that the default is broken when not specifying this.

@hobarrera seiichiro0185 already noted that https://bugs.archlinux.org/task/54825#comment159710
Using /etc/crypttab.initramfs also works without any timeout specified
Edit:
In the upstream bug the screenshots in response to the request for information since the report was reopened are both from systems using dracut.
Could an affected arch user post similar screenshots if textual output is not available to the upstream report.

I have had the same issue. Chroot from Live-USB and downgrading solved the problem.

I haven't met this bug, maybe the option, `luks.key=`, also works? Refer https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#luks.key . I use btrfs on top of LUKS, and here is the cmdline in file /etc/default/grub: `luks.uuid=d97261f8-38cc-42be-9cc6-745489831a3a luks.name=d97261f8-38cc-42be-9cc6-745489831a3a=dcroot luks.key=/.ck.bin acpi_osi="!Windows 2012"`

Alvin: You're using a key rather than a passphrase? Or both?

@hobarrera Just a key. I enter the passphrase in the grub phase, and then unlock the entire disk by a key automaticly.

Well then, of course you haven't met this issues, because you CAN'T meet this issue. In your scenario, the prompt that's failing to show up is never shown up.

Has anyone tried a possible fix https://github.com/systemd/systemd/issues/6381#issuecomment-318881151 ?
Edit:
Should be this commit https://github.com/andrewsoutar/systemd/commit/e9f4cfe8c4db23bd8048aa29909a53b9d33efb41

I'm the author of that particular patch. It's worked for me, but that doesn't mean very much... If anyone wants to test it, I've got a PKGBUILD up at https://github.com/andrewsoutar/pkgbuild-systemd-fix-6381 .
EDIT: Just got confirmation from another user on Github that this worked for him.

eworm or Barthalion could post built packages with the patch applied on pkgbuild.com if they think the patch is promising.
Otherwise wait for upstream to review the patch.