Wednesday 8 December 2021

Re: Revisiting default initramfs compression



On Thu, 9 Dec 2021 at 10:02, Julian Andres Klode <julian.klode@canonical.com> wrote:
On Thu, Dec 09, 2021 at 09:21:35AM +1300, Michael Hudson-Doyle wrote:
> On Thu, 9 Dec 2021 at 08:52, Julian Andres Klode <julian.klode@canonical.com>
> wrote:
>
> > The most interesting solution would be to create the cpip archive
> > dynamically by giving cpio a list of files over a pipe that we create
> > dynamically in the hooks as we copy files in, then pipe that to zstd
> > --adapt; then it would all work super nicely.
> >
>
> If we're going to spend significant effort, I think I'd prefer we try to
> find a way to not recompress the modules when making the initrd at all, at
> least for MODULES=most builds. We could just ship a zstd -19'ed
> MODULES=most cpio archive in the kernel packaging and have four layers of
> initrd (intel firmware, amd64 firmware, modules, everything else) but that
> would bloat the kernel package rather a lot...

I'd kind of like us to ship "default" initramfs in like linux-initrd-$uname-r
and linux-initrd-generic and so on. Maybe even signed somehow so that
the kernel can verify its integrity when booting. Such that booting with
authenticated FDE is fully authenticated.

But oh well, those are all long term wishes :)

Yeah, let's not let that sort of thing distract us from fixing the issues that lead to this thread (but also let's not put *too* much effort into this).

Cheers,
mwh