23 Feb
2021
23 Feb
'21
7:57 p.m.
On Tue, Feb 23, 2021 at 11:28:13AM -0700, Grant Taylor via TUHS wrote:
What that fails to take into account is if the system actually uses an
initrd / initramfs or not. Many of the systems I maintain do /not/ use an
initrd / initramfs. Thus the systems have /some/ actual /need/ to be able
to bring up a minimal system to repair file system problems. Even if the so
called problem is simply that the extent file system needs an fsck with
human interaction (time since last check and / or maximum number of mounts).
There are two reasons why you might want to have an initramfs. One is
you are using a distribution-provided generic kernel, in which case
the device driver / kernel modules needed to access the root file
system needed to be loaded from *somewhere*, and that's the in-memory
initramfs/initrd.
The other reason is how you run fsck on the root file system. 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. 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. 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.
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.)
*/boot still tends to be it's own file system on
Linux, mostly because
that's where the initrd / initramfs image live which contain drivers for
more fancy things (software RAID, LVM, ZFS, SAN, etc.) which are needed to
bring up / (root).
/boot needs to exist due to limitations to the firmware and/or boot
loader being used. 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. 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.
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.
- Ted
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....