Talk:EFI system partition

Some firmware requires esp/EFI/BOOT/BOOTX64.EFI path

Had an issue with "no bootable image found" on an HP Elitebook. It appears that someone else had a similar problem here:

https://forums.opensuse.org/showthread.php/493175-Issues-with-booting-GPT-and-UEFI/page4

The solution is to change the path from, e.g. esp/EFI/arch_grub/grubx64.efi to esp/EFI/BOOT/BOOTX64.EFI (simply by copying the efi file).

Is this worth adding to the Troubleshooting section?

—This unsigned comment is by Kolo (talk) 13:26, 1 June 2020‎. Please sign your posts with ~~~~!

The solution should already be in all boot loader pages (GRUB#Default/fallback boot path, rEFInd#Installation with refind-install script, Syslinux#Installation on UEFI, etc.).

The default/fallback boot path is also briefly mentioned in Arch boot process#Under UEFI and Unified Extensible Firmware Interface, though not in the context of this issue. Since the issue is not relevant to the EFI system partition page, it should not be added here. If you want to document it (in a boot-loader-agnostic way), feel free to do so in Unified Extensible Firmware Interface#Troubleshooting.

-- nl6720 (talk) 07:55, 2 June 2020 (UTC)

Mounting the partition is not mandatory

I run GRUB in my UEFI/GPT setup, and I don't mount the EFI partition when booting the OS. In fact, I created the /efi directory but don't use it. This should be mentioned, IMO - Megver83 (talk) 05:06, 3 August 2020 (UTC)

It could be mentioned, but It needs to be clear that it doesn't apply when mounting it to /boot. E.g., something along the lines of: "If the EFI system partition's mountpoint (or bind mount) is not /boot, it can be left unmounted during everyday system usage. For example, configure /etc/fstab to mount it on first access..." -- nl6720 (talk) 08:26, 3 August 2020 (UTC)

Add systemd automatic intel-ucode.img moving under alternate mount points

Under the systemd section of the alternate mount points part of the page, would it make sense to also add a task triggered on the changing of /boot/intel-ucode.img that copied /boot/intel-ucode.img to the esp? Dghosef (talk) 01:56, 2 December 2020 (UTC)DghosefDghosef (talk) 01:56, 2 December 2020 (UTC)

Since /boot/intel-ucode.img and /boot/amd-ucode.img are packaged, it would IMHO make more sense to copy them using a pacman hook instead of systemd path. -- nl6720 (talk) 16:37, 2 December 2020 (UTC)

Mountpoint umask

Looking at [1], bootctl will complain if the ESP mountpoint is world-readable. The automount .mount units set umask=0077[2] (and also noexec,nodev,nosuid), so I think it may be a good idea to do the same (or something similar) with all the ESP mount commands in the wiki.

The mount commands would need to be changed to include -o umask=0077,noexec,nosuid,nodev and a corresponding fstab example would need to be provided in EFI system partition#Mount the partition.

Personally, I think fmask=0177,dmask=0077 is prettier than umask=0077, but maybe it's better to follow systemd.

-- nl6720 (talk) 13:55, 15 June 2023 (UTC)

We probably also need to change Installation guide#Mount the file systems.

Hanabishi (talk) 22:29, 29 April 2024 (UTC)

Marking EFI partition as platform-required

The current instructions don't include marking EFI partition as platform-required (aka. system partition) in the GPT. While not strictly necessary, it could be at leased mentioned as a side note, or is there some background I'm missing? Drws (talk) 15:21, 17 July 2024 (UTC)

Why? What uses the platform-required bit of the partition attributes? — Lahwaacz (talk) 16:38, 17 July 2024 (UTC)

The specification says:

[...] it should be considered part of the hardware of the system. Actions such as [...] even OS install or boot could potentially stop working if this partition is removed. [...] it should never be removed or modified as the UEFI firmware or platform hardware may become non-functional.

None of these apply here (e.g. you can always boot from LiveUSB and restore ESP), so I think "platform-required" is unnecessary.

— andreymal (talk) 16:48, 17 July 2024 (UTC)