The bin/sbin merge feature landed in Rawhide today: https://bodhi.fedoraproject.org/updates/FEDORA-2025-da0a082e66 with that, ostree build is broken due to several package scripts trying to run things in /usr/sbin: [2025-01-13 10:49:28] container-selinux.post: /proc/self/fd/5: line 3: /usr/sbin/setsebool: No such file or directory [2025-01-13 10:49:28] container-selinux.post: libsemanage.semanage_validate_and_compile_fcontexts: setfiles returned error code 1. (No such file or directory). [2025-01-13 10:49:28] container-selinux.post: semodule: Failed! [2025-01-13 10:49:28] passt-selinux.post: libsemanage.semanRunning post scripts...done [2025-01-13 10:49:37] error: Installing packages: Running %post for kernel-tools-libs: bwrap(/bin/sh): Child process stopped by signal 0 [2025-01-13 10:49:37] age_validate_and_compile_fcontexts: setfiles returned error code 1. (No such file or directory). [2025-01-13 10:49:37] passt-selinux.post: semodule: Failed! [2025-01-13 10:49:37] passt-selinux.post: libsemanage.semanage_validate_and_compile_fcontexts: setfiles returned error code 1. (No such file or directory). [2025-01-13 10:49:37] passt-selinux.post: semodule: Failed! [2025-01-13 10:49:37] kernel-tools-libs.post: /proc/self/fd/5: line 1: /sbin/ldconfig: No such file or directory not sure if this is ostree-specific or an ordering issue (the update that changes the definition is being installed too early?), but wanted to get it reported. openQA caught this, but as the ostree tests are not gating at this time, the update wasn't prevented going stable.
Thanks for reporting. I think it's worth following up to the fedora-devel@ thread for things like this. There is a more focused discussion of this in https://gitlab.com/fedora/bootc/tracker/-/issues/29
https://github.com/coreos/rpm-ostree/pull/5224
https://bodhi.fedoraproject.org/updates/FEDORA-2025-fabb0f80a7 landed in Rawhide so this should be fixed.
Let's keep this open for now until we are confident this is fixed. Adam pointed rebase is failing in https://openqa.fedoraproject.org/tests/3142672#step/rpmostree_rebase/17.
Hmm that may relate to https://github.com/ostreedev/ostree/blob/639db09ea06e624b27bb05a5c35f8922e8c0c3e5/src/libostree/ostree-sysroot-deploy.c#L3344 - I think the direction of the symlink may be reversed there...looking (edit no I think that's right) > Let's keep this open for now until we are confident this is fixed. OK for now but if it's an ostree bug as seems likely then we'll want a separate bug anyways.
I think it's fine to close this one, as this specific bug is fixed. rebase failing is a different thing, I was planning to investigate and report that separately if it's not fixed already.
More fallout in https://bugzilla.redhat.com/show_bug.cgi?id=2339009