<div dir="ltr"><div>For anyone that may stumbled upon this, we worked around this issue by setting a more fine-grained dirs on the SYSTEMD_SYSEXT_HIERARCHIES env var. So it would just match those instead of overlaying the full /usr and getting our mounts under it lost :D</div><div><br></div><div>root@localhost:~# SYSTEMD_SYSEXT_HIERARCHIES=/usr/local/bin:/usr/local/sbin:/usr/local/include:/usr/local/lib:/usr/local/share:/usr/local/src:/usr/bin:/usr/share:/usr/lib:/usr/include:/usr/src:/usr/sbin systemd-sysext refresh<br>Using extensions 'work'.<br>Merged extensions into '/usr/local/bin'.<br>Merged extensions into '/usr/lib'.</div><div><br></div><div>That made our sysext work AND respected our mount under /usr/local with our own writable mounts and such :D<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2024 at 6:43 PM Itxaka Serrano Garcia <<a href="mailto:itxaka.garcia@spectrocloud.com">itxaka.garcia@spectrocloud.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="auto">Ah, I guess this is because overlayfs does not respect any underlying mounts in the /usr so they get lost<div dir="auto"><br></div><div dir="auto">So this has nothing to do with sysext.</div><div dir="auto"><br></div><div dir="auto">In any case, is this a valid use case that we can see happening? Or now that we are here already, if anyone got a suggestion it would be welcome, otherwise feel free to ignore this email :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El lun, 10 jun 2024, 17:19, Itxaka Serrano Garcia <<a href="mailto:itxaka.garcia@spectrocloud.com" target="_blank">itxaka.garcia@spectrocloud.com</a>> escribió:<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>Hey again,</div><div><br></div><div>I'm back with more annoying questions about sysext :D</div><div><br></div><div>According to the docs, sysext only "extends" the existing usr/opt/etc with the sysext contents but we are seeing a different thing here:</div><div><br></div><div>root@cos-recovery:~# stat /usr/local/file2 <br>  File: /usr/local/file2<br>  Size: 0              Blocks: 0          IO Block: 4096   regular empty file<br>Device: 0,47      Inode: 171         Links: 1<br>Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)<br>Access: 2024-06-10 14:56:50.725904625 +0000<br>Modify: 2024-06-10 14:56:50.725904625 +0000<br>Change: 2024-06-10 14:56:50.725904625 +0000<br> Birth: 2024-06-10 14:56:50.725904625 +0000<br>root@cos-recovery:~# systemd-sysext refresh<br>Using extensions 'work'.<br>Merged extensions into '/usr'.<br>root@cos-recovery:~# stat /usr/local/file2 <br>stat: cannot statx '/usr/local/file2': No such file or directory</div><div>root@cos-recovery:~# systemd-sysext unmerge<br>Unmerged '/usr'.<br>root@cos-recovery:~# stat /usr/local/file2 <br>  File: /usr/local/file2<br>  Size: 0              Blocks: 0          IO Block: 4096   regular empty file<br>Device: 0,47      Inode: 171         Links: 1<br>Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)<br>Access: 2024-06-10 14:56:50.725904625 +0000<br>Modify: 2024-06-10 14:56:50.725904625 +0000<br>Change: 2024-06-10 14:56:50.725904625 +0000<br> Birth: 2024-06-10 14:56:50.725904625 +0000<br></div><div><br></div><div>Weirdly enough, any files under /usr/ that we create are NOT overridden when we load any sysext, it only seems to happen in the dirs inside /usr<br></div><div><br></div><div>It's true that we are using USI here and on a "normal" non-USI/UKI system this behaviour doesn't seem to happen.</div><div><br></div><div><div>The main difference I can see is that the root fs in the failure 
case is a tmpfs while in the working case it's an ext4 fs, but for 
example our /usr/local is mounted to a ext4 disk:</div><div><br></div><div>/dev/mapper/vda3 on /usr/local type ext4 (rw,relatime)</div></div><div><br></div><div><br></div><div>If I do create an overlay on /usr then it seems to work as expected but its too late for us, we lose anything mounted there and hidden dirs.<br></div><div><br></div><div>Is this a bug or its expected behaviour? Is there anything we could be missing that triggers this behaviour? Any pointers on why this would react like this?</div><div><br></div><div><br></div><div>Cheers,</div><div>Itxaka<br></div></div>
</blockquote></div>
</blockquote></div>