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/s ... ification/

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

[pietinger]

That means you can have your esp/efi if you want to.

Yes ... I know that all ... hehe ... what do you think I will do if I have to install a new gentoo again

BUT ... I cannot and must not recommend this of course, because the standard is our AMD64 handbook !

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

[pjp]

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 /bootgrub/

I presume /bootgrub/ is meant to be /boot/grub/ (slash between boot and grub)?

I think there might be slight variations for non-Grub. I use rEFInd. I have no idea how other non-Grub EFI bootloaders compare.

I have my first partition as a 2M "BIOS boot". I don't remember what it was supposed to do.
My second partition is the vfat "EFI System". I presume this is the ESP?


I still have no practical understanding of how EFI is supposed to function. Documentation indicates kernels should be located in /boot/EFI/Gentoo.

I found the theory different from practice and wasn't able to understand the results I observed. I simply put kernels in /boot. The only thing I touch under /boot/EFI is /boot/EFI/BOOT/refind.conf, which may or may not matter. rEFInd seems to find kernels that exist and lists them separately from what's in the "menu" (which I presume to be the entries in refind.conf) -- behavior I find extremely annoying. The entire things seems like an accident that happens to work rather than the result of intentional engineering.

Is the following viable?

/ESP/<whatever the correct path is>/bootx64.efi
(current location: /boot/EFI/BOOT/bootx64.efi)
Where /ESP is a type of FAT32 partition.

/boot/vmlinuz...
Where /boot is an ext4 (or other file system supported by rEFInd -- good thing I noticed that... I've been contemplating ZFS).

bootx64.efi is only 226K, so maybe that's what the 2M partition was for.

[GDH-gentoo]

I presume /bootgrub/ is meant to be /boot/grub/ (slash between boot and grub)?

Yes.

I have my first partition as a 2M "BIOS boot". I don't remember what it was supposed to do.

If the disk has a GPT, you are using GRUB, and the machine does BIOS boot instead of UEFI boot, it contains a part of GRUB (placed there by grub-install). Otherwise, it is useless, but does no harm.

My second partition is the vfat "EFI System". I presume this is the ESP?

It is.

Documentation indicates kernels should be located in /boot/EFI/Gentoo.

The section title clearly says "(Optional)", and personally, if I used rEFInd, I wouldn't do that. The only special thing about that location is that rEFInd can deduce from the directory's name that it should display the Gentoo icon in the menu instead of the generic Tux icon, and there are other ways of doing that, as it says in the note.

The only thing I touch under /boot/EFI is /boot/EFI/BOOT/refind.conf, [...]

You are not supposed to do that for booting a Linux kernel, you are supposed to let rEFInd autodetect the kernels, and use /boot/refind_linux.conf to specify the kernel command line.

Is the following viable?

/ESP/<whatever the correct path is>/bootx64.efi
(current location: /boot/EFI/BOOT/bootx64.efi)
Where /ESP is a type of FAT32 partition.

It is viable, just not customary. Change "/ESP" to "/efi", though, and it becomes the pathname specified by the UAPI Group's Discoverable Partitions Specification, mentioned in the OP. For the bootx64.efi file, <whatever the correct path is> = EFI/BOOT.

However, if you are booting a Linux kernel with rEFInd, unless there is a removable medium involved, or the UEFI firmware is of poor quality, you shouldn't be installing files with the name bootx64.efi, you should be telling the UEFI firmware to run rEFInd's PE32+ executable, refind_x64.efi (e. g. with efibootmgr), which would have pathname /ESP/EFI/someting/refind_x64.efi, following your convention, or /efi/EFI/someting/refind_x64.efi, following The Discoverable Partitions Specification.

/boot/vmlinuz...
Where /boot is an ext4 (or other file system supported by rEFInd -- good thing I noticed that... I've been contemplating ZFS).

It is viable. And yes, rEFInd needs to have a driver for the filesystem that contains your kernels.

[Anon-E-moose]

I have a simple uefi setup.

/boot is my efi partition

Code: Select all

/dev/nvme0n1p1    2048   4196351   4194304     2G EFI System

/dev/nvme0n1p1		/boot		vfat		noauto,noatime,user		0 0

$ ls /boot
5.17.8  Boot  EFI  System Volume Information  admin  current  last  livecd  loader  misc

 $ ls /boot/*
/boot/livecd

/boot/5.17.8:
System.map  old  vmlinuz

/boot/Boot:
BOOTX64.EFI

/boot/EFI:
gummiboot

/boot/System Volume Information:

/boot/admin:
System-gentoo.map  gentoo  gentoo-config  gentoo.igz  image.squashfs

/boot/current:
System.map  vmlinuz

/boot/last:
System.map  vmlinuz

/boot/loader:
entries  loader.conf

/boot/misc:

The reason for 2 gig size is to allow for as many kernels as I want, as well, as dumping something like the squash filesystems from admin/rescue images.
I use the original gummiboot (that later became systemd boot), and though it's a non-gui program, it's simple and works well.

[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?

[sMueggli]

Is the following viable?

/ESP/<whatever the correct path is>/bootx64.efi
(current location: /boot/EFI/BOOT/bootx64.efi)
Where /ESP is a type of FAT32 partition.

It depends on "<whatever the correct path is>".

The EFI System Partition (ESP) contains always a directory called EFI. And in the UEFI specification the file \EFI\BOOT\BOOTx64.EFI (in case of amd64 architecture) is used as a default file path especially for removable media (see UEFI spec 2.9, chapter 3.5.1.1). In practice the file is also used as a fallback. So if a EFI binary is installed it will be usually installed inside \EFI\$distribution\$name.efi and often also under \EFI/BOOT\BOOTx64.EFI to provide a fallback.

My recommendation:
Do not put your main EFI binary to \EFI\BOOT\BOOTx64.efi on your ESP as this might be overwritten by another bootloader/operating system. For the ESP mountpoint, choose one of: /boot, /boot/efi or /efi (or /esp if you are otherwise confused).

If you are using Grub, I recommend /boot/efi as mountpoint for the ESP, because this is the Grub default for the ESP location (otherwise you need to specify the option "--efi-directory" for grub-install). Then you will install the Grub EFI binary under /boot/efi/EFI/gentoo/grubx64.efi, which is on the ESP under \EFI\gentoo\grubx64.efi.

[sMueggli]

I don't get what all this means.
Do I have to freeze grub at a certain version so things don't break?

No, if you have a working system, you do not need to do anything.

If you are freshly installing, you can think about where to mount the ESP and also whether you want to use the ESP also as /boot or just as the place for the bootloader.

When you mounted the ESP to /boot, you probably have a good reason to do so (or you followed a wiki without having a good reason). If however you mounted the ESP to /boot/efi you might consider another mountpoint. This is especially the case, when /boot, / and /boot/efi are on three different partitions and you are therefore having a nested layout, where you first need to mount /, then /boot and /boot/efi only after mounting /boot.

To avoid any problems with automounting (ALERT! ALERT: systemd as an example) and nested partitions, the proposal is to mount the ESP to /efi.

[pjp]

Thank you.

If the disk has a GPT, you are using GRUB, and the machine does BIOS boot instead of UEFI boot, it contains a part of GRUB (placed there by grub-install). Otherwise, it is useless, but does no harm.

I wondered if it might have been GRUB related. I'm guessing I either chose to have GRUB as a fallback option in case I didn't like any of the EFI methods, or I originally did intend to use GRUB. It was several years ago, so I don't recall.

The section title clearly says "(Optional)", and personally, if I used rEFInd, I wouldn't do that. The only special thing about that location is that rEFInd can deduce from the directory's name that it should display the Gentoo icon in the menu instead of the generic Tux icon, and there are other ways of doing that, as it says in the note.

When I was first reading through this thread, I didn't remember that I was using rEFInd. Then I realized that was why there were some differences between what had been written and what I had on my system. I was attempting to reconstruct my initial experience when first set up rEFInd.

You are not supposed to do that for booting a Linux kernel, you are supposed to let rEFInd autodetect the kernels, and use /boot/refind_linux.conf to specify the kernel command line.

I either never read that or it was part of my confusion with how it's "autmagic" worked. Maybe I was trying to force an ordered list how I wanted it. I'm not sure. This may be why I thought to do it:

Code: Select all

# Below are several sample boot stanzas. All are disabled by default.
# Find one similar to what you need, copy it, remove the "disabled" line,
# and adjust the entries to suit your needs.

# A sample entry for a Linux 3.13 kernel with EFI boot stub support
# on a partition with a GUID of 904404F8-B481-440C-A1E3-11A5A954E601.
# This entry includes Linux-specific boot options and specification
# of an initial RAM disk. Note uses of Linux-style forward slashes.
# Also note that a leading slash is optional in file specifications.
menuentry Linux {
    icon EFI/refind/icons/os_linux.png
    volume 904404F8-B481-440C-A1E3-11A5A954E601
    loader bzImage-3.3.0-rc7
    initrd initrd-3.3.0.img
    options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
    disabled
}

I'll have to go through the documentation.

It is viable, just not customary. Change "/ESP" to "/efi", though, and it becomes the pathname specified by the UAPI Group's Discoverable Partitions Specification, mentioned in the OP. For the bootx64.efi file, <whatever the correct path is> = EFI/BOOT.

Customary is probably better. /efi/efi though... :)

However, if you are booting a Linux kernel with rEFInd, unless there is a removable medium involved, or the UEFI firmware is of poor quality, you shouldn't be installing files with the name bootx64.efi, you should be telling the UEFI firmware to run rEFInd's PE32+ executable, refind_x64.efi (e. g. with efibootmgr), which would have pathname /ESP/EFI/someting/refind_x64.efi, following your convention, or /efi/EFI/someting/refind_x64.efi, following The Discoverable Partitions Specification.

I'll have to read documentation. I don't remember specifying the filename, and it is the only one:

Code: Select all

$ find /boot/EFI/ -iname "*.efi"
/boot/EFI/BOOT/bootx64.efi

I don't know what documentation I read, or what it contained, but the current Handbook indicates efibootmgr isn't required. If that was mentioned when I first set it up, I must have defaulted to rEFInd alone. I recall dismissing something like the stub method as it was apparently more difficult to troubleshoot.


Thanks again for the comments!

[pietinger]

[...] I recall dismissing something like the stub method as it was apparently more difficult to troubleshoot.

With efibootmgr from sys-boot/efibootmgr you can ADD, DELETE and CHANGE your UEFI-boot-entries ... AND you can LOOK which entries you have (therefore I recommend to install it always). An example from my system:

Code: Select all

# efibootmgr 
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Secure        HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\secure\bzImage.efi)
Boot0001* gentoo        HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\EFI\gentoo\grubx64.efi)
Boot0002* Unlocked      HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\unlocked\bzImage.efi)

As you can see I have/use two STUB-Kernels and one bootmanager (grub).

If a new kernel would not boot, I can set in my BIOS to boot the other stub-kernel (first backup).

grub is able to load a stub-kernel as a normal kernel ... so, it is my second backup.

(P.S: Dont worry about different /efi and /EFI ... the install routine of grub makes this entry ... and because the ESP has a FAT filesystem it doesnt matter if uppercase or not)

[pjp]

It depends on "<whatever the correct path is>".

I presume that is handled by installation. I didn't want to reference something incorrectly and have that be a distraction. In retrospect, it would have been better phrased as "Do I understand correctly that /ESP can be used instead of /EFI?" From other comments, it appears that either /esp or /efi would also work, so that's nice too. "/EFI/efi" along with the use of FAT reinforces the "NIC card" aspects of the design. Not being reminded of it whenever I encountered "/EFI/efi" is a small life improvement. /boot/EFI hides it too.

The EFI System Partition (ESP) contains always a directory called EFI. And in the UEFI specification the file \EFI\BOOT\BOOTx64.EFI (in case of amd64 architecture) is used as a default file path especially for removable media (see UEFI spec 2.9, chapter 3.5.1.1). In practice the file is also used as a fallback. So if a EFI binary is installed it will be usually installed inside \EFI\$distribution\$name.efi and often also under \EFI/BOOT\BOOTx64.EFI to provide a fallback.

Hmm. So as long as BOOTx64.EFI is "correct" in its contents, it doesn't matter which program provided it? With removable media, is the the concern that the file exist in that path and by that name? Is there an intentional benefit to having the same .efi file (with a different name) existing in $distriution\$name.efi and BOOT\BOOTx64.efi?

My recommendation:
Do not put your main EFI binary to \EFI\BOOT\BOOTx64.efi on your ESP as this might be overwritten by another bootloader/operating system. For the ESP mountpoint, choose one of: /boot, /boot/efi or /efi (or /esp if you are otherwise confused).

That's more confusing. However the file got to /boot/EFI/BOOT/bootx64.efi, it wasn't with intention beyond running a command that did it on its own. If a location must be specified, I would guess I followed documentation.

If you are using Grub, I recommend /boot/efi as mountpoint for the ESP, because this is the Grub default for the ESP location (otherwise you need to specify the option "--efi-directory" for grub-install). Then you will install the Grub EFI binary under /boot/efi/EFI/gentoo/grubx64.efi, which is on the ESP under \EFI\gentoo\grubx64.efi.

I'm not currently using it for my only EFI system, but with the information in this thread, I don't know what I'll choose for my next system. I like the idea of syslinux, other than having to use dd to install the boot sector on disks with data. Being able to restore form backup is nice, but not having to is better.

[pjp]

With efibootmgr from sys-boot/efibootmgr you can ADD, DELETE and CHANGE your UEFI-boot-entries ... AND you can LOOK which entries you have (therefore I recommend to install it always).

I have it installed, but I don't think I ever used it. Using a tool to do something I can do with a text file seems unnecessary. But as per one of the above comments, I apparently not supposed to edit refind.conf (even though that file indicates otherwise). What I'd really like is to stop the "automagic" and manage the configuration myself. This is the main complaint I have with rEFInd, but I admit to not understanding how it works. Depending on my other options, I would want to choose rEFInd again. On my non-EFI system with GRUB, I don't use the GRUB 2 "improvements." I manage the configuration myself. What GRUB 2 added to make its use easier, I find significantly more complicated.

Code: Select all

# efibootmgr 
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Secure        HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\secure\bzImage.efi)
Boot0001* gentoo        HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\EFI\gentoo\grubx64.efi)
Boot0002* Unlocked      HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\unlocked\bzImage.efi)

As you can see I have/use two STUB-Kernels and one bootmanager (grub).

I'll take your word for it :). If it meant not being stuck with EFI, I consider buying used Apple M1 (or newer) hardware.

If a new kernel would not boot, I can set in my BIOS to boot the other stub-kernel (first backup).

My system is at least 10 years old. I don't recall the BIOS having that ability, but maybe I'm not aware of it.

grub is able to load a stub-kernel as a normal kernel ... so, it is my second backup.

It seems to add complexity to the kernel and boot process that I'd rather not bother with, at least not for now. Maybe as I gain a better understanding I'll thin differently.

(P.S: Dont worry about different /efi and /EFI ... the install routine of grub makes this entry ... and because the ESP has a FAT filesystem it doesnt matter if uppercase or not)

I originally chose rEFInd partly because it wasn't Grub.

I have some spare hardware for testing. I think it is new enough that it uses UEFI.

[szatox]

Using a tool to do something I can do with a text file seems unnecessary. But as per one of the above comments, I apparently not supposed to edit refind.conf (even though that file indicates otherwise). What I'd really like is to stop the "automagic" and manage the configuration myself. This is the main complaint I have with rEFInd, but I admit to not understanding how it works

Wait, what? Why?
Efibootmgr talks to your mobo, not to refind.
The alternative to efibootmgr is reboot into bios* and enter or select the default boot option there.

Refind config file allows you to provide a list of kernel command line arguments which will be passed on to the newest (by modification date) kernel detected at boot time
OR ALTERNATIVELY (I think, didn't use this one)
define full boot entries, including the kernel and arguments, which should result in a cleaner menu for running multiple OS on a single machine. In this case you'll probably have to update your boot list after kernel update, unless you do some magic with pattern matching. Which I don't know whether or not is supported, but would not surprise me if it was.

I don't think there is any tool for creating refind configs outside of all the text editors out there.
Refind effectively replaces mobo's builtin efi. Well, I think it's technically chainloaded, but it's not really much of a difference.


* I don't care how it's called now, I mean the mobo's builtin configuration utility you can branch to by interrupting boot sequence before loading your bootloader of choice, everyone here knows what I'm talking about. Efi or no efi, every single board has an eeprom with that thing.

[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]

With efibootmgr from sys-boot/efibootmgr you can ADD, DELETE and CHANGE your UEFI-boot-entries ... AND you can LOOK which entries you have (therefore I recommend to install it always).

I have it installed, but I don't think I ever used it.

If at some point you used GRUB on a UEFI machine, grub-install calls it automatically (unless you tell it not to with an option), so that might be why you don't recall using it. However, you should have used it for setting up rEFInd, you don't remember that?

What I'd really like is to stop the "automagic" and manage the configuration myself. This is the main complaint I have with rEFInd, [...]

Um, that automagic (discovering "boot loaders", including EFI stub kernels, and presenting them in the boot menu without explicit configuration) is one of rEFInd's selling points...

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

[pietinger]

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. [...]

pingtoo,

thank you very much for your detailled (and of course correct) informations. Please let my explain WHY I made this thread. As you know - and surely many others - we had a recommendation in our AMD64 handbook for installing an UEFI compatible Linux system (wtih grub as default boot manager).

I first saw this change in our Wiki:

https://wiki.gentoo.org/index.php?title ... id=1258723

After this change from our developer @sam I saw the first changes in our AMD64 handbook made by our Wiki editor @maffblaster; e.g.:

https://wiki.gentoo.org/wiki/Handbook:A ... T_for_UEFI

A problem could be that not all pages in our Wiki are changed at the moment; here is still the old mountpoint for an ESP:

https://wiki.gentoo.org/wiki/EFI_System ... ount_point

So, I wrote this forums post as a fast reaction ... until everything was/will be changed over.

Please note that neither I nor Gentoo developers try to establish a convention. IT WAS MADE BY UAPI and Gentoo developers ONLY follow it.

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.

Please allow me to say: Me too !

[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]

[...] It would be much better to help some one understand the intrigue detail of why than to said just do it this way.

Yes ... I am with you ... but we should not forget the problem of all beginners: It will be too much information at once. Look at our AMD64 handbook ... all the 10 main pages ... If you explain every detail there it would be ... the same size as all pages we have in our wiki. Do you think someone will read all this ... before ... installing Gentoo ?

Have you seen the installation guide for ARCH ? It is ONE page => https://wiki.archlinux.org/title/installation_guide

Do you think all is explained there ?

[pingtoo]

[...] It would be much better to help some one understand the intrigue detail of why than to said just do it this way.

Yes ... I am with you ... but we should not forget the problem of all beginners: It will be too much information at once. Look at our AMD64 handbook ... all the 10 main pages ... If you explain every detail there it would be ... the same size as all pages we have in our wiki. Do you think someone will read all this ... before ... installing Gentoo ?

Have you seen the installation guide for ARCH ? It is ONE page => https://wiki.archlinux.org/title/installation_guide

Do you think all is explained there ?

But I think may be you but for sure Neddy always advise when install Gentoo failed, Do NOT erase and start from fresh. Always try to go back and find where is problem and understand it, learn from it.

I think if Gentoo's goal is have more people use it. than A one page of installation guild is actually a good thing. Think of Mac(OSX) it is design that you don't necessary need to understand computer in order to use it.

Just for sake of argument, I would said if one is not willing to spent time to understand Gentoo than Gentoo is not the right thing for this someone.

[pietinger]

But I think may be you but for sure Neddy always advise when install Gentoo failed, Do NOT erase and start from fresh. Always try to go back and find where is problem and understand it, learn from it.

Yes, I also learned this from Neddy. But I do not understand the connection now.

[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 ?