BBS: TELESC.NET.BR
Assunto: Re: Adding a hardware swap partition
De: Richard Kettlewell
Data: Thu, 19 Mar 2026 22:00:45 +0000
-----------------------------------------------------------
bp@www.zefox.net writes:
> Richard Kettlewell wrote:
>> You seem to have a misapprehension about /sbin. It?s not some kind of
>> ?stuff you need to boot? directory. It?s 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. You?d 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 don?t 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?
It?s 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 computer?s 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 can?t 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 ?init? program found within the ramdisk.
This is usually a shell script (though it doesn?t 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 doesn?t 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 what?s inside the initramfs, have a look in
/boot. You?ll 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 I?m
trying to dissuade you from is that ?the root filesystem? has to include
/usr (the real one, not the initramfs?s 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 isn?t then quite early in the process you?ll
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.
--
https://www.greenend.org.uk/rjk/
--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
-----------------------------------------------------------
[Voltar]