On Fri, Apr 05, 2024 at 08:09:32PM +0200, Stefano
Brivio wrote:
On Fri, 22 Mar 2024 13:27:37 +1100
David Gibson <david(a)gibson.dropbear.id.au> wrote:
mbuto has two ways of building the initramfs.
One is the typical approach
of staging its contents in a temporary directory, then building the
initramfs with cpio. The other is to create an empty initramfs, mount
it with archivemount, and copy things into the mounted archive.
However, the archivemount approach is broken. I'm not entirely sure why,
but it appears not to properly unmount the archive and retrieve the final.
filled version. The upshot is that if archivemount is installed, then
mbuto generates an empty, gzip-compressed initramfs instead of whatever it
was supposed to. It looks like this has bitrotted from some earlier
working version.
The archivemount approach is not necessary, and honestly a pretty strange
and roundabout way of building the initramfs. Remove it.
There were two reasons behind that: first off, I mistakenly assumed
that the kernel could see changes made to the initramfs after boot.
Yeah, that was never going to work.
Second, it was actually convenient for developing
this tool as I could
just make directories and copies in half-working images. I also had
half a mind about some usage with QEMU rebooting the guest, and the
initramfs would change across reboots without having to call mbuto
again, for bisections or suchlike.
That's not really dependent on using archivemount in any case. If
qemu re-reads the initrd on each boot, then you can still do this by
rebuilding the image between boots (which is all that archivemount
would do anyway).
That was exactly my point: with archivemount, the user doesn't have to
call mbuto again -- archivemount does it, implicitly.
If qemu doesn't re-read it, then this won't
work even if you are using
archivemount.
It looks like QEMU doesn't do that, at least not on x86, so yes, this
part never worked anyway.
--
Stefano