Mailing List Archive

On 12/6/23 10:32, Peter Humphreey wrote:
> Hello list,
>
> I have a new toy to play with - an Intel NUC with i5 (16 threads in all) and
> 1TB superfast M2 SSD. I grew tired of the noise and thirst of my Amari machine
> and I wanted something quiet and frugal, so now I'm building a new Gentoo
> system on it. I want to use bootctl from systemd-boot, as usual, to give me a
> boot menu without that grub monster.
>
> The installation guides on the Web have been developed since I last had a new
> machine, and they attempt to show how boot and EFI partitions should be laid
> out, but there's a problem.
>
> In particular, the Gentoo wiki says I must have an EFI partition of type esp
> [1] - not a directory in, say, /boot, as my other machines have. All right so
> far, but the Gentoo systemd-boot page says I need a /boot partition as well,
> of type XBOOTLDR [2]. So now I seem to need /efi on /dev/nvme0n1p1 and /boot on
> /dev/nvme0n1p2, both with FAT32 file systems.
>
> In fact those two guides contradict each other. One says I must have a boot
> partition, the other that I don't need one on a modern system.
>
> Quandary: if I believe both guides I finish up with both partitions, and then
> 'bootctl install' is happy, but the usual make && make modules-install && make
> install sequence ends up with no kernel in either partition.
>
> I'm getting sawdust under my fingernails.
>
> Has anyone some advice for me?
>
> 1.https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/
> Disks#What_is_the_EFI_System_Partition_.28ESP.29.3F
>
> 2.https://wiki.gentoo.org/wiki/Systemd/systemd-boot#Pre_Deployment_Considerations

Based on an earlier post in the other thread about booting issues, and
not having read the actual docs, it sounds like if you have /efi mounted
as type esp, /boot can just be a directory in whatever is mounted at /;
it no longer needs to be a separate partition.

The way I think of it is that the UEFI firmware needs to find the
xxxx.efi loader, and it can only read FAT32 formatted partitions
labelled as type esp. That xxxx.efi loader then needs to find your
kernel and related files, but as it is specific for that type of kernel
(linux) it can know about more partition formatting options. I suspect
that many (most?/all?) existing linux utilities still expect the boot
dir to be at /boot, but perhaps the docs are late to change describing
that it no longer needs to be a separate partition, or perhaps one or
more of those utilities still requires a partition.

Hopefully this isn't too far off base.

Jack

On Wed, 6 Dec 2023 at 15:32, Peter Humphreey <peter@prh.myzen.co.uk> wrote:
>
> I want to use bootctl from systemd-boot, as usual, to give me a
> boot menu without that grub monster.
>
As a disclaimer, I do not and have not used systemd-boot specifically.
That said...

> In particular, the Gentoo wiki says I must have an EFI partition of type esp
> [1] - not a directory in, say, /boot, as my other machines have. All right so
> far, but the Gentoo systemd-boot page says I need a /boot partition as well,
> of type XBOOTLDR [2]. So now I seem to need /efi on /dev/nvme0n1p1 and /boot on
> /dev/nvme0n1p2, both with FAT32 file systems.
>
This is indeed my understanding as well.

Irrespective of systemd-boot ESP is required for EFI bootloader
executables to be stored into. This is part of the GPT and UEFI
standard, so this should be of type ESP and formatted as FAT32, and is
usually the first partition on the boot drive when using GPT. Not
required for BIOS/Legacy boot, as the guide already mentions.

Moving on to "/boot", it has long been recommended (but not always
required) to have "/boot" as a separate partition. In practice, it
would often be the case (especially with GRUB) that "/boot" could
simply be a directory on your root partition. But sometimes, e.g. with
LVM and/or encrypted root, "/boot" has to be separated out so that the
kernel image could be read and booted by the boot loader before rootfs
could be unlocked. This could be any filesystem recognised by the boot
loader of choice.

So, a typical GPT set up, especially when having encrypted rootfs,
would look something like:

/dev/nvme0n1p1: ESP, GPT type 0xEF00, FAT32, usually mounted under
/efi (preferred) or /boot/efi (legacy)
/dev/nvme0n1p2: boot, GPT type 0x8300, ext3/ext4/etc, usually mounted
under /boot
/dev/nvme0n1p3: rootfs - GPT type 0x8308 if using LUKS, 0x8300 for
standard rootfs

So, without knowing much about systemd-boot from the guide linked it
seems to me that its implementation doesn't differ too much from this
reasonably well established model, except for a few additional
constraints which, based on my understanding, are:
1. You _must_ have an XBOOTLDR partition (functionally equivalent to
"boot" above) _in addition to_ the ESP and cannot simply use "/boot"
under your rootfs partition
2. XBOOTLDR partition _must_ be of GPT type 0xEA00
3. XBOOTLDR partition _must_ have GUID set to
"bc13c2ff-59e6-4262-a352-b275fd6f7172"
4. XBOOTLDR partition _must_ be formatted with a filesystem supported
by your EFI BIOS with FAT32 being universally supported, though your
particular EFI BIOS _might_ support others

I say "must" as it appears to be from the guide like this is the
requirement for systemd-boot, the actual Boot Loader Specification
page appears to suggest that an XBOOTLDR partition is optional. So
there may be a viable configuration without it.

Mount point recommendations seem consistent with previously
established conventions re EFI ESP and /boot.

Hope this helps. I'm happy to be corrected in case I misunderstood
anything specific to systemd-boot.

Best Regards,
Victor

On Wednesday, 6 December 2023 17:49:43 CET Victor Ivanov wrote:
> So, without knowing much about systemd-boot from the guide linked it
> seems to me that its implementation doesn't differ too much from this
> reasonably well established model, except for a few additional
> constraints which, based on my understanding, are:
> 1. You _must_ have an XBOOTLDR partition (functionally equivalent to
> "boot" above) _in addition to_ the ESP and cannot simply use "/boot"
> under your rootfs partition
> 2. XBOOTLDR partition _must_ be of GPT type 0xEA00
> 3. XBOOTLDR partition _must_ have GUID set to
> "bc13c2ff-59e6-4262-a352-b275fd6f7172"
> 4. XBOOTLDR partition _must_ be formatted with a filesystem supported
> by your EFI BIOS with FAT32 being universally supported, though your
> particular EFI BIOS _might_ support others
>
> I say "must" as it appears to be from the guide like this is the
> requirement for systemd-boot, the actual Boot Loader Specification
> page appears to suggest that an XBOOTLDR partition is optional. So
> there may be a viable configuration without it.

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.

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).

-Marco

On Wednesday, 6 December 2023 17:34:08 GMT Marco Rebhan wrote:
> On Wednesday, 6 December 2023 17:49:43 CET Victor Ivanov wrote:
> > So, without knowing much about systemd-boot from the guide linked it
> > seems to me that its implementation doesn't differ too much from this
> > reasonably well established model, except for a few additional
> > constraints which, based on my understanding, are:
> > 1. You _must_ have an XBOOTLDR partition (functionally equivalent to
> > "boot" above) _in addition to_ the ESP and cannot simply use "/boot"
> > under your rootfs partition
> > 2. XBOOTLDR partition _must_ be of GPT type 0xEA00
> > 3. XBOOTLDR partition _must_ have GUID set to
> > "bc13c2ff-59e6-4262-a352-b275fd6f7172"
> > 4. XBOOTLDR partition _must_ be formatted with a filesystem supported
> > by your EFI BIOS with FAT32 being universally supported, though your
> > particular EFI BIOS _might_ support others
> >
> > I say "must" as it appears to be from the guide like this is the
> > requirement for systemd-boot, the actual Boot Loader Specification
> > page appears to suggest that an XBOOTLDR partition is optional. So
> > there may be a viable configuration without it.
>
> 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.
>
> 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).
>
> -Marco

The UAPI Group Boot Loader Specification is trying to square the circle of
multiple OSs overwriting each other's kernel images, boot loaders, menu
entries, etc. and also to automate the creation and maintenance of such
elements by distros.

The XBOOTLDR partition is indeed optional and it depends on what type of
kernel images you use (Type #1 or #2 as they call it). In addition, the
specification explains XBOOTLDR *should*, rather than must, be formatted with
a FAT32 fs. It states the XBOOTLDR partition "... should be a file system
readable by the firmware".

However, if the boot loader's xxxx.efi executable found in ESP is capable of
accessing other filesystems with its own drivers, as indeed GRUB is, then I
think the XBOOTLDR partition can be formatted with ext* instead.

Reading this Boot Loader specification makes me smile at the manual simplicity
of using efibootmgr and xxx.efi kernel images with no 3rd party bootloaders.
:-)

On 06/12/2023 16:36, Jack Ostroff wrote:
> The way I think of it is that the UEFI firmware needs to find the
> xxxx.efi loader, and it can only read FAT32 formatted partitions
> labelled as type esp. That xxxx.efi loader then needs to find your
> kernel and related files, but as it is specific for that type of kernel
> (linux) it can know about more partition formatting options. I suspect
> that many (most?/all?) existing linux utilities still expect the boot
> dir to be at /boot, but perhaps the docs are late to change describing
> that it no longer needs to be a separate partition, or perhaps one or
> more of those utilities still requires a partition.

It's not that far off base ... note that Macs use UEFI, but don't have
FAT32 partitions ...

On the raid wiki I say that you need *some* sort of boot partition, and
say that if you're using legacy (bios) boot you should really put /boot
on its own partition so if you decide to go UEFI, you re-purpose that
partition. It certainly seems weird that systemd-boot would want its own
partition on top of the efi partition :-)

The UEFI spec basically requires - as a minimum - that the UEFI software
in rom must be able to read fat32. There is no requirement that that is
the only format it can read, hence Macs reading the Mac format. If you
want your own boot rom that can read ext*, that's fine (so long as ext32
is also available).

Cheers,
Wol

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

On Wednesday, 6 December 2023 17:34:08 GMT Marco Rebhan wrote:
> On Wednesday, 6 December 2023 17:49:43 CET Victor Ivanov wrote:
> > So, without knowing much about systemd-boot from the guide linked it
> > seems to me that its implementation doesn't differ too much from this
> > reasonably well established model, except for a few additional
> > constraints which, based on my understanding, are:
> > 1. You _must_ have an XBOOTLDR partition (functionally equivalent to
> > "boot" above) _in addition to_ the ESP and cannot simply use "/boot"
> > under your rootfs partition
> > 2. XBOOTLDR partition _must_ be of GPT type 0xEA00
> > 3. XBOOTLDR partition _must_ have GUID set to
> > "bc13c2ff-59e6-4262-a352-b275fd6f7172"
> > 4. XBOOTLDR partition _must_ be formatted with a filesystem supported
> > by your EFI BIOS with FAT32 being universally supported, though your
> > particular EFI BIOS _might_ support others
> >
> > I say "must" as it appears to be from the guide like this is the
> > requirement for systemd-boot, the actual Boot Loader Specification
> > page appears to suggest that an XBOOTLDR partition is optional. So
> > there may be a viable configuration without it.
>
> 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.

I haven't either, as I said, but this is a new venture so I went to the official
guides, wanting to Do The Right Thing. That's where the contradiction exists.

--
Regards,
Peter.

On Thursday, 7 December 2023 11:51:10 GMT I wrote:
> On Wednesday, 6 December 2023 17:34:08 GMT Marco Rebhan 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.
>
> I haven't either, as I said, but this is a new venture so I went to the
> official guides, wanting to Do The Right Thing. That's where the
> contradiction exists.

At the time I started this thread I hadn't reached the fstab creation, so I
did that and now I do get a kernel in /boot, but it's just called 'linux' (I
think - I dismounted and unplugged the USB disk I was transferring the output
below to this machine and the NUC promptly shut itself down. It's quite a
business getting it up again.)

Anyway, 'make install' gives the folowing output:

INSTALL /boot <---
New machine ID '49eccff7c02e4fa38053e7140fd90a5a' generated.
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
Using XBOOTLDR partition at /boot as $BOOT_ROOT.
Using entry token: gentoo
kernel version (6.1.57-gentoo) set via command line.
kernel image file (/usr/src/linux-6.1.57-gentoo/arch/x86/boot/bzImage) set via
command line.
/boot/gentoo exists, using layout=bls.
Using ENTRY_DIR=/boot/gentoo/6.1.57-gentoo
mkdir -p /boot/gentoo/6.1.57-gentoo
Using plugins:
/usr/lib/kernel/install.d/00-00machineid-directory.install
/usr/lib/kernel/install.d/50-depmod.install
/usr/lib/kernel/install.d/90-loaderentry.install
/usr/lib/kernel/install.d/90-uki-copy.install
Plugin environment:
LC_COLLATE=C.UTF-8
KERNEL_INSTALL_VERBOSE=1
KERNEL_INSTALL_IMAGE_TYPE=pe
KERNEL_INSTALL_MACHINE_ID=49eccff7c02e4fa38053e7140fd90a5a
KERNEL_INSTALL_ENTRY_TOKEN=gentoo
KERNEL_INSTALL_BOOT_ROOT=/boot
KERNEL_INSTALL_LAYOUT=bls
KERNEL_INSTALL_INITRD_GENERATOR=
KERNEL_INSTALL_UKI_GENERATOR=
KERNEL_INSTALL_STAGING_AREA=/tmp/kernel-install.staging.30L75M
Plugin arguments: add 6.1.57-gentoo /boot/gentoo/6.1.57-gentoo /usr/src/
linux-6.1.57-gentoo/arch/x86/boot/bzImage
Successfully forked off '(sd-executor)' as PID 71429.
Successfully forked off '(direxec)' as PID 71430.
/usr/lib/kernel/install.d/00-00machineid-directory.install succeeded.
Successfully forked off '(direxec)' as PID 71431.
+depmod -a 6.1.57-gentoo <---
/usr/lib/kernel/install.d/50-depmod.install succeeded.
Successfully forked off '(direxec)' as PID 71432.
Creating /boot/loader/entries/gentoo-6.1.57-gentoo.conf <---
/usr/lib/kernel/install.d/90-loaderentry.install succeeded.
Successfully forked off '(direxec)' as PID 71441.
/usr/lib/kernel/install.d/90-uki-copy.install succeeded.
(sd-executor) succeeded.

Only three of those lines are in the standard white (on black background);
I've marked them with pointers. The others are in grey. That's new to me. In
fact, all that output from 'make install' is new.

I now need to get the kernel name to include the version and the local
version; then I'll be able to show a menu of options at boot time, as on my
other machines.

--
Regards,
Peter.