Can you have another partition you can install apps to like a /usr partition for apps?
In short, no. You can split off /usr
and/or /opt
from the root filesystem — albeit that this requires some work, and I’ve written a tutorial on how to do it — but UNIX is not Microsoft Windows. In UNIX, applications are always completely integrated into the operating system itself and become part of the system, whereas in Windows, applications are separate entities.
No, systemd recently removed support for having /usr
on a separate partition.
Thought so, just asking to be sure. So I have a unalocated drive, just install onto it or partition first? Do I need to make it GPT?
Shh!!! Don’t tell my computer! I’ve been running with a separate /usr
for 23 years now.
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] > lsblk -o UUID,MOUNTPOINT
UUID MOUNTPOINT
CEF6-EF5C /boot/efi
924f11d8-4bec-49a6-852e-033ce5e3d6a3 /boot
3f1852bc-be95-4e42-8d46-25bafac4ce79 /
8de45432-efe5-4d76-beb9-fcb3247a063e /usr
8462b14d-4a97-4383-a55d-61fcd136aeb9 /usr/local
6e756bf9-2d7c-401a-a0f3-bb4ea3b824a9 /opt
6d475769-c92c-4935-b2af-a53d29dcd898
e3fe76c9-8dea-4a27-8f47-839bb464f022 /srv
db2385c9-2715-408e-96b4-52086a0292fe /home
6fbd221f-5d46-40f0-9fbf-4479d73874b4
bdf6a9f6-a2a7-47a0-ba6f-7bbf71a01a95 /var
889d4e36-e279-4b82-838a-a5c1d4964e1a
1aedac7f-403b-4d85-9643-0d622be75453
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >
Read the tutorial.
Not necessarily. This is only needed if the drive is the one that the system boots up from and if it’s bigger than 2 TiB.
I think I will just instaal how I did it the first, let it take all the drive, or just partion on install.
Not for apps you install using the default package manager, because those packages are all using the system layout with it’s default paths.
You can however install any app in any directory if you do a manual install of that package from source or tar files.
(After adjusting the needed changes to integrate with your system)
In other words:
Pre-build packages already have directories configured where the apps expect parts of itself to be in.
Note: It might be possible to use snap packages or similar that are installed on a different partition, if they make use of overlay mounts…
Ohh?
Can you provide a link to the source where that is announced?
(Sounds highly doubtful)
From Release systemd v253 · systemd/systemd · GitHub
[…]
* We intend to remove support for split-usr (/usr mounted separately
during boot) and unmerged-usr (parallel directories /bin and
/usr/bin, /lib and /usr/lib, etc). This will happen in the second
half of 2023, in the first release that falls into that time window.
For more details, see:
[systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023
[…]
However, probably, the important thing is during boot.
@mithrial , you make the mistake of picking words apart…
They are removing support for the combination of split and unmerged (un-split) versions of /usr
dirs in systemd.
Which means, as they explicitly stated by mentioning the subdirs, they won’t be looking in /usr/bin
and /usr/lib
and the like, in favor of only looking in the “merged” versions.
Eg:
- They will only check in
/bin
instead of also looking in/usr/bin
. - They will only check in
/lib
instead of also in/usr/lib
. - Etc…
This does not mean systems making use of /usr
will not be able to use that directory at all, because a system-manager with it’s own search paths does not equal a filesystem with inaccessible paths
That is because the system manager is initialized during that phase… it is PID 1 for a reason…
Thanks
My interpretation is that they are the merged versions and they’ll stop looking in /bin
, /lib
etc. Which fits with the fact that /bin
etc are there for backwards compatibility after we moved to using /usr/bin
etc.
EDIT:
That’s 404 for me.
Thos are the primary locations for binaries and libraries, unlike /usr
which is by it’s name a non-system directory and only meant for “user” installed stuff. (hence the name is a short version of “user” and actually pronounced exactly the same.)
- User in this context is the person owning and operating the system, not to be confused with a user account on that system.
That’s why /usr
is historically mounted after the rest of the system paths have become available, be it via NFS or different partition.
Especially if you take into consideration that /usr
can be mounted via network, it only makes sense that systemd
is dropping support to check for files inside that directory at boot
So no /bin
and /lib
are not for backwards compatibility at all, they are part of the base hierarchy.
Just remove the last double collon, which is a typo in his markup:
It’s the other way around. /bin
, /sbin
and /lib
are the traditional directories holding binaries needed at boot time, but the usr-merge
made those directories into symbolic links to their respective counterparts under the /usr
hierarchy, while systemd
currently still supports the original, non-merged directories.
This support was required because certain distributions had not implemented the usr-merge
by default yet — e.g. on Debian you have to install a special usr-merge
package and run it yourself to move all the stuff over and create the symlinks — and because (open)SUSE did it bass-ackwards; they moved stuff out of /usr/{bin,sbin,lib}
back into the root-level directories.
However, from what it looks like in the link @mithrial posted, the systemd
developers are now about to break booting up with a separate /usr
once again.
They’ve done it before, out of sheer stupidity, because there are reasons for having a separate /usr
, such as mounting /usr
read-only, e.g. if you’re going to be sharing it across the network. When they then realized their stupidity, they had to rush out a solution whereby a separate /usr
could be mounted from within the initramfs
— as it is on my own system here. And so it looks like they’re about to break that too now.

but the
usr-merge
made those directories into symbolic links to their respective counterparts under the/usr
hierarchy
Well tbh, if that user-merge
made those traditional directories into symbolic links pointing to locations under /usr
as destination:
Then im on the same side as the systemd devs
What’s next? all traditional base directories becoming a symbolic link into /usr?
(I guess this is what happens when Micro$@$ minded ppl try to mingle with Unix)
Anyhow lets stop derailing the OP, if you guys want lets create a fresh topic about this

Just remove the last double collon, which is a typo in his markup
I don’t know how I missed that, well spotted.