A partition to install apps on?

[Edward78]

Can you have another partition you can install apps to like a /usr partition for apps?

[Aragorn]

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.

[Tip] Root filesystem nearly full but got a spare partition sitting around? Split off some stuff!

Difficulty: ★★★☆☆ Introduction As you should all already know by now, GNU/Linux is a FLOSS variant of the UNIX operating system design, and UNIX does not know the concept of drive letters, nor does it approach storage from the vantage of having different volumes. Instead, everything is mounted into a uniform directory hierarchy, so that regardless of what physical medium any particular group of files resides on ─ even if this physical medium is actually located in another computer across the…

[mithrial]

No, systemd recently removed support for having /usr on a separate partition.

[Edward78]

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?

[Aragorn]

@mithrial

systemd recently removed support for having /usr on a separate partition.

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] > 

---

@Edward78

So I have a unalocated drive, just install onto it or partition first?

Read the tutorial.

@Edward78

Do I need to make it GPT?

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.

[Edward78]

I think I will just instaal how I did it the first, let it take all the drive, or just partion on install.

[TriMoon]

@Edward78

Can you have another partition you can install apps to like a /usr partition for apps?

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…

@mithrial

No, systemd recently removed support for having /usr on a separate partition.

Ohh?
Can you provide a link to the source where that is announced?
(Sounds highly doubtful)

[mithrial]

@TriMoon

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.

[TriMoon]

@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

@mithrial

However, probably, the important thing is during boot.

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

[mithrial]

Thanks

[dmt]

@TriMoon

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.

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:

@mithrial

@mithrial

From https://github.com/systemd/systemd/releases/tag/v253:

That’s 404 for me.

[TriMoon]

@dmt

and they’ll stop looking in /bin, /lib etc.

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.

@dmt

That’s 404 for me.

Just remove the last double collon, which is a typo in his markup:

Release systemd v253 · systemd/systemd

[Aragorn]

@TriMoon

@dmt

and they’ll stop looking in /bin, /lib etc.

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

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.

[TriMoon]

@Aragorn

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

[dmt]

@TriMoon

Just remove the last double collon, which is a typo in his markup

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