F42 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

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?

https://src.fedoraproject.org/rpms/filesystem/pull-request/24 might help.

1 Like

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 :wink:

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.

1 Like

fxload is fixed:

F43: Making sure you're not a bot!
F42: Making sure you're not a bot!

1 Like

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

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.