Preparing for a merged /usr in Debian

Posted Jan 19, 2016 9:02 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: Preparing for a merged /usr in Debian by walex
Parent article: Preparing for a merged /usr in Debian

> The solution that exists and has existed for decades and has worked well for decades is to mount am ordinary '/' filesystem at first-stage boot and use that to mount '/usr'

That's certainly a thing you could do, but now you have two choices:

1) Have /var, /home and /etc be part of /, and so be unencrypted
2) Have /var, /home and /etc be separate partitions, and introduce additional complexity (how do you know where /etc is if /etc isn't already there?)

Both of these choices are bad, and so your solution is a bad solution and has not worked well for decades.

Preparing for a merged /usr in Debian

Posted Jan 19, 2016 19:25 UTC (Tue) by walex (guest, #69836) [Link] (2 responses)

It seems that I need to explain again the basics of how the boot process works and how UNIX/Linux sytems wor k in repect of the mount and pivot_root system calls, I'll try to keep it short:

It is impossible to avoid using a static kernel and a simple root filesystem to boostrap the process of getting to a complex-configuration / or /usr or anything else.
The only choice is which "static kernel" and "simple root" to use.
Currently the "static kernels" and "simple root" are the GRUB kernel (stage2) plus its root filesystem /boot and the Linux kernel it loads plus its stage 1 "simple root", the "initramfs" instantiated from the associated static snapshot loaded from /boot.
They can both be replaced with the Linux kernel and a / filesystem.
That / filesystem for stage 1 booting can be but does not need to be the stage 2 / filesystem anymore than the GRUB kernel /boot root needs to part of the stage 2 / or /usr filesystem or the "initramfs" snapshot image need to be stored on those stage 2 / or /usr filesystems.

The outline boot sequence can therefore well be:

Linux kernel is booted mounting /dev/sda1 as /, which contains a fully functional but "vanilla" / filesystem.
Linux kernel loads from it modules, runs scripts, does whatever it takes to unencrypt and prepare for mounting /dev/sda2 which contains /etc, /bin, /var, /home, ... /usr.
Then something like mount /dev/mapper/sda2 /newroot and pivot_root /newroot. In simpler times that would be instead something like mount /dev/mapper/sda2 /, and I have done something like that many times in the distant past. and occasionally in the recent past (e.g. after boot from live-CD)
Linux kernel remounts the "vanilla" root in /dev/sda1 as /boot :-).

That the above, which seems to me basic system knowledge, needs explaining again and again in detail is quite frustrating; as I wrote a few times already, the first-stage boot / (or kernel) does not need to be the very same as the the second-stage / (or kernel), and indeed in the current arrangement there are another two.

Plus there is mount --bind for an alternative option.

Anyhow in the current practice GRUB's root (first-stage root) /boot is inside an unencrypted partition distinct from that containing / (second/third stage root) and someone could replace anyhow its contents with suitably "improved" kernel images or "initramfs" snapshot images. I know people who understand boot processes and who keep /boot (only) on a USB storage device they carry with them at all times because they reckon that an encrypted / with an unencrypted /boot is not giving them peace of mind.

Preparing for a merged /usr in Debian

Posted Jan 19, 2016 19:38 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

If /dev/sda1 is used only for boot and then gets dropped, it's actually identical to an initramfs except none of the tooling to keep it in sync with the rest of the system exists and you can't use it for netbooting so it's precisely as complicated but less flexible and nobody's written the software that you'd need to make it work. And you still don't have a way to choose a kernel unless you're using kexec, which isn't an option. The reason we do things the way we do is that it works better than what you're proposing.

Preparing for a merged /usr in Debian

Posted Jan 20, 2016 9:00 UTC (Wed) by anselm (subscriber, #2796) [Link]

Linux kernel is booted mounting /dev/sda1 as /, which contains a fully functional but "vanilla" / filesystem.

This is essentially what happens with initramfs, except that the initramfs is loaded using the boot loader/system firmware, and can in principle come from anywhere (including a remote server). Your approach forces you to have the first-stage “/” available locally as an actual file system on a storage medium, which sucks if you want to have a diskless system.

You still need to ensure that whatever is on the first-stage “/” matches the rest of the system, just like with an initramfs. The difference is that the process of making initramfses is fairly well-understood and there are good tools for it already.

Anyhow in the current practice GRUB's root (first-stage root) /boot is inside an unencrypted partition distinct from that containing / (second/third stage root) and someone could replace anyhow its contents with suitably "improved" kernel images or "initramfs" snapshot images. I know people who understand boot processes and who keep /boot (only) on a USB storage device they carry with them at all times because they reckon that an encrypted / with an unencrypted /boot is not giving them peace of mind.

Two points:

Your approach doesn't help these people because your first-stage “/” can't be encrypted either, since the Linux kernel has no way of getting at a pass phrase to decrypt the first-stage “/”. They will have to put their first-stage “/” on a removable storage device just like they do now with “/boot”.
It is quite possible for GRUB to use an encrypted “/boot” (see, e.g., here), although it is not what distributions do by default.