A partition to install apps on?

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. :stuck_out_tongue:

[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
e3fe76c9-8dea-4a27-8f47-839bb464f022 /srv
db2385c9-2715-408e-96b4-52086a0292fe /home
bdf6a9f6-a2a7-47a0-ba6f-7bbf71a01a95 /var

[aragorn] > 

Read the tutorial. :wink:

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? :face_with_monocle:
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.

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

That is because the system manager is initialized during that phase… it is PID 1 for a reason…

Thanks :wink:

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.



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

So no /bin and /lib are not for backwards compatibility at all, they are part of the base hierarchy. :wink:

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. :man_facepalming:

1 Like

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 :woman_shrugging:
What’s next? all traditional base directories becoming a symbolic link into /usr? :joy:
(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 :wink:

I don’t know how I missed that, well spotted. :slight_smile: