Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Migrating from Fedora 41 or reinstalling filesystem on Fedora 42 to trigger the /usr/sbin and /usr/bin migration script, stops it because it find links to /etc/alternatives Version-Release number of selected component (if applicable): filesystem-3.18-36.fc42.x86_64 How reproducible: Always if there are alternatives symlinks on /usr/sbin before the merge Steps to Reproduce: 1. Start with a non merged installation. 2. Install packages like iptables-nft or ebtables-legacy (qemu requirements) 3. proceed to reinstall filesystem: dnf reinstall filesystem Actual results: /usr/sbin cannot be merged, /usr/sbin/arptables points to /etc/alternatives/arptables Expected results: If there are no other binary directly installed on /usr/sbin, the merge should proceed. Additional info: The migration script should make an exception with alternatives links like it does with links to /usr/bin
Zbyszek, pls, could you take a look?
This will be fixed without any changes in the filesystem package. Instead, we need to change individual packages that user alternatives to move their symlinks to /usr/bin. We actually started doing that, but then alternatives didn't work properly, and I reverted those changes. Later on, alternatives were fixed to handle both paths as equivalent. But now we need to redo the work in the packages. I'll close this bug here, since there's no bug in filesystem. The PR for iptables is at https://src.fedoraproject.org/rpms/iptables/pull-request/11. Let's continue the discussion there if appropriate.
I think we need to change filesystem a bit to make this easier. This will be better than updating all individual packages to handle the move.
Hmm, after trying to script this in this filesystem.spec, I think this cannot be solved there. The problem is that alternatives keeps state in /var/lib/alternatives that remembers the old paths. So after upgrading a package using alternatives for symlinks in /usr/sbin, now moved to /usr/bin, alternatives knows about both sets of paths and things are broken. Reproducer from https://bodhi.fedoraproject.org/updates/FEDORA-2025-a17e3e5938: $ sudo rm -rf /var/tmp/inst1 && mkdir /var/tmp/inst1/usr/sbin -p $ sudo dnf5 install --repo=fedora --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config iptables-nft -y $ sudo dnf5 install --repo=fedora --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config iptables-{nft,libs}-1.8.11-7.fc43.x86_64.rpm $ sudo systemd-nspawn -q -D /var/tmp/inst1 alternatives --display iptables iptables - status is auto. link currently points to /usr/sbin/iptables-nft /usr/sbin/iptables-nft - priority 10 follower ip6tables: /usr/sbin/ip6tables-nft follower ip6tables-restore: /usr/sbin/ip6tables-nft-restore follower ip6tables-save: /usr/sbin/ip6tables-nft-save follower iptables-restore: /usr/sbin/iptables-nft-restore follower iptables-save: /usr/sbin/iptables-nft-save follower ip6tables: /usr/sbin/ip6tables-nft follower ip6tables-restore: /usr/sbin/ip6tables-nft-restore follower ip6tables-save: /usr/sbin/ip6tables-nft-save follower iptables-restore: /usr/sbin/iptables-nft-restore follower iptables-save: /usr/sbin/iptables-nft-save /usr/bin/iptables-nft - priority 10 follower ip6tables: /usr/bin/ip6tables-nft follower ip6tables-restore: /usr/bin/ip6tables-nft-restore follower ip6tables-save: /usr/bin/ip6tables-nft-save follower iptables-restore: /usr/bin/iptables-nft-restore follower iptables-save: /usr/bin/iptables-nft-save follower ip6tables: /usr/bin/ip6tables-nft follower ip6tables-restore: /usr/bin/ip6tables-nft-restore follower ip6tables-save: /usr/bin/ip6tables-nft-save follower iptables-restore: /usr/bin/iptables-nft-restore follower iptables-save: /usr/bin/iptables-nft-save Current `best' version is /usr/sbin/iptables-nft. $ grep 'nft$' /var/tmp/inst1/var/lib/alternatives/iptables /usr/sbin/iptables-nft /usr/sbin/ip6tables-nft /usr/sbin/ip6tables-nft /usr/bin/iptables-nft /usr/bin/ip6tables-nft /usr/bin/ip6tables-nft I wonder if we should somehow handle this automatically in alternatives.
Hopefully, https://bodhi.fedoraproject.org/updates/FEDORA-2025-4b99136835 should fix this.
Over the last few days, a bunch of changes in different components were made to resolve this. But in particular, in filesystem, the scriptlets were extended to merge symlinks to /etc/alternatives. I'll mark this bug as resolved.