[ipxe-devel] Does imgextract keep writing to same named location by design?

[John Hanks]

Hi Thomas,

I've added marker files to the images and as far as I can tell nothing is
missing from the end result, it's just not clear which unpacked image will
win when the same file exists in multiple images using the ipxe script I
have been using.

griznog

On Mon, Mar 14, 2022 at 1:34 AM Thomas Mieslinger <miesi at mail.com> wrote:

> Adding a /one to image one, a /two to image two etc would make it easier
> to see whether all files are there....
>
> Am 11.03.22 um 21:13 schrieb John Hanks:
> >     On Fri, Mar 11, 2022 at 1:55 PM John Hanks <griznog at gmail.com
> >     <mailto:griznog at gmail.com>> wrote:
> >
> >
> >         If I get the OS container first, then get the ssh overlay, then
> >         the files that are new from the overlay appear correctly, but
> >         files that should overwrite those in the container don't appear
> >         so the new keys aren't there.
> >
> >         If I get the overlay img first, then the container, the files
> >         from the overlay all get written correctly and the ones in the
> >         container do not overwrite them.
> >
> >         Basically it behaves as if the first extracted img to write a
> >         file wins for that file and all subsequent files with the same
> >         name are discarded. This is counter-intuitive as I would have
> >         expected the last writer to win if I had simply ran `cpio` to
> >         extract all the images to a single location.
> >
> > Ok, I'm taking all that back. I think the file overwrite or not
> > overwrite behavior may be random or at least subject to some other
> > effect I haven't figured out yet. Repeated reboots to get more samples
> > shows that I can't really predict which img will win for a given file
> > that is present in multiple images. I'll be playing around with this
> > some more as it's really useful behavior, if it can be made to be
> > predictable and repeatable.
> >
> > griznog
> >
> >
> > _______________________________________________
> > ipxe-devel mailing list
> > ipxe-devel at lists.ipxe.org
> > https://lists.ipxe.org/mailman/listinfo/ipxe-devel
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20220314/3145f8f8/attachment.htm>