@MSGID: 3:633/10 709d74e1
@REPLY: 3:633/10 49ddf724
@PID: PyGate 1.5.13
@TID: PyGate/Linux 1.5.13
@CHRS: CP1252 2
@TZUTC: 0000
@REPLYADDR: invalid@invalid.invalid
@REPLYTO: 3:633/10 UUCP
@RFC-Message-ID:
<wwvbjgjtr76.fsf@LkoBDZeT.terraraq.uk>
bp@www.zefox.net writes:
> Richard Kettlewell <invalid@invalid.invalid> 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)
SEEN-BY: 19/10 50/109 153/757 218/840 840 220/70
221/1 6 360 226/17 100
SEEN-BY: 229/426 240/1120 267/800 301/1 113 812
310/31 335/364 341/66 463/68
SEEN-BY: 633/10 280 414 416 418 420 422 509 2744
712/848 770/1 3 100 340 350
SEEN-BY: 772/210 220 230 5019/40 5020/715 848 1042
4441 12000 5030/49 722
SEEN-BY: 5030/1081 1474 5053/55 5061/133 5075/128
@PATH: 633/10 280 770/1 218/840 221/6 301/1
5020/1042 4441