Package: dracut-core
Version: 106-6
Hi,
This bug is still present in Debian trixie (current stable, 13.5
as of 2026-05-20), which still ships dracut 106. The upstream fix
(renaming the systemd-sysusers module so it runs last, plus a
follow-up removing the (g)shadow file it created) landed in
dracut-ng and is part of the 107 release.
Could this be addressed for trixie users in one of two ways:
1) backport the upstream patches onto 106 as a stable update
via the next trixie point release, or
2) make a newer dracut available to trixie users via
trixie-backports (forky currently has 110-12).
Motivation: this is not only an issue in the emergency shell
scenario the bug was originally filed for. It also breaks an
important practical use case -- early-userspace remote access
via dracut-sshd (and similar setups) used to unlock
LUKS-encrypted root filesystems over SSH on headless machines.
With dracut 106 as shipped in trixie, the systemd-sysusers
module bakes `root:!unprovisioned:...` into the initramfs
`/etc/shadow`, which sshd then treats as a locked account and
rejects public key authentication. The net effect is that a
Debian stable user who follows the standard dracut-sshd setup
cannot unlock their encrypted root remotely -- they have to
physically attend the machine, which defeats the point of the
setup.
For reference, this has now also been documented on the
dracut-sshd side:
https://github.com/gsauthof/dracut-sshd/issues/92#issuecomment-3583525213
Thanks for considering.
--
Regards,
Thomas
