Re: [TUHS] /usr separation

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 4716 bytes --]

On 2/23/21 11:57 AM, Theodore Ts'o wrote:
> There are two reasons why you might want to have an initramfs.
Rather than getting into a tit for tat debate, I'll agree that we have 
both proposed reasons why you /might/ want to use an initramfs.  The 
operative words are "you" and "might".  Each person probably wants 
slightly different things.  It's far from one size fits all.

> The other reason is how you run fsck on the root file system.

The same way that it's been done for years.  Root is mounted read only 
and you run fsck to repair damage.  If it's severe damage, you will 
likely need to boot off of something else.  I've had both situations 
happen multiple times.

The quintessential max mount count / max days since last check have 
happily been fixed while root was mounted read only.

> That won't be needed if hardware is perfect, the kernel is 
> bug-free(tm), and the root file system has journalling support, 
> as all modern file systems tend to have.

I wouldn't bet on that.  I've had to run fsck on journalling file 
systems at boot / mount time multiple times.

> However, if it is needed, there are two ways to do this.  One is the 
> traditional way, which is to mount the root file system read/only, 
> repair the file system, and if any changes were required to the root 
> file system, force a reboot; otherwise, remount the root file system 
> read-write, and proceed.

This is what happened in /most/ of the cases that I've needed to 
interact with fsck of a root file system.

> The other way of doing this is to include the fsck program in the 
> initrams, and run fsck on the root file system before it is mounted. 
> Now you never have to worry about rebooting if any chances were made, 
> since the root file system wasn't mounted and so there is no danger 
> of invalid metadata being cached in memory.

Oh ... I would definitely *NOT* say /never/.  There are ways that a file 
system can get corrupted that will cause fsck to stop and require manual 
intervention.

> That being said, it's certainly possible to skip using an initramfs; 
> it's geenrally not required, and if you're building your own kernel, 
> with the device drivers you need for your hardwaer compiled into 
> the kernel, most distributions will support skipping the initramfs. 
> (Debian certainly does, in any case.)

And if you're building a minimal kernel, removing support for modules 
and what's required for swing-root saves space.  ;-)

> /boot needs to exist due to limitations to the firmware and/or boot 
> loader being used.

Not necessarily.  E.g. one single partition containing /boot and / (root).

> If the boot loader is using the legacy PC Bios interfaces to read the 
> kernel and initial ramdisk/file system, then those files need to be in 
> a low-numbered LBA disk space, due to legacy BIOS/firmware limitations.

So make sure said /boot & / (root) partition stays within that 
limitation.  I don't recall exactly what that is.  I think it's ~8 GB. 
But it's definitely possible to have small installations in that space.

> It could also be a concern if you are using some exotic file system 
> (say, ZFS), and the bootloader doesn't support that file system due 
> to copyright licensing incompatibilities, or the boot loader just not 
> supporting that bleeding-edge file system.  In that case, you might 
> have to keep /boot as an ext4 file system.

That scenario is definitely a possibility.  Though such scenarios are 
not a requirement and tend to be antithetical to minimal installations, 
like the type that would be used in embedded devices and possibly copied 
to ROM as indicated in a different post.

> Other than that, there is no reason why /boot needs to be its own 
> file system, except that most installers will create one just because 
> it's simpler to use the same approach for all cases, even if it's 
> not needed for a particular use case.

As Steve Gibson is famous for saying; The tyranny of the default.

> P.S.  Oh, and if you are using UEFI, you might need to have yet 
> another file system which is a Microsoft FAT file system, typically 
> mounted as /boot/efi, to keep the UEFI firmware happy....

Yes, the file system needs to exist.  But that's part of the firmware, 
not the operating system.  I also question if that FAT file system needs 
to be mounted or not.  --  I don't know how GRUB et al. deal with a 
non-mounted UEFI file system.

But even if it does need to be mounted, you can still get away with two 
partitions; / (root) and /boot/efi.  I suspect UEFI does away with the 
LBA issue you mentioned.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]