On Thu, Apr 25, 2024 at 06:47:38AM +0200, Stefano Brivio wrote:On Sat, 6 Apr 2024 14:02:58 +1100 David Gibson <david(a)gibson.dropbear.id.au> wrote:Not in a way that you can use safely. Archives are not a filesystem, let alone a filesystem designed for concurrent access from multiple parties. So, it's basically never going to be safe to read the archive independently while archivemount has it open for writing. If you're lucky, you might get what you want, but you could also get old contents because archivemount hasn't flushed out the changes yet (which is exactly what we saw). Or, worse, you could see a partly written archive, because you read when archivemount had started but not finished writing. Or, worse still, you could see inconsistent garbage, because you were reading partway through, then archivemount rewrote from the beginning. If you want this behaviour, you need something like virtio-fs or NFS.On Fri, Apr 05, 2024 at 08:09:32PM +0200, Stefano Brivio wrote:That was exactly my point: with archivemount, the user doesn't have to call mbuto again -- archivemount does it, implicitly.On Fri, 22 Mar 2024 13:27:37 +1100 David Gibson <david(a)gibson.dropbear.id.au> wrote:Yeah, that was never going to work.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.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).-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibsonIf 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.