<div dir="ltr">Also forgot to answer part of that, yes these are all gzip compressed cpio archives, I'm using imgextract because the kernel won't uncompress an initrd larger than 4 GB.<div><br></div><div>griznog</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022 at 1:55 PM John Hanks <<a href="mailto:griznog@gmail.com">griznog@gmail.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"><div dir="ltr">Whether contents from all of them are available turns out to be hard to answer. Some background for what I'm doing, I have a container (basically a chroot OS install) image that is my golden img. Then I have additional smaller images, each one containing some configuration subset that I want to overlay onto the golden OS image to modify it. So I can't easily use size to say it's doing the right thing because I'm overwriting (or attempting to) some files and I'd expect the result to not be the simple sum of the parts.<div><br></div><div>The best example of observed behavior is my ssh config setup. The golden image contains the keys generated when the initial chroot install was done. Then I have an ssh img that overlays that and places the correct keys for the host being booted over those. The overlay ssh image also adds several additional files in /etc/ssh. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.  </div><div><br></div><div>Other than that bit of confusion, I haven't yet found an example of anything missing that should be there in the resulting booted host filesystem. </div><div><br></div><div>Despite it being confusing with first writer winning, it's still quite useful behavior as collapsing all these overlay images before passing them to the kernel simplifies the resulting kernel command line nicely.  Is it worth adding a feature request for this if it's really unintentional? It's trivial to use different names to keep them separate so if the merging behavior was documented and stable, it'd be a nice option to have available, especially if it could behave predictably like extracting a series of cpio archives to the same location. </div><div><br></div><div>griznog</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022 at 12:54 PM Christian Iwata Nilsson <<a href="mailto:nikize@gmail.com" target="_blank">nikize@gmail.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"><div dir="ltr"><div dir="ltr">On Fri, 11 Mar 2022 at 17:42, John Hanks <<a href="mailto:griznog@gmail.com" target="_blank">griznog@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi, <div><br></div><div>I am using imgextract to download several images, like so</div><div><br></div><div><div>imgextract --name one <a href="http://master/one.img" target="_blank">http://master/one.img</a></div><div>imgextract --name two <a href="http://master/two.img" target="_blank">http://master/two.img</a></div><div>imgextract --name three <a href="http://master/three.img" target="_blank">http://master/three.img</a></div></div><div>boot kernel initrd=initrd.magic initrd=one initrd=two initrd=three blah blah blah</div><div><br></div><div>So far so good, except that I wanted to try adding a lot of these but am restricted by the maximum kernel command line length. I naively tried</div><div><br></div><div>imgextract --name mysystem <a href="http://master/one.img" target="_blank">http://master/one.img</a><br>imgextract --name mysystem <a href="http://master/two.img" target="_blank">http://master/two.img</a><br>imgextract --name mysystem <a href="http://master/three.img" target="_blank">http://master/three.img</a><br>boot kernel initrd=initrd.magic initrd=mysystem blah blah blah<br></div><div><br></div><div>and it worked!!! But, that seems way too easy, like I'm cheating. Is this expected to work this way or am I exploiting a bug that might get fixed later? I don't want to depend on this unless it's working this way on purpose. </div><div><br></div><div>Thanks,</div><div><br></div><div>griznog</div></div><br></blockquote><div><br></div><div>Are you sure that the contents from them are all available?<br>Since you are using imgextract I assume that the contents of *.img is compressed and that it contains CPIO archives?<br><br>Could you verify with imgstat that size adds up if you do them to separate names and then try those 2 to the same file?<br>I see nothing that indicates this as being expected behaviour.</div><div><br></div><div>/Christian</div><div> </div></div></div>
</blockquote></div>
</blockquote></div>