<div dir="auto">Yes, your understanding is correct. I'm off at the moment, we will try and open a PR sometime to explain it better.<div dir="auto"><br></div><div dir="auto">By the way I'd also happily review your PR also if you think you could explain it better.</div><div dir="auto"><br></div><div dir="auto">At the moment it's a loopback mounted file from /boot, mounted as an erofs with transient overlay on top, there's a corresponding initoverlayfs file for each initramfs file basically.</div><div dir="auto"><br></div><div dir="auto">But it could be configurable in future to load a raw erofs partition if somebody wanted to do that.</div><div dir="auto"><br></div><div dir="auto">Gonna try and do some of the storage-init things as systemd service scripts soon.</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, 18 Dec 2023, 22:00 Askar Safin, <<a href="mailto:safinaskar@gmail.com" target="_blank" rel="noreferrer">safinaskar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi. Unfortunately, this is not clear enough from<br>
<a href="https://github.com/containers/initoverlayfs" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/containers/initoverlayfs</a> how exactly the<br>
second-stage early filesystem is mounted. So, please, add that<br>
information to README. Let me describe how I understand this.<br>
<br>
First, init program from (small) first-stage early filesystem mounts<br>
boot/ESP partition, where second-stage early filesystem image (i. e.<br>
erofs) is located. Then that init program mounts that erofs image.<br>
Without copying the whole erofs image into memory. In other words, if<br>
some part of erofs image is not accessed, then not only it is not<br>
uncompressed, it even is not loaded from disk to memory at all. Is my<br>
understanding correct?<br>
<br>
-- <br>
Askar Safin<br>
<br>
</blockquote></div>
</div>