On 2026-03-15 at 19:53 ADT, bp@www.zefox.net <bp@www.zefox.net> wrote:
Jim Diamond <zsd@jdvb.ca> wrote:
Yes, but that has nothing much to do with the OP's plan to put /usr on its >>> own partition. He didn't indicate where /home was going, but if he puts it >>> on the root partition, he can still fill that up. And if /var is on /root, >>> also problems.
Which is why I was curious about why he wants to a separate /usr partition.
Since you ask...8-)
Thanks. :-)
On rare occasions my 8GB Pi5 slowed to a crawl. Eventually I realized it
was happening when I had two browsers (firefox and chromium) both running
with too many tabs open. The system was short of memory. It needed swap
to cope this those occasions.
So far, I follow you.
Hardware swap is _supposed_ to be faster than a swap partition, which
made it, at least in principle, more attractive. Also, in principle, a
physical swap partition can be placed _between_ (in the sense of seek
stroke) /uar and /, minimizing the amount of head movevent. This was true >> in the days of st506 disks, I'm not sure how true it is with SATA. So, I
inquired about how this might be done under RasPiOS. It's not hurgely
hard under FreeBSD and I thought there might be some nifty tools for the
purpose in RasPiOS.
Assuming you are using a mechanical disk (I don't think you said anywhere, did you?), there is some (a smallish?) gain to be had for minimizing head movement. If you are using an SSD through some SATA-USB dongle, then you
can completely forget about worrying where on the disk to put swap... the
end is fine.
Carrying on with the assumption that you are using a mechanical disk...
Someone else already pointed out that /sbin is (on Raspberrry Pi OS and
many others) just yet another sym link. On current systems where /bin is just a link to /usr/bin, except for occasional updates for log files, I
doubt that your system would be accessing / (the "without /usr" version of
/) very often. (Unless your /tmp is not a tmpfs and you are using /tmp a lot, for whatever reason.)
You also didn't tell us where /home is going to be. Were you thinking
of having it on its own partition? That decision may be more significant than any possible benefit from separating /usr from /.
The answers received have now led me to question the orignal premises.
No nifty tools have come to light. The relative speed of
file-vs-hardware swap haven't been quantified. The need for occasional
swap use remains, but it's sporadic. Maybe a swapfile is good
enough.... it's certainly easier.
That is true.
It was a surprise to learn that a single partition is somehow required
for RasPiOS to function correctly. If true, it's a good thing to know.
You mean "a single partition for / and /usr" ?
I'm not sure that it is required, but I wouldn't be surprised if having
/usr on its own partition caused problems. But I'm happy to be educated about that!
Back in the good old days there were enough programs in /bin (which was an >>> actual directory, not a link to /usr/bin) to recover a system with disk
errors (when possible, anyway). But now that /bin is a link, I wonder if >>> the system will even boot properly, since "user space" would have to mount >>> /usr before almost all (all?) programs are available. Including systemd.
Given that RasPiOS has an /sbin directory, I'm pretty sure the machine
will come up at worst in single-user if /usr can't be mounted normally.
See above.
Whether /home/, /var/ and /tmp/ can be links to /usr is less clear to
me at this point.
/home certainly can, and if /usr gets mounted "early enough" during boot, maybe /var and /tmp can be too. But if you do that, you now have a
minuscule amount of stuff sitting there by itself on /, and I can't imagine the benefit of having swap between "almost nothing" and "almost everything".
The original plan would have left the machine with a /root of around
100GB and a /usr of around 800GB so running out of space isn't a problem.
OK. I thought it your original message you said something about making /
as small as possible.
OP, where are you... ?
Busy trying to drink from a firehose 8-)
Tricky to not drown. Although I've seen dogs trying to drink from garden hoses, it might just be a matter of scale.
If I was going to set up swap it seemed prudent to make it as fast
as I reasonably could. I didn't (and so far still don't) have a clear
idea how much difference a swap file versus a swap partition makes.
Since /sbin isn't a freestanding directory, this seems impossible
without booting from a separate root device, likely a microSD. I
didn't see this hurdle coming, at all. It isn't a fatal blunder, but
it's a blunder.
bp@www.zefox.net writes:
If I was going to set up swap it seemed prudent to make it as fast
as I reasonably could. I didn't (and so far still don't) have a clear
idea how much difference a swap file versus a swap partition makes.
The only way to be find out is to measure it under a representative
workload, but the likely outcome is that the difference will be
negligible or undetectable.
Since /sbin isn't a freestanding directory, this seems impossible
without booting from a separate root device, likely a microSD. I
didn't see this hurdle coming, at all. It isn't a fatal blunder, but
it's a blunder.
You seem to have a misapprehension about /sbin. ItrCOs not some kind of rCLstuff you need to bootrCY directory. ItrCOs for utilities used for system administration and other root-only commands.
The way to make a separate-/usr system bootable is to ensure that the initramfs mounts /usr, as already discussed. You donrCOt need a separate device for that.
I don't see an initramfs
manpage. There apropos references to it, but nothing explaining
its purpose. What's it for?
Richard Kettlewell <invalid@invalid.invalid> wrote:
You seem to have a misapprehension about /sbin. ItrCOs not some kind of
rCLstuff you need to bootrCY directory. ItrCOs for utilities used for system >> administration and other root-only commands.
But those utilities are needed during the partition resize, creastion, copying and mounting processes if I want to "clean out" the duplicated
/usr files.
The way to make a separate-/usr system bootable is to ensure that the
initramfs mounts /usr, as already discussed. You donrCOt need a separate
device for that.
This touches on something I wasnt aware of. I don't see an initramfs
manpage. There apropos references to it, but nothing explaining
its purpose. What's it for?
bp@www.zefox.net wrote:
I don't see an initramfs manpage. There apropos references to it, but
nothing explaining its purpose. What's it for?
I am sure Richard can do much better, BUT AIUI initramfs is a RAM
based filesystem that is responsible for installing the final file
system, as such it loads complete as a ram image off the boot disk and
then can mount disks, (load the final OS ?) and start to use it.
I am unclear as to whether the kernel it uses is a stripped down or a
final version however
This touches on something I wasnt aware of. I don't see an initramfs
manpage. There apropos references to it, but nothing explaining
its purpose. What's it for?
bp@www.zefox.net writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
You seem to have a misapprehension about /sbin. ItrCOs not some kind of
rCLstuff you need to bootrCY directory. ItrCOs for utilities used for system
administration and other root-only commands.
But those utilities are needed during the partition resize, creastion,
copying and mounting processes if I want to "clean out" the duplicated
/usr files.
Yes. YourCOd also need things conventionally found in /bin (today,
/usr/bin) for that.
The way to make a separate-/usr system bootable is to ensure that the
initramfs mounts /usr, as already discussed. You donrCOt need a separate >>> device for that.
This touches on something I wasnt aware of. I don't see an initramfs
manpage. There apropos references to it, but nothing explaining
its purpose. What's it for?
ItrCOs there to bridge the gap between the boot loader and the root filesystem.
A typical Linux boot process looks like this:
1) The computer is powered up or reset.
2) The computerrCOs built-in firmware runs. This would be UEFI on a Mac or
PC, or the EEPROM on a Pi.
3) The device firmware loads a boot loader. This would often be Grub on
a PC. Sometimes the boot loader is built into the firmware (e.g. Pi
4B and later).
4) The boot loader loads a Linux kernel.
What we want to do next is run the kernel, which should then mount the
root filesystem and run init. But to do that the kernel may need a
number of things:
- device drivers for the physical storage device containing the root
file system
- if root filesystem is across a network, then network drivers and
network configuration
- if the storage is encrypted, a driver for the encrypted storage, and
the passphrase or key that unlocks the storage
- if the root filesystem is on software RAID or LVM, it needs the kernel
components for those and may also need to run user-space components to
properly configure access to them
- the driver for the filesystem used by the root filesystem (ext4, zfs,
etc)
In principle many of these things could be hard-coded into the kernel,
and many years ago they were - we all rebuilt our kernels manually with
just the drivers we thought we needed, and put configuration (e.g. root device name) on a kernel command line in the boot loader configuration.
However, a Linux distribution generally wants to support as wide a range
of possible configurations as possible and adding all possible drivers
that anyone might need would make the kernel unreasonably large. So the drivers are kept in separate files and loaded when needed.
This creates a chicken-and-egg problem: to mount the root filesystem we
need device drivers (and maybe a lot more than that), but if all of
those things are on the root filesystem, the kernel canrCOt load them yet.
The solution is an initramfs, which is essentially a filesystem archive
which contains the kernel modules and user-space executables necessary
to mount the root filesystem. So booting continues:
5) The boot loader loads the initramfs into RAM.
6) The boot loader executes the Linux kernel.
7) The kernel extracts the initramfs archive into (effectively) a
ramdisk.
8) The kernel executes the rCyinitrCO program found within the ramdisk.
This is usually a shell script (though it doesnrCOt have to be).
9) Code within the initramfs loads all kernel modules required and does
any other setup needed to mount the (real) root filesystem
(e.g. reassemble a RAID, acquire a decryption key, etc).
10) When the real root filesystem has been mounted, the initramfs
contents are deleted (to save memory) and the real filesystem is
moved to its proper location, i.e. the / directory.
11) The real init program in the real root filesystem is executed.
This is often systemd (but doesnrCOt have to be).
There are other ways to achieve this, but the above is more or less how
it is typically done in Debian-based systems (which includes the
Raspberry Pi OS).
If you want to see whatrCOs inside the initramfs, have a look in
/boot. YourCOll see one or more files with initrd in the name (for
historical reasons). You can unpack them with unmkinitramfs, e.g.:
$ mkdir initrd
$ unmkinitramfs /boot/initrd.img-6.12.74+deb13+1-amd64 initrd/
$ ls -l initrd/main/
total 28
lrwxrwxrwx 1 richard richard 7 Mar 15 06:16 bin -> usr/bin
drwxr-xr-x 3 richard richard 4096 Mar 19 21:50 conf
drwxr-xr-x 7 richard richard 4096 Mar 19 21:50 etc
-rwxr-xr-x 1 richard richard 6787 May 13 2025 init
lrwxrwxrwx 1 richard richard 7 Mar 15 06:16 lib -> usr/lib
lrwxrwxrwx 1 richard richard 9 Mar 15 06:16 lib32 -> usr/lib32
lrwxrwxrwx 1 richard richard 9 Mar 15 06:16 lib64 -> usr/lib64
drwxr-xr-x 2 richard richard 4096 Mar 15 06:16 run
lrwxrwxrwx 1 richard richard 8 Mar 15 06:16 sbin -> usr/sbin
drwxr-xr-x 8 richard richard 4096 Mar 19 21:50 scripts
drwxr-xr-x 7 richard richard 4096 Mar 19 21:50 usr
The initramfs here has its own private /usr l-)
The relevance of all this to the separate /usr configuration that IrCOm trying to dissuade you from is that rCLthe root filesystemrCY has to include /usr (the real one, not the initramfsrCOs private /usr).
Typically that is done by having it all be in one big root filesystem
but as long as /usr is there by step 11, then in at least in theory, you should be golden. If it isnrCOt then quite early in the process yourCOll
find that something assumes it is present and falls over in its absence;
on a modern Debian-derivce system the specific issue will be that init
(i.e. systemd) is in /usr, so failure will be immediate.
No words but "thank you!", that's an eloquent tutorial.
Clearly my goal was mistaken.
If I was going to set up swap it seemed prudent to make it as fast
as I reasonably could. I didn't (and so far still don't) have a clear
idea how much difference a swap file versus a swap partition makes.
bp@www.zefox.net writes:
If I was going to set up swap it seemed prudent to make it as fast
as I reasonably could. I didn't (and so far still don't) have a clear
idea how much difference a swap file versus a swap partition makes.
The difference is very little to nothing. It's not like using a swap
file would need to go through the file system layer and all that. Not
since a long time. Here's a discussion thread about the perf difference
from a couple of decades ago, when the 2.6 kernel was new: https://lkml.org/lkml/2005/7/7/326
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 50:17:42 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,859 |