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@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@cos-recovery:~# systemd-sysext refresh Using extensions 'work'. Merged extensions into '/usr'. root@cos-recovery:~# stat /usr/local/file2 stat: cannot statx '/usr/local/file2': No such file or directory root@cos-recovery:~# systemd-sysext unmerge Unmerged '/usr'. root@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
