<div dir="ltr"><div dir="ltr">Hello,<br><br>I am reporting a regression in the 6.12 stable series related to EROFS file-backed mounts.<br><br>After updating from Linux 6.12.62 to 6.12.63, a previously working setup using OSTree-backed composefs mounts as Podman rootfs no longer works.<br><br>The regression appears to be caused by the following commit:<br><br>  34447aeedbaea8f9aad3da5b07030a1c0e124639 ("erofs: limit the level of fs stacking for file-backed mounts")<br>  (backport of upstream commit d53cd891f0e4311889349fff3a784dc552f814b9)<br><br>## Setup description<br><br>We use OSTree to materialize filesystem trees, which are mounted via composefs (EROFS + overlayfs) as a read-only filesystem. This mounted composefs tree is then used as a Podman rootfs, with Podman mounting a writable overlayfs on top for each container.<br><br>This setup worked correctly on Linux 6.12.62 and earlier.<br><br>In short, the stacking looks like:<br><br>  EROFS (file-backed)<br>    -> composefs (EROFS + overlayfs with ostree repo as datadir, read-only)<br>        -> Podman rootfs overlays (RW upperdir)<br><br>There is no recursive or self-stacking of EROFS.<br><br>## Working case (6.12.62)<br><br>The composefs mount exists and Podman can successfully start a container using it as rootfs.<br><br>Example composefs mount:<br><div><br></div><div>    ❯ mount | grep a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c<br>    a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c on /home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c type overlay (ro,noatime,lowerdir+=/proc/self/fd/10,datadir+=/proc/self/fd/7,redirect_dir=on,metacopy=on)</div><div><br></div><div>(lowedir is a handle for the erofs file-backed mount, datadir is a handle for the ostree repository objects directory)</div><br>Running Podman:<br><br>  ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l<br>  root@d691e785bba3:/# uname -a<br>  Linux d691e785bba3 6.12.62 #1-NixOS SMP PREEMPT_DYNAMIC Fri Dec 12 17:37:22 UTC 2025 x86_64 GNU/Linux<br>  root@d691e785bba3:/# <br><br></div><div>(succeed)</div><div dir="ltr"><br>## Failing case (6.12.63)<br><br>After upgrading to 6.12.63, the same command fails when Podman tries to create the writable overlay on top of the composefs mount.<br><br>Error:<br><br>    ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l    <br>    Error: rootfs-overlay: creating overlay failed "/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c" from native overlay: mount overlay:/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/merge, flags: 0x4, data: lowerdir=/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c,upperdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/upper,workdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/work,userxattr: invalid argument<br>    ❯ uname -a<br>    Linux ci-node-09 6.12.63 #1-NixOS SMP PREEMPT_DYNAMIC Thu Dec 18 12:55:23 UTC 2025 x86_64 GNU/Linux<br><br>## Expected behavior<br><br>Using a composefs (EROFS + overlayfs) read-only mount as the lowerdir for a container rootfs overlay should continue to work as it did in 6.12.62.<br><br>## Actual behavior<br><br>Overlayfs mounting fails with EINVAL when stacking on top of the composefs mount backed by EROFS.<br><br>## Notes<br><br>The setup does not involve recursive EROFS mounting or unbounded stacking depth. It appears the new stacking limit rejects this valid and previously supported container use case.<br><br>Please let me know if further details or testing would be helpful.<br><br>Thank you,</div><div dir="ltr">-- </div><div> Alekséi Nadénov</div>
</div>