Dear Maintainer,

When building an initramfs with dracut, it is not possible to access its
emergency shell during boot. Instead, there is an error saying "Cannot
open access to console, the root account is locked."

The reason for this appears to be that the systemd-sysusers module adds
a locked root user entry to /etc/shadow ("!unprovisioned").

The issue has already been fixed upstream by renaming the module so that
it executes as late as possible: https://github.com/dracut-ng/dracut-ng/pull/1212/files

The upstream change makes it sound like this only applies to niche
scenarios, but as far as I can tell, the emergency shell is broken in
any configuration, hence the elevated severity.

Dear all,

I can reproduce this bug with Debian stable. lsinitrd provides

lsinitrd /rootfs/initrd.img /etc/shadow
root:!unprovisioned:20336::::::


Should the bug be not filled against the dracut package.

Quirin

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.