This is a tracking bug for Change: Unify /usr/bin and /usr/sbin For more details, see: https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to usr/bin and usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH. The same change is also done to make /usr/local/sbin point to bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place. The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
FEDORA-2024-3aafcac6a8 (bind-9.18.26-2.fc41, chkconfig-1.28-2.fc41, and 52 more) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8
This has been deferred to F42.
Hello, is there any update on this bug? Thank you.
FEDORA-2025-da0a082e66 (bin-sbin-merge) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-da0a082e66
FEDORA-2025-da0a082e66 (bin-sbin-merge) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
hddtemp PR: https://src.fedoraproject.org/rpms/hddtemp/pull-request/1 it would have been nice to file bugs or (ideally) PRs against the consolehelper-using packages the Change owners *knew* would be broken by this, listed at https://fedoraproject.org/wiki//Changes/Unify_bin_and_sbin#Scope . I can't find a bug, issue or PR for hddtemp. I found it because the problem breaks the build of ostrees that contain hddtemp.
Please see bug 2338712. There may be an issue with Alternatives or with the iptables-legacy package.
Hello, I still have an issue with PATH on the latest fedora-rawhide and f42. It still contains '/usr/sbin' path. The biggest issue is that if a package is build on system with merged bin/sbin and PATH contains '/usr/sbin' then some rpm dependencies are resolved to be '/usr/sbin/<binary>' instead of '/usr/bin/<binary>' and package cannot be installed because nothing provides '/usr/sbin/<binary>'. There have been fixes made in the systemd and setup packages: https://src.fedoraproject.org/rpms/systemd/c/cc9bce7893d956c5e0a5041e0890150b21c0d6d7?branch=f42 https://src.fedoraproject.org/rpms/setup/c/827730533e34a87ff743c15f81e218488232dbc6?branch=rawhide I think that additional fixes needs to be done to the openssh package because it looks like it defines its own PATH: https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh.spec#_436 The variable PATH on my rawhide installation looks like this: $ ssh root@fraw-3 'env | grep ^PATH' PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin Probably some fixes will be needed also for shadow-utils package. When i login via 'virsh console' I get PATH: [root@fraw-3 ~]# env | grep ^PATH PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin When I edit ENV_SUPATH in the /etc/login.defs and remove '/usr/sbin' then environment in the next login has PATH variable without '/usr/sbin'. Please, could somebody look at it? I'm not sure if my assumptions are correct.
Miroslav, what is the actual problem you're seeing? Having additional paths in $PATH should generally just be a cosmetic issue. > some rpm dependencies are > resolved to be '/usr/sbin/<binary>' instead of '/usr/bin/<binary>' and > package cannot be installed because nothing provides '/usr/sbin/<binary>'. Please be specific.
https://discussion.fedoraproject.org/t/f40-change-proposal-unify-usr-bin-and-usr-sbin-system-wide/99853(In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > Miroslav, what is the actual problem you're seeing? Having additional > paths in $PATH should generally just be a cosmetic issue. > > > some rpm dependencies are > > resolved to be '/usr/sbin/<binary>' instead of '/usr/bin/<binary>' and > > package cannot be installed because nothing provides '/usr/sbin/<binary>'. > > Please be specific. The pcs package has been built in our CI on Fedora-42 and could not be installed on Fedora-42: # dnf install rpms/pcs-0.12.0-99+git.70.1b0f.PcsFedoraCurrentRelease.fc42.x86_64.rpm Updating and loading repositories: Repositories loaded. Failed to resolve the transaction: Problem: conflicting requests - nothing provides /usr/sbin/ruby needed by pcs-0.12.0-99+git.70.1b0f.PcsFedoraCurrentRelease.fc42.x86_64 from @commandline You can try to add to command line: --setopt=optional_metadata_types=filelists to load additional filelists metadata --skip-broken to skip uninstallable packages # rpm -qR rpms/pcs-0.12.0-99+git.70.1b0f.PcsFedoraCurrentRelease.fc42.x86_64.rpm | grep ruby /usr/bin/ruby /usr/sbin/ruby libruby.so.3.4()(64bit) ruby >= 3.1 rubygems The autotools searches the PATH variable and founds '/usr/sbin/ruby' which is used for shebang. Issue regrading '/usr/sbin/' in PATH was discussed in this thread beginning at: https://discussion.fedoraproject.org/t/f40-change-proposal-unify-usr-bin-and-usr-sbin-system-wide/99853/25
Commands to reproduce issue with ruby path: dnf install -y autoconf automake mkdir -p reproducer cd reproducer cat <<EOF > configure.ac AC_INIT() AC_PATH_PROG([RUBY], [ruby]) EOF autoreconf -i -v ./configure Output of configure script on Fedora-Rawhide is: checking for ruby... /usr/sbin/ruby This is because symlink /usr/sbin -> /usr/bin and PATH containing '/usr/sbin'. I'm not sure which Fedora package/script is still setting '/usr/sbin' to the PATH.
(If you're not using mock to build the rpms, please consider doing so. It's easier to have a clean and reproducible environment that way.) A new install of F42 will have /usr/sbin as a symlink, and with the changes in systemd and setup, $PATH should not contain /usr/sbin. Do you have setup >= 2.15.0-13? If the $PATH cannot be fixed, i.e. if something injects /usr/sbin into the path in your environment, please just update the variable locally.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #12) > (If you're not using mock to build the rpms, please consider doing so. > It's easier to have a clean and reproducible environment that way.) We will condiser it. > > A new install of F42 will have /usr/sbin as a symlink, and with the > changes in systemd and setup, $PATH should not contain /usr/sbin. > Do you have setup >= 2.15.0-13? > Yes, I have setup-2.15.0-14.fc43.noarch. > If the $PATH cannot be fixed, i.e. if something injects /usr/sbin > into the path in your environment, please just update the variable > locally.
I noticed on my F42 Silverblue system that /usr/sbin is still in my PATH when opening up a terminal in my GNOME session. I tracked this down to the build configuration of gdm: -Ddefault-path=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin \ https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/gdm.spec#_117 Is it appropriate to open a PR to gdm to remove /usr/sbin from the default path citing this initiative?
> Is it appropriate to open a PR to gdm to remove /usr/sbin from the default path citing this initiative? Yes. It'd be even better for gdm to not touch the path at all. There is no supported scenario in which gdm is executed in an unitialized environment and it needs to do system setup. When it does such setup, it mostly serves to confuse and break things.
Opendkim needs updating in Fedora 42: https://bugzilla.redhat.com/show_bug.cgi?id=2365908
The following may be related. Doing a fedora 40->42 upgrade I came across a conflict: the nut package includes /usr/sbin/rhino Driver for Brazilian Microsol RHINO UPS equipment the rhino package includes /usr/bin/rhino invokes the JavaScript shell for running scripts in batch mode or interactive Both are regular files (not a symlink). The upgrade test fails for this reason. How should this be fixed?
(In reply to Eyal Lebedinsky from comment #17) > The following may be related. > > Doing a fedora 40->42 upgrade I came across a conflict: > the nut package includes /usr/sbin/rhino > Driver for Brazilian Microsol RHINO UPS equipment > the rhino package includes /usr/bin/rhino > invokes the JavaScript shell for running scripts in batch mode or > interactive > Both are regular files (not a symlink). > > The upgrade test fails for this reason. > > How should this be fixed? I now checked the content of the f42 rpms and see that both packages install to /usr/bin/rhino, hence the conflict. Still a problem.
This will need to be solved between those packages. I filed a new bug now.
The incus and docker containers of fedora 42 in /usr/local only have bin/ ``` $ docker run --pull=always -ti --entrypoint ls fedora:latest /usr/local | grep bin latest: Pulling from library/fedora Digest: sha256:ee88ab8a5c8bf78687ddcecadf824767e845adc19d8cdedb56f48521eb162b43 Status: Image is up to date for fedora:latest bin etc games include lib lib64 libexec share src ``` The wiki spec claims that there should be /usr/local/sbin symlink to /usr/local/bin. Can you please doublecheck if it the symlink in /usr/local is intentionally or accidentally missing; and if containers or the wiki spec need updating.
I wanted to say "of course", there is a scriptlet to create the symlink and it certainly was being created in the past, but somehow it is not present! $ sudo dnf --repo=fedora --repo=updates --releasever=42 --installroot /var/tmp/instA --use-host-config install filesystem -y $ ls -l /var/tmp/instA/usr/sbin /var/tmp/instA/usr/local/sbin ls: cannot access '/var/tmp/instA/usr/local/sbin': No such file or directory lrwxrwxrwx 1 root root 3 May 18 16:51 /var/tmp/instA/usr/sbin -> bin $ rpm -q --root /var/tmp/instA --scripts filesystem|grep 'symlink.*sbin' posix.symlink("usr/sbin", "/sbin") posix.symlink("usr/sbin", "/usr/lib/debug/sbin") posix.symlink("bin", "/usr/sbin") posix.symlink("bin", "/usr/lib/debug/usr/sbin") posix.symlink("bin", "/usr/local/sbin") $ sudo dnf --repo=fedora --repo=updates --releasever=42 --installroot /var/tmp/instA --use-host-config reinstall filesystem -y $ ls -l /var/tmp/instA/usr/sbin /var/tmp/instA/usr/local/sbin lrwxrwxrwx 1 root root 3 May 18 17:04 /var/tmp/instA/usr/local/sbin -> bin lrwxrwxrwx 1 root root 3 May 18 16:51 /var/tmp/instA/usr/sbin -> bin :((((
I updated https://src.fedoraproject.org/rpms/filesystem/pull-request/29 and https://src.fedoraproject.org/rpms/filesystem/pull-request/30 to fix this issue. See the last commits there for explanation.