XPost: linux.debian.bugs.dist 
 From: Matti.Kurkela@welho.com 
  
 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/fecbce1fc654076a2fc092 
 e6d36e5300ea04cdf 
 https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614b 
 4c2d90f8d91cce66c 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)