Bug#1114943: release-notes: Using dracut, debug shell access with rd.break fails
Package: release-notes
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was upgrading from bookworm to trixie while using the non-default
initramfs creator "dracut" (as packaged in Debian). I had
an otherwise straightforward LVM-on-LUKS setup with a TPM2-based
LUKS unlocking method added (using systemd-cryptsetup in bookworm).
It turned out that the initramfs created by trixie's dracut had
a problem unlocking LUKS and hung in initramfs, waiting forever for the
device containing the root filesystem to come up.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Booting with the previous kernel+initramfs still worked, but it
obviously did not allow me to get any information on what was going
wrong with the new trixie-generated one. So I tried to trigger the
dracut initramfs emergency shell in order to investigate.
I tried the boot parameter "systemd.unit=emergency.target",
and also "rd.break", with various values like "rd.break=pre-mount".
* What was the outcome of this action?
All attempts either hung the same as a regular boot attempt or
produced the message:
Cannot open access to console, the root account is locked.
See sulogin(8) to continue.
* What outcome did you expect instead?
I expected to get a root shell on the console within the initramfs
environment, in order to start troubleshooting the LUKS unlocking issue.
* What was the workaround?
Once I added "rd.break SYSTEMD_SULOGIN_FORCE=1" to the kernel command line,
I managed to get the root shell I expected and could start investigating
what was going wrong with LUKS unlocking.
I knew about this because RedHat/Fedora used to have the same issue when a root
account is left locked on installation:
https://bugzilla.redhat.com/show_bug.cgi?id=1763160
However, I did have a passworded root account which should have been
usable on the local console.
Apparently dracut-generated initramfs uses a synthesized minimal
/etc/passwd + /etc/shadow, instead of one with the root password hash copied
from the regular /etc/shadow. Or maybe my system had a root password
hash that was too old for sulogin to handle, or something...
Anyway, in chapter 4.1.4.2 of the Release Notes, it might be useful to mention
the possible need to add "SYSTEMD_SULOGIN_FORCE=1" to the kernel command
line if sulogin says "the root account is locked". This information is
not exactly easy to find if you don't already know about it: neither
the sulogin(8) nor the dracut.cmdline(7) man pages do mention it at all.
An alternative solution would be a kernel boot parameter:
init="/sbin/sulogin --force"
But it contains whitespace and so requires quoting, which increases the
risk of mistakes. SYSTEMD_SULOGIN_FORCE=1 is a whitespace-free
equivalent.
Related upstream changes, newest first:
https://github.com/systemd/systemd/commit/fecbce1fc654076a2fc0922e6d36e5300ea04cdf
https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c
Reply to: