Boot method: USB (DVD image)
Image version: debian-trixie-DI-alpha1 2024-12-30 and Trixie weekly 2025-04-14
Date: <Date and time of the install>
Machine: Custom build (N/A)
Partitions:
Output of df -Tl
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev devtmpfs 16351004 0 16351004 0% /dev
tmpfs tmpfs 3278108 1796 3276312 1% /run
/dev/sda2 xfs 209612772 12163380 197449392 6% /
tmpfs tmpfs 16390528 8484 16382044 1% /dev/shm
efivarfs efivarfs 128 63 61 51%
/sys/firmware/efi/efivars
tmpfs tmpfs 5120 12 5108 1% /run/lock
tmpfs tmpfs 16390532 3652 16386880 1% /tmp
tmpfs tmpfs 1024 0 1024 0%
/run/credentials/systemd-journald.service
/dev/sda1 vfat 1046508 4500 1042008 1% /boot/efi
/dev/mapper/debiancrypt xfs 289184776 5654112 283530664 2% /home
tmpfs tmpfs 3278104 144 3277960 1%
/run/user/1000
(Configuration is simple. Small EFI partition, large partition for OS root,
then the rest of the drive is a luks encrypted partition for /home.)
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card: [O]
Configure network: [O]
Detect media: [O]
Load installer modules: [O]
Clock/timezone setup: [O]
User/password setup: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system: [O]
Install tasks: [O]
Install boot loader: [O]
Overall install: [O]
Comments/Problems:
Following the installation process to create the partition layout mentioned
above works in previous Bookworm stable via the installer without any user
intervention. Unfortunately in Trixie it seems that it does not. It should
request the password to unlock the volume on the console during startup,
however, the request never shows up. Typing blindly also does not work. After
some time (30 seconds I guess) it eventually times out and the system enters
maintenance mode. If I log in during maintenance mode I can manually open the
encryption and mount the partition and then continue the boot process without
further error.
In journalctl I can see that it says forwarding password request to Plymouth
first. I see these relevant lines in journalctl:
debian systemd[1]: Started systemd-ask-password-wall.path - Forward Password
Requests to Wall Directory Watch.
debian systemd[1]: systemd-ask-password-console.path - Dispatch Password
Requests to Console Directory Watch was skipped because of an unmet condition
check (ConditionPathExists=!/run/plymouth/pid).
debian systemd[1]: Started systemd-ask-password-plymouth.path - Forward
Password Requests to Plymouth Directory Watch.
debian systemd[1]: systemd-ask-password-console.path - Dispatch Password
Requests to Console Directory Watch was skipped because of an unmet condition
check (ConditionPathExists=!/run/plymouth/pid).
debian systemd[1]: systemd-ask-password-console.path - Dispatch Password
Requests to Console Directory Watch was skipped because of an unmet condition
check (ConditionPathExists=!/run/plymouth/pid).
Out of curiosity I tried removing Plymouth (I wasn't sure how else to modify
this behavior) but it still does not show a password request, nor does typing
blindly work then either.
I knew that most people encrypt the full disk and presumed that most testing of
this function was done with full disk encryption, so, in testing a theory, I
added initramfs to the crypttab entry for my non-root partition. With this it
asked for the password during initramfs instead of after and with this
parameter added it now correctly asks for the password during startup.
I assume the issue is Plymouth is failing to handle the password request
because it isn't even showing up. I still see text only at these stages of the
startup process, so I guess something is missing in the default installation.
(I had not added or removed any packages from what the installer produced at
that stage of the process.) Perhaps plymouth-themes was missing or something
was misconfigured. It should fall back to the console, but it seems to not do
so, thus the system waits until it times out.