The following initrd info may or may not be pertinent to this bug in respect to how initrds may be created in future versions of Debian...
> To: debian-de...@lists.debian.org > Cc: debian-de...@lists.debian.org > Subject: Re: Unlock LUKS with login/password > From: Marco d'Itri <m...@linux.it> > Date: Fri, 10 Mar 2023 17:57:40 +0100 > On Mar 10, Stephan Verbücheln <verbuech...@posteo.de> wrote: > > > On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote: > > > In the future the initramfs will (usually) be static as well. > > Can you provide more information on that? > Due to multiple reasons, mostly related to secure boot and boot > attestation, there is significant interest by distributions in > providing > static and signed initrds. > BTW, I have been informed that "initramfs" is an obsolete term and > that > we are back to "initrd" like in the '90s. > > Some people in Debian are interested in working on > https://github.com/systemd/mkosi-initrd, which will provide a static > initrd built from system binaries and extensible using the > systemd-sysext and future systemd-sysconf mechanisms for things like > SAN boot or sshd in the initrd. > Do not look too hard at it at this point: the upstream developers are > going to make soon a new release with significant changes. > > I expect that people interested in working on initramfs-tools can > probably extend it with little work to generate static images > suitable > for the most common deployments. > People with uncommon ones will have to do without the modern boot > attestation features or else sign their own images (which will be > very > easy once I, or somebody else, will have packaged sbctl). > Obviously there are no new requirements for the systems without > secure > boot. > > -- > ciao, > Marco >
