Alpine Linux plans /usr merge
The Alpine Linux project has announced plans to change its base filesystem hierarchy:
In the future, /lib, /bin, and /sbin will be symbolic links to their /usr counterparts, and every package shall be installed under the /usr paths. For now, /usr/bin and /usr/sbin will continue to be independent paths, but that might change if the Filesystem Hierarchy Standard (FHS) gets updated.
The merge will take place in the upcoming Alpine 3.23 release planned for November; non-merged systems will be considered unsupported when 3.22 is at its end of life in May 2027.
Posted Oct 1, 2025 20:25 UTC (Wed)
by mb (subscriber, #50428)
[Link] (1 responses)
Is it actually still alife?
Posted Oct 1, 2025 20:37 UTC (Wed)
by knewt (subscriber, #32124)
[Link]
https://lwn.net/Articles/1032947/ # Finding a successor to the FHS [August 15, 2025]
Posted Oct 2, 2025 9:56 UTC (Thu)
by bof (subscriber, #110741)
[Link] (20 responses)
Posted Oct 2, 2025 10:32 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (8 responses)
Because thereās just not a well-defined boundary. Any command that āwonāt workā for a regular user can at least be invoked for `--help` by a regular user. Or maybe thereās a more granular site/specific permission setup in place than envisioned by those who made the split.
Itās the same problem as with the ā/ vs /usrā split vs. initramfs: yes, there was this idea that tools in / can be used to mount a /usr with the rest of the tools, but it just doesnāt scale: what if my complicated setup requires a tool that was never envisioned to be used in early userspace, and is thus built with prefix=/usr?
Posted Oct 2, 2025 11:39 UTC (Thu)
by joib (subscriber, #8541)
[Link] (2 responses)
(Also makes using sudo easier.)
Posted Oct 2, 2025 12:07 UTC (Thu)
by aragilar (subscriber, #122569)
[Link] (1 responses)
Posted Oct 2, 2025 12:19 UTC (Thu)
by joib (subscriber, #8541)
[Link]
Posted Oct 2, 2025 13:52 UTC (Thu)
by josh (subscriber, #17465)
[Link] (4 responses)
Many commands may also make sense to invoke from a new user namespace in which the user has privileges.
From a quick look at the commands in /usr/sbin on my system, the first few easy examples I found:
Various commands to make, adjust, resize, or otherwise operate on filesystems or disks, which users can run on filesystem images.
tarcat, should clearly be in bin.
ldconfig, which users can run on their own chroots.
filefrag, which users can run without privileges.
nbd-client, which has unprivileged operations like --list.
logsave, which should work fine as a user.
service, which has unprivileged or partially-privileged operations.
ifconfig, which works fine as a user to read configuration.
getcap, which works fine as a user.
Posted Oct 2, 2025 16:10 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
Similar applies with /sbin; it was created when shared libraries came to be, as a place for statically linked binaries that would run even if /lib or /usr/lib was unreadable, so that you could repair the system to the point where you can use dynamically linked binaries from /bin or /usr/bin. The only reason that it's been used as a split between "system" and "user" commands is that "system" commands often were statically linked, historically, so that they'd run even if you had a damaged system (e.g. because you'd put /lib on a different disk, and the driver for it was on /, or because /usr was network mounted).
Nowadays, the problems that the /bin split from /sbin was meant to solve are solved by the initramfs instead - if your system is so broken you need rescue tools to get it going, you use the initramfs tools, not the tools in / - indeed, you may not even be able to mount / without the initramfs tools, whereas the split comes from the days when the kernel mounted / as the very first thing it did, without any form of RAM FS.
Posted Oct 2, 2025 18:10 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
Posted Oct 19, 2025 4:40 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Posted Oct 2, 2025 16:18 UTC (Thu)
by mb (subscriber, #50428)
[Link]
This, and also run0 doesn't work, if the invoked binary is not in the user's $PATH, because it checks that before elevating privileges.
Posted Oct 2, 2025 12:26 UTC (Thu)
by joib (subscriber, #8541)
[Link] (5 responses)
There's probably too much stuff out there that has various /usr containing paths hardcoded to be worth the effort to get rid of /usr (POSIX might even mandate the presence of /usr/bin/env?).
(Another motivation put forth that I read somewhere (Lennart Poettering's blog maybe?) is that it makes it possible to have /usr as some kind of read-only atomic snapshot. Not perhaps the reality for most installations today, but maybe we're slowly going towards at least making that possible without excessive heroics.)
Posted Oct 3, 2025 8:49 UTC (Fri)
by jengelh (guest, #33263)
[Link]
More precisely, admins want to be able to reset either config or programs (or both), which means the two need to live in different subvolumes. That alone does not mandate any particular layout, though. Your initramfs could well do either of:
mount @config_subvol /realroot/etc
-or-
mount @config_subvol /realroot/etc
Posted Oct 3, 2025 9:51 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
That's great for image-based distributions; I can upgrade by downloading and writing a new version of /usr to my workstation, and then swap on reboot. But for this to be possible transparently to non-admin users (ones who don't install software to /, but instead use something like Flatpak to install it to their own home directory), you need non-image distros to agree that everything lives in /usr, too.
Posted Oct 6, 2025 21:23 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (2 responses)
Posted Oct 7, 2025 5:18 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 7, 2025 9:14 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
If I don't want an image based system, I can continue to run with a writeable /usr and change the contents freely, just like I can today. If I want an image based system, I can build my own images, or I can download other people's images.
Posted Oct 2, 2025 13:25 UTC (Thu)
by smcv (subscriber, #53363)
[Link] (4 responses)
This was a frequently asked question during Debian's implementation of the same /usr merge. The subdirectories of /usr, together with the subdirectories of the root that get merged into /usr by the /usr merge, have more in common with each other than they do with any other subdirectory of the root: they're all "owned" by the packaging system (.deb or .rpm or equivalent), they're all read-only during normal system operation (only modified when packages are added, removed or changed), they can reasonably be immutable on an image-based system, in an ideal world they're a deterministic product of the list of packages that have been installed, it is plausible to share them between identically set up machines using NFS or similar, and so on. (Unlike, for example, /etc, which contains the hostname and machine ID so is specific to a single machine, even if there is no local/sysadmin configuration that differs.)
If you're going to do anything like sharing a /usr between containers, or NFS-sharing /usr, then it's easier to do that with 1 mount point than with n >= 3 mount points (/lib, /share, /bin, maybe /sbin, maybe /games, maybe /lib64, etc.).
Debian GNU/Hurd did try the opposite of the /usr merge (normalizing to /bin, /lib, etc. with a compatibility symlink /usr -> /) a while ago, but with hindsight that approach doesn't have the desirable property that all the "/usr-like" directories are kept together, so the /usr merge was the better way round to do it.
Posted Oct 6, 2025 17:31 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
It would almost be worth trying to unify /usr/local with /opt, but unfortunately I think they are slightly too different for that to work. The subdirectories of /usr/local are usually very similar to the /usr subdirectories, but /opt has no structure, and it is probably too late to try and impose the former on the latter.
Posted Oct 6, 2025 18:50 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (2 responses)
Posted Oct 6, 2025 21:41 UTC (Mon)
by NekkoDroid (guest, #176638)
[Link] (1 responses)
Posted Oct 7, 2025 13:57 UTC (Tue)
by smcv (subscriber, #53363)
[Link]
New FHS release?
The last release was over 10 years ago.
Quite some things changed during this time.
New FHS release?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
It's also worth bearing the history of the split in mind; originally, there was only /bin for binaries, and they were statically linked by definition. /usr/bin got added when an early system ran out of space on the disk used for /, and they had to split across the "user" disk (mounted as /usr, used like today's /home) and the "system" disk.
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
for i in @prog_subvol/*; do
j=${i##*/}
mount @prog_subvol/$j /realroot/$j
ln -s /$j /realroot/usr/$j
done
mount @prog_subvol /realroot/usr
for i in bin lib sbin; do ln -s usr/$i /realroot/$i; done
The best motivation I've seen for /usr (rather than directly in /) is that it enables a setup where you do not mount anything over persistent filesystem volumes, and you swap persistent volumes for an upgrade.
Why split bin + sbin?
Why split bin + sbin?
Why split bin + sbin?
How?
Why split bin + sbin?
why keep /usr
why keep /usr
why keep /usr
why keep /usr
why keep /usr