I did the same (even updated after the official release date) and still got two binaries from vpnc lying around. I found this vpnc update in updates-testing, which – after updating to it – correctly moved the vpnc binaries to /usr/bin. After that, /usr/sbin only contains symlinks, i.e, find /usr/sbin/ -type f returns nothing.
Still, /usr/sbin is not a symlink to /usr/bin. This is the case even after dnf reinstall filesystem. Is this expected? When will /usr/sbin be turned into a symlink for /usr/bin then?
I also have /usr/sbin/iconvconvert and /usr/sbin/ldconfig that are regular files. Invoking them with the “–version” option I can confirm these are from glibc 2.40, i.e. from Fedora 41. I think these were not properly removed during the upgrade to Fedora 42. I’ve filed a bug, hoping it’s not a duplicate ![]()
I just did an F42->F43 upgrade and it still doesn’t go through.
-rwxr-xr-x. 1 root root 16008 Jul 18 2024 getcap
-rwxr-xr-x. 1 root root 16000 Jul 18 2024 getpcaps
-rwxr-xr-x. 1 root root 32728 Jul 24 03:00 iconvconfig
-rwxr-xr-x. 1 root root 1023376 Jul 24 03:00 ldconfig
-rwxr-xr-x. 1 root root 16160 Jul 17 2024 sasldblistusers2
-rwxr-xr-x. 1 root root 16144 Jul 17 2024 saslpasswd2
-rwxr-xr-x. 1 root root 15992 Jul 18 2024 setcap
this laptop has gone through upgrades since at least F40.
On my main computer, which has seen even more upgrades, the list is much longer:
-rwxr-xr-x. 1 root root 26816 Feb 1 2019 avmcapictrl
-rwxr-xr-x. 1 root root 43760 Feb 1 2019 capiinit
-rwxr-xr-x. 1 root root 51736 Jul 18 2024 capsh
-rwxr-xr-x. 1 root root 15992 Jul 17 2024 cracklib-check
-rwxr-xr-x. 1 root root 15992 Jul 17 2024 cracklib-packer
-rwxr-xr-x. 1 root root 15976 Jul 17 2024 cracklib-unpacker
-rwxr-xr-x. 1 root root 1276792 Jul 25 2019 dibbler-client
-rwxr-xr-x. 1 root root 24216 Jun 24 03:00 faillock
-rwxr-xr-x. 1 root root 24152 Jan 16 2025 fxload
-rwxr-xr-x. 1 root root 16008 Jul 18 2024 getcap
-rwxr-xr-x. 1 root root 16000 Jul 18 2024 getpcaps
-rwxr-xr-x. 1 root root 22128 Feb 1 2019 hisaxctrl
-rwxr-xr-x. 1 root root 22144 Feb 1 2019 icnctrl
-rwxr-xr-x. 1 root root 32728 Jun 21 03:00 iconvconfig
-rwxr-xr-x. 1 root root 30696 Feb 1 2019 imon
-rwxr-xr-x. 1 root root 22192 Feb 1 2019 imontty
-rwxr-xr-x. 1 root root 226056 Feb 1 2019 ipppd
-rwxr-xr-x. 1 root root 26304 Feb 1 2019 ipppstats
-rwxr-xr-x. 1 root root 22136 Feb 1 2019 iprofd
-rwxr-xr-x. 1 root root 89784 Feb 1 2019 isdnctrl
-rwxr-xr-x. 1 root root 388840 Feb 1 2019 isdnlog
-rwxr-xr-x. 1 root root 1023376 Jun 21 03:00 ldconfig
-rwx--s--x. 1 root lock 20256 Jul 18 2024 lockdev
-rwxr-xr-x. 1 root root 22088 Feb 1 2019 loopctrl
-rwxr-xr-x. 1 root root 20168 Jun 24 03:00 mkhomedir_helper
-rwxr-xr-x. 1 root root 32184 Jul 8 2019 mk_passwd
-rwxr-xr-x. 1 root root 47648 Feb 1 2019 mkzonedb
-rwxr-xr-x. 1 root root 20064 Jul 20 2023 nfacct
-rwxr-xr-x. 1 root root 21458 Feb 7 2025 nvmetcli
-rwxr-xr-x. 1 root root 45744 Jan 19 2023 pam_console_apply
-rwsr-xr-x. 1 root root 16000 Jun 24 03:00 pam_timestamp_check
-rwxr-xr-x. 1 root root 24272 Jun 24 03:00 pwhistory_helper
-rwxr-xr-x. 1 root root 30672 Feb 1 2019 rcapid
-rwxr-xr-x. 1 root root 16160 Jul 17 2024 sasldblistusers2
-rwxr-xr-x. 1 root root 16144 Jul 17 2024 saslpasswd2
-rwxr-xr-x. 1 root root 15992 Jul 18 2024 setcap
-rwxr-xr-x. 1 root root 36712 Jul 20 2024 tmpwatch
-rwxr-xr-x. 1 root root 15760 Jul 20 2024 tunctl
-rwxr-xr-x. 1 root root 11728 Jan 19 2025 umount.udisks
-rwsr-xr-x. 1 root root 32568 Jun 24 03:00 unix_chkpwd
-rwx------. 1 root root 36736 Jun 24 03:00 unix_update
-rwxr-xr-x. 1 root root 47600 Feb 1 2019 vboxd
-rwxr-xr-x. 1 root root 1059 Feb 1 2019 vboxmail
-rwxr-xr-x. 1 root root 179208 Aug 1 2020 xinetd
tmpwatch in particualr, puts the bin in usr/sbin, and symlinks to it in usr/bin.
I went through and manually converted to symlinks in both, and reinstalled the filesystem package, which resolved it for me.
tunctl is from tunctl-1.5-32.fc41, which dnf search still shows as available.
nvmetcli is from nvmetcli-0.8-1.fc42.noarch, still available.
tmpwatch is from 2.11-27.fc41, which the f42 upgrade strangely didn’t upgrade. dnf search still shows the fc41 version as available, along fc42 package.
lockdev is from lockdev-1.0.4-0.51.20111007git.fc42.x86_64. a dep of some common packages.
xinetd is from xinetd-2:2.3.15-34.fc33. No longer available.
nfacct is from nfacct-1.0.1-20.fc39. No longer available.
some others may be from careless make install in the past.
All those files have been moved to /usr/bin in their packages. There is an rpm bug which caused it to leave behind binaries. A hacky solution to handle this in glibc was merged (Making sure you're not a bot!), but then it was reverted (error: Package 'glibc' has (currently) unsupported <lua> script in '%posttrans' · Issue #660 · fedora-silverblue/issue-tracker · GitHub).
tunctl failed in the mass rebuild for F42, but it was then built successfully for F43. I don’t think dnf search should list the F41 version. If it does, maybe it’s because the F41 version was held back on your system because of dependencies. In general, it seems that you have a bunch of old packages, and an upgrade in the past was only partial. I guess you could remove the duplicate packages by hand and then the rest of the upgrade should go through.
Making sure you're not a bot! for xinetd and nfacct.
FYI, remctl is another obsolete package which is causing problems:
# ls -l /usr/sbin/remctld
-rwxr-xr-x. 1 root root 82576 Jul 20 2023 /usr/sbin/remctld
# rpm -qf /usr/sbin/remctld
remctl-3.18-8.fc39.x86_64
Added to the PR linked above.
fxload is fixed:
F43: Making sure you're not a bot!
F42: Making sure you're not a bot!
tunctlfailed in the mass rebuild for F42, but it was then built successfully for F43. I don’t thinkdnf searchshould list the F41 version. If it does, maybe it’s because the F41 version was held back on your system because of dependencies
Right. The F43 laptop shows the fc43 package (which installs in /usr/bin). But on the F42 box, the fc41 package is the last available in the package repos, carried over from F42. So that’s the version dnf shows and installs on F42.