[Solved] New /efi mount point

[ololoshwin]

I've found /efi mount point generated by systemd-gpt-auto-generator

I do not understand why my ESP partition is mounted to /efi.
How to revert it to /boot?

I've removed /boot line from /etc/fstab and i have not "Extended Boot Loader Partition (XBOOTLDR partition)" but ESP is still mounted to /efi.

ESP should be mounted to /boot according to https://uapi-group.org/specifications/s ... ification/

sys-apps/systemd-255.3-r1

[sMueggli]

@ololoshwin

So far your setup is not wrong. From the linked bootloader specification:

It is recommended to mount $BOOT (either XBOOTLDR or the ESP) to /boot/. If both XBOOTLDR and the ESP are present, the ESP should be mounted to /efi/.

I am using systemd-255.3-r1 and my ESP is not automatically mounted to /efi. I am using Grub and have mounted the ESP to /boot/efi. Because my /boot is on the /-partition, I do not have a nested mount. And I do not want to abuse the ESP as /boot.

What shows

Code: Select all

lsblk -o +PARTTYPE

?

[NeddySeagoon]

There are two different related but unconnected things happening.
Keeping them related is the system admins problem.

At boot time, the UEFI firmware finds the ESP partition. It must be flagged type ESP.
It then uses the efivars to know where to find the .efi program to boot.
That is always under EFI/ in the ESP.

The fallback of EFI/Boot/bootx64.efi is hard coded in amd64 systems.
The EFI program can anything that fits into the space.

On Gentoo, an EFI compliant program is installed to EFI/GRUB/grubx64.efi and as the name suggests, its the first part of the GRUB bootloader.
The efivars are updated to point to that too.

As grubx64.efi makes its own arrangements to find grub stage2, the rest of grub can go anywhere. It need not be on the ESP.
Gentoo often uses /boot/grub.

We are still getting the boot loader loaded. The kernel and the kernel filesystem tree are still a distant dream. Hold that thought. It will be key to what comes next.
Grub stage2 displays the menu, loads the kernel and initramfs then exits by jumping to the kernel start address.

There is still no kernel filesystem tree, no I should really be using kernel filesystem tree path names above.
All that matters at this time is that the UEFI firmware can load the .efi program and the efi program can load the bootloader which in turn, loads the kernel.
The .efi program can be the kernel and initramfs ll in one piece. No boot bootloader required.

The kernel and initramfs are loaded. Together, they need to de whatever is required to execute /sbin/init in the root of the kernel filesystem tree. It turn, that brings the system up, including assembling the kernel filesystem tree.

The system is up, the kernel filesystem exists, all without the kernel being aware of the ESP, boot loader and even itself before it was loaded into RAM.

Now we come the full circle and to the point of confusion.
The kernel is used to update grub, itself, the efivars and the .efi program, so wherever they are stored needs to be mounted in the kernel filesystem tree for the update.
It does not matter where because the kernel filesystem tree is only used for updates, It does not exist at boot time ... which I said right at the start.
Its the system admins job to put updates in the right place(s) so that they will be found at boot time.

[ololoshwin]

What shows

Code: Select all

lsblk -o +PARTTYPE

?

Code: Select all

$ lsblk -o +PARTTYPE
NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS          PARTTYPE
zram0           253:0    0    14G  0 disk  [SWAP]               
zram1           253:1    0     0B  0 disk                       
nvme0n1         259:0    0 476,9G  0 disk                       
├─nvme0n1p1     259:1    0   260M  0 part                       c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─nvme0n1p2     259:2    0    16M  0 part                       e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3     259:3    0   ***G  0 part                       ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
├─nvme0n1p4     259:4    0  1000M  0 part                       de94bba4-06d1-4d40-a16a-bfd50179d6ac
├─nvme0n1p5     259:5    0    **G  0 part  /                    0fc63daf-8483-4772-8e79-3d69d8477de4
├─nvme0n1p6     259:6    0    18G  0 part  [SWAP]               0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
└─nvme0n1p7     259:7    0   ***G  0 part                       e6d6d379-f507-44c2-a23c-238f2a3df928

I've located the problem. systemd-gpt-auto-generator mounts ESP partition to /boot only if directory exists and empty.

My /boot directory in root filesystem was created long time ago and ".keep" file was inside. systemd-gpt-auto-generator prefer to create /efi directory in this case.

• If ESP partition is already mounted systemd-gpt-auto-generator do nothing with it.
• If /boot directory exists and empty and boot drive does not have "Extended Boot Loader Partition" systemd-gpt-auto-generator mounts ESP to /boot
• If /efi directory is empty or does not exist systemd-gpt-auto-generator mounts ESP to /efi