23 Feb
2021
23 Feb
'21
9:29 p.m.
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