From: Victor Ivanov <vic.m.ivanov@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Boot and EFI partitions
Date: Wed, 6 Dec 2023 18:48:41 +0000 [thread overview]
Message-ID: <CAB=_hA5dPJFUJ+dzgBker8L9B8OWr5iSLXgQ74uqf9Pw7UKyQg@mail.gmail.com> (raw)
In-Reply-To: <5016238.mAOz24JPc2@invader>
On Wed, 6 Dec 2023 at 17:35, Marco Rebhan <me@dblsaiko.net> wrote:
> No, you do not need an XBOOTLDR partition with systemd-boot and in fact I have
> never used one, and I'm not sure why the guide advertises it so prominently.
>
Good to know! Then I'm not sure why the guide is advocating for one if
they're both FAT32. And, as I mentioned earlier, the Boot Loader
Specification doc does suggest that it's optional, so I would have
been surprised if any implementation would require the partition.
> There seems to be a lot of cargo cult around boot partitions (probably left
> over from the BIOS days), you really only need the ESP. The set up I have used
> for years is ESP at /boot, containing systemd-boot, kernel, initramfs and so
> on, and that's it (excluding of course / and other actual system partitions).
>
I disagree that it's _just_ BIOS days thing. While you can,
irrespective of boot loader, have all of your kernel and initrd images
dumped into ESP without any functional issues and do away with a
separate partition, there are benefits to the contrary. One such
benefit is journaling. Unless your EFI firmware allows for a non-FAT32
ESP, then storing the kernel and initrd images will need to be on a
separate partition.
While data corruption during write operations on this partition, given
its usage patterns, is perhaps highly improbable it's certainly not
impossible. So while the benefits of a journaling system for /boot may
be small, they can be a legitimate consideration.
In this line of reasoning, perhaps the boot loader guide(s),
particularly the one in the Handbook, are aimed at covering a
partition layout that:
a) is compatible between EFI and BIOS set ups (with difference being ESP);
b) is consistent across boot loader choices and compatible enough if
one should wish to switch from one to the other at a later point;
c) allows for cases where rootfs may not be readable by a boot loader
(e.g. encryption as previously mentioned); and
d) offers a degree of protection from corruption on writes;
while leaving the coverage various possible layout choices to those
that are more familiar with what they're doing. So some of it may be
baggage from BIOS days, I admin, I also would not be surprised if it
was a conscious decision to reduce the complexity of a first-time set
up by someone new to Gentoo. A 50+ page document, while exhaustive,
certainly wouldn't classify as a "handbook" or something to use as a
reference.
Regards,
Victor
next prev parent reply other threads:[~2023-12-06 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 15:32 [gentoo-user] Boot and EFI partitions Peter Humphreey
2023-12-06 16:36 ` Jack Ostroff
2023-12-06 18:46 ` Wols Lists
2023-12-06 16:49 ` Victor Ivanov
2023-12-06 17:34 ` Marco Rebhan
2023-12-06 18:08 ` Michael
2023-12-06 18:48 ` Victor Ivanov [this message]
2023-12-07 11:51 ` Peter Humphrey
2023-12-08 11:02 ` Peter Humphrey
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='CAB=_hA5dPJFUJ+dzgBker8L9B8OWr5iSLXgQ74uqf9Pw7UKyQg@mail.gmail.com' \
--to=vic.m.ivanov@gmail.com \
--cc=gentoo-user@lists.gentoo.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