Mountpoint for the ESP

[pietinger]

Mountpoint for the ESP


Since 2023-09-13 we have a new mountpoint for an EfiSystemPartition (ESP). This is not an invention of gentoo, but of the UAPI Group:
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

Already in the past there was always confusion about the mountpoint. Therefore I want to explain earlier solutions here first. Possibly (hopefully) it contributes to more clarity.

But before that - to repeat - what has not changed:


UEFI specification

says that the ESP MUST have a FAT filesystem and a primary directory called \efi. In this directory there should be an executable *.efi file in a subdirectory. Example: \efi\gentoo\grubx64.efi. Yes, grubx64.efi is a main part of our grub bootmanager. The other main part of grub resides in /boot/grub/


Mounting the ESP in the past

There were three solutions (the third was rare):

1. The ESP was mounted to /boot. This was also the default in our AMD64 handbook. So you found the grub in /boot/efi/gentoo/grubx64.efi. And the second part of grub (in /boot/grub) was therefore also on the ESPartition.

2. Other distributions (and also some Gentoo users) did not want the second part of grub to be on a FAT partition, so they created a subdirectory "efi" in the /boot directory and mounted the ESP to /boot/efi. So you found the grub in /boot/efi/efi/gentoo/grubx64.efi. And the second part of grub (in /boot/grub) was therefore on your root partition !

3. Some wanted to have both separated and created two additional partitions. A normal ESP and an additional partition for /boot. They then mounted these to /boot. There was also a directory /boot/efi and mounted the ESP (just like in solution 2) to /boot/efi. So you found the grub in /boot/efi/efi/gentoo/grubx64.efi. And the second part of grub (in /boot/grub) was therefore on an extra partition !


Mounting the ESP to /efi

Now what solution we have now if we mount the ESP to /efi ? If you compare it to old solutions then we have now a solution 2 with one difference: The ESP is not mounted on /boot/efi. Instead, it is now mounted directly to the primary directory /efi. So you found the grub in /efi/efi/gentoo/grubx64.efi. And the second part of grub (in /boot/grub) is therefore on your root partition !



Rant: If I add a new primary directory to our Linux root directory - as mountpoint for a partition - then I would name it so that it is immediately obvious which partition i am mounting there: /esp

Then I would also have a nice /esp/efi/gentoo... instead of the idiotic /efi/efi/gentoo ... but it was not my/our decision ...



Edit 2023-09-21: I have added the missing / as pjp ask later. Thanks a lot, pjp !

[NeddySeagoon]

pietinger,

It does not matter where the EFI System Partition is mounted. There are two cases to consider.

1. At boot time when the the UEFI firmware is looking for an .efi file to execute.
The kernel is not yet loaded, so the kernel filesystem tree does not yet exist.
The UEFI firmware reads the partition table(s) which must be GPT to find the partition tagged ESP. There should be exactly one.
That is required to have an EFI directory, as you say.
It has a hard coded path that on x64 is EFI/Boot/bootx64.efi with respect to the ESP which will be loaded if the efivars don't say to do something else.

2. Once the kernel is running and something in the ESP needs to be updated/added/deleted.
The ESP needs to be mounted in the kernel filesystem tree somewhere.
The somewhere is not important as long as the update commands, whatever they are, act on the right thing.

The handbook makes certain assumptions to make it easy to follow and we need users to follow that to make support consistent too.
The point here is that only case 1. is forced my the UEFI standard.

For case 2, do whatever works but be careful not to make support difficult.

-- edit --

That means you can have your esp/efi if you want to. :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pietinger]

[NeddySeagoon]

pietinger,

I wasn't really addressing you personally, I know you know ... :)

I was aiming to provide some background to others finding you post in years to come.
It another one of those standards that everyone knows and hates but they use it anyway.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pjp]

[GDH-gentoo]

[Anon-E-moose]

I have a simple uefi setup.

/boot is my efi partition

[szatox]

Looks like change made for sake of changing something, but at least it's likely a nothingburger. I wonder if it's going to affect already installed systems though.
Probably not. GRUB's boot list is not on efi, refind doesn't even have one, and bootloader doesn't do enough before excusing itself out of memory to _require_ updating binaries, so whatever.
Will handle it once it's here, if it really needs it.

[stefan11111]

I don't get what all this means.
Do I have to freeze grub at a certain version so things don't break?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"

[sMueggli]

[sMueggli]

[pjp]

Thank you.

[pietinger]

[pjp]

[pjp]

[szatox]

[pingtoo]

Allow me to jump in try to make some clarification.

There are two aspects to UEFI,

1. the computer firmware that implement Unified Extensible Firmware Interface (UEFI)
2. the tool that manipulate UEFI Variables

The first part of UEFI as "boot loader" is loading "UEFI application", A Linux stub-kernel could be kind of "UEFI application", A grub executable can be wrap in a format compatible to "UEFI application" therefor computer can start linux directly or start grub as second stage boot loader. rEFInd is yet another "UEFI application"

Once UEFI firmware load the UEFI application than the execution is transfer to the UEFI application entrypoint for continue execution. At this point UEFI firmware no longer matter.

the UEFI specification expect the computer node have data storage device have EFI System Partition (ESP). in the ESP it is expect to have a UEFI specified FAT file system. The FAT file system structure is not set by UEFI specification. However it did define a fallback position in case of all else failed. the fallback path for the default UEFI application is \EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI. The ".efi" file extension name is important, I think the specification said all "EFI application" must have the ".efi" file extension.


Now come to the second part, manipulate UEFI Variables. The UEFI specification define many "Services", for managing boot a "Variable services" is defined, in PC it is usually implemented use NVRAM. And Linux have a special virtual file system module "efivarfs". Once the "efivarfs" mounted under /sys/firmware/efi the tool "efibootmgr" can interact with UEFI "Variable services".


The grub and possible rEFInd installation procedure also manipulate UEFI variables, specifically UEFI boot* variables.



Now the "mountpoint" concept come to play, It is the installation procedure (grub-install for example, or manually if you know how) that have certain expatiation, the "mountpoint" is where the install procedure copy the "UEFI application" to the a specific location under "mountpoint" in order to match what is in UEFI boot* variables.

So the "mountpoint" is a Linux concept, more specifically it is the installation procedure tool requirement. It is not defined is UEFI specification.

So pietinger post and/or Gentoo Wiki is try to establish a convention. The convention make support much easier. if you follow the convention than many small detail can be skip, just check a few place generally we can found where the cause is. Whereas if you know what you are doing you don't need to follow the convention, however if you require support, a lot more questions need to be asked in order to understand the current state before even start debug.


Finally please forgive my grammar mistake in post, English is not my first language. I welcome any correction and will correct them in my post.

[GDH-gentoo]

[Anon-E-moose]

What the mountpoint is called doesn't matter, it could be /boot, /efi, /EFI or even /magic.

But within the efi partition it needs to have a boot and an EFI directory,
the default for boot is BOOTX64.EFI (capitalization doesn't matter) that is the default loader if nothing else is used
the EFI partition has possible directories under it with *.efi loaders, ie /boot/EFI/gummiboot/gummibootx64.efi (/boot is mount point, EFI is dir on EFI partition)
with gummiboot being a directory for the efi program.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[pietinger]

[pingtoo]

pietinger,

Thank you for your respond.

So now we want to call UAPI group a "Standard" body? As we all know "The wonderful thing about standard is there are so many"

My apology, I should not said you or Gentoo developers are creating convention.

However in my mind the UAPI group is just trying to establish convention, I see no existing body claim adaption of the UAPI specification.

Why I call it convention? again it is detail in my post, because there is no program that actually hard coded to expect the specified mountpoint. It is just as easy to use anywhere in the file system as mountpoint for the ESP partition and make installation into under the mountpoint path.

One of the dangerous thing about our Wiki is that either it is out dated or change too frequent. I remember either in this thread or another thread that someone was caught off guard that Wiki changed after he/she post and claim it was following Wiki.

I wish our Wiki as well as Ebuild can be tread as cooking recipe as opposed as some kind of gospel that one must follow to exactly. It would be much better to help some one understand the intrigue detail of why than to said just do it this way.

[pietinger]

[pingtoo]

[pietinger]

[ozcircuit]

Hi,

Well the /boot partition (vfat EFI filesytem) doesn't need to be automounted in /etc/fstab when accessed with kernel/initrd at startup (grub or stub kernel).

One can mount the partition when he needs read or write access to it. The remaining partitions are LUKS encrypted.

The /boot partition is not encrypted and can be accessed with a rescue disk. I wonder /boot can me moved to the LUKS encrypted volume though ?