From: "Theodore Ts'o" <tytso@mit.edu>
To: Grant Taylor <gtaylor@tnetconsulting.net>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] /usr separation
Date: Tue, 23 Feb 2021 13:57:53 -0500 [thread overview]
Message-ID: <YDVQMUG6UXzrPrMh@mit.edu> (raw)
In-Reply-To: <78fede43-bf9b-5a56-5e59-e6ee5a0ee23d@spamtrap.tnetconsulting.net>
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....
next prev parent reply other threads:[~2021-02-23 18:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-20 23:09 [TUHS] Abstractions M Douglas McIlroy
2021-02-21 8:15 ` Otto Moerbeek
2021-02-21 11:08 ` Rich Morin
2021-02-21 22:40 ` Dave Horsfall
2021-02-21 23:01 ` Steve Nickolas
2021-02-23 3:31 ` Andrew Warkentin
2021-02-23 17:29 ` [TUHS] /usr separation (was: Abstractions) Greg A. Woods
2021-02-23 18:28 ` [TUHS] /usr separation Grant Taylor via TUHS
2021-02-23 18:57 ` Theodore Ts'o [this message]
2021-02-23 20:29 ` Grant Taylor via TUHS
2021-02-24 14:14 ` Theodore Ts'o
2021-02-24 17:50 ` Grant Taylor via TUHS
2021-02-24 18:37 ` Theodore Ts'o
2021-02-24 18:48 ` Grant Taylor via TUHS
2021-02-25 3:38 ` Theodore Ts'o
2021-02-24 20:25 ` Steve Nickolas
2021-02-24 22:08 ` Steffen Nurpmeso
2021-02-24 3:12 ` [TUHS] /usr separation (was: Abstractions) Andrew Warkentin
2021-02-22 0:13 ` [TUHS] Abstractions Warren Toomey
2021-02-27 2:47 ` Dave Horsfall
2021-02-23 0:25 ` Wesley Parish
2021-02-23 0:38 ` Steve Nickolas
2021-02-23 2:50 ` Theodore Ts'o
2021-02-23 3:19 ` Warner Losh
2021-02-23 1:47 ` Theodore Ts'o
2021-02-21 22:54 ` Clem Cole
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YDVQMUG6UXzrPrMh@mit.edu \
--to=tytso@mit.edu \
--cc=gtaylor@tnetconsulting.net \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).