<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Dec 2021 at 10:02, Julian Andres Klode <<a href="mailto:julian.klode@canonical.com">julian.klode@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 09, 2021 at 09:21:35AM +1300, Michael Hudson-Doyle wrote:<br>
> On Thu, 9 Dec 2021 at 08:52, Julian Andres Klode <<a href="mailto:julian.klode@canonical.com" target="_blank">julian.klode@canonical.com</a>><br>
> wrote:<br>
> <br>
> > The most interesting solution would be to create the cpip archive<br>
> > dynamically by giving cpio a list of files over a pipe that we create<br>
> > dynamically in the hooks as we copy files in, then pipe that to zstd<br>
> > --adapt; then it would all work super nicely.<br>
> ><br>
> <br>
> If we're going to spend significant effort, I think I'd prefer we try to<br>
> find a way to not recompress the modules when making the initrd at all, at<br>
> least for MODULES=most builds. We could just ship a zstd -19'ed<br>
> MODULES=most cpio archive in the kernel packaging and have four layers of<br>
> initrd (intel firmware, amd64 firmware, modules, everything else) but that<br>
> would bloat the kernel package rather a lot...<br>
<br>
I'd kind of like us to ship "default" initramfs in like linux-initrd-$uname-r<br>
and linux-initrd-generic and so on. Maybe even signed somehow so that<br>
the kernel can verify its integrity when booting. Such that booting with<br>
authenticated FDE is fully authenticated.<br>
<br>
But oh well, those are all long term wishes :)<br></blockquote><div><br></div><div>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).</div><div><br></div><div>Cheers,</div><div>mwh </div></div></div>