Bug#778849: Support restoring initrd on shutdown and pivoting into it
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-devel@lists.debian.org
> Cc: debian-devel@lists.debian.org
> Subject: Re: Unlock LUKS with login/password
> From: Marco d'Itri <md@Linux.IT>
> Date: Fri, 10 Mar 2023 17:57:40 +0100
> On Mar 10, Stephan Verbücheln <verbuecheln@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
>
Reply to: