@MSGID: 3:633/10 85406b19
@REPLY: 3:633/10 709d74e1
@PID: PyGate 1.5.13
@TID: PyGate/Linux 1.5.13
@CHRS: CP1252 2
@TZUTC: 1100
@REPLYADDR: bp@www.zefox.net
@REPLYTO: 3:633/10 UUCP
@RFC-Message-ID: <10pig5v$198or$1@dont-email.me>
No words but "thank you!", that`s an eloquent tutorial.
Clearly my goal was mistaken.

bob prohaska

Richard Kettlewell <invalid@invalid.invalid> wrote:
> 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.
> 

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