[systemd-devel] sysext merge of /usr/local

[Itxaka Serrano Garcia]

Ah, I guess this is because overlayfs does not respect any underlying
mounts in the /usr so they get lost

So this has nothing to do with sysext.

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 :)

El lun, 10 jun 2024, 17:19, Itxaka Serrano Garcia <
itxaka.garcia at spectrocloud.com> escribió:

> Hey again,
>
> I'm back with more annoying questions about sysext :D
>
> According to the docs, sysext only "extends" the existing usr/opt/etc with
> the sysext contents but we are seeing a different thing here:
>
> root at cos-recovery:~# stat /usr/local/file2
>   File: /usr/local/file2
>   Size: 0         Blocks: 0          IO Block: 4096   regular empty file
> Device: 0,47 Inode: 171         Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2024-06-10 14:56:50.725904625 +0000
> Modify: 2024-06-10 14:56:50.725904625 +0000
> Change: 2024-06-10 14:56:50.725904625 +0000
>  Birth: 2024-06-10 14:56:50.725904625 +0000
> root at cos-recovery:~# systemd-sysext refresh
> Using extensions 'work'.
> Merged extensions into '/usr'.
> root at cos-recovery:~# stat /usr/local/file2
> stat: cannot statx '/usr/local/file2': No such file or directory
> root at cos-recovery:~# systemd-sysext unmerge
> Unmerged '/usr'.
> root at cos-recovery:~# stat /usr/local/file2
>   File: /usr/local/file2
>   Size: 0         Blocks: 0          IO Block: 4096   regular empty file
> Device: 0,47 Inode: 171         Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2024-06-10 14:56:50.725904625 +0000
> Modify: 2024-06-10 14:56:50.725904625 +0000
> Change: 2024-06-10 14:56:50.725904625 +0000
>  Birth: 2024-06-10 14:56:50.725904625 +0000
>
> 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
>
> It's true that we are using USI here and on a "normal" non-USI/UKI system
> this behaviour doesn't seem to happen.
>
> 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:
>
> /dev/mapper/vda3 on /usr/local type ext4 (rw,relatime)
>
>
> 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.
>
> 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?
>
>
> Cheers,
> Itxaka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240610/48645d24/attachment.htm>