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] fmask=0177,dmask=0077[3] (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 -o fmask=0177,dmask=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)

I added the mount options to the fstab article. For Installation guide#Mount the file systems (and similar), I'm thinking of using this:

# mount --mkdir -o fmask=0177,dmask=0077,noexec,nosuid,nodev /dev/efi_system_partition /mnt/boot

It's not the prettiest command, but there's nothing better.

-- nl6720 (talk) 11:21, 6 January 2025 (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)

It serves the purpose to additionaly inform users and various software/OSes as well about the partition purpose. While it's mostly a cosmetic aid for users, some sofware functionality depending on this additional bit of information could be limited without (think recovery tools, multiboot tools, and similar). It also prevents quick ESP format/removal from Windows in dual-boot scenarios. This should also answer @Andreymal while I agree the bit is not strictly necessary. But also not completely redundant. Drws (talk) 19:47, 27 August 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)

ESP as /efi

I'm trying to follow this setup because it's recommended for UKI and encryption https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points:~:text=by%20the%20firmware.-,mount%20the%20ESP%20to,of%20accessing%20the%20kernel(s)%20and%20files%20that%20are%20stored%20elsewhere.,-mount%20the%20ESP

But not sure what the correct scheme should be? Should it be /boot as separate partition and /efi will be encrypted and housing only UKI image? --Webcapcha (talk) 19:45, 28 October 2024 (UTC)

The ESP cannot be encrypted. When using UKIs, the ESP can be mounted to /efi while /boot would remain a simple directory (not a separate partition) on the root volume. -- nl6720 (talk) 09:41, 6 January 2025 (UTC)

Moving "Hibernation and dual boot systems" section

In regards to this change: I disagree. That's neither a Windows-specific issue (as noted in the section), nor even an issue specific to Microsoft filesystems, but for any filesystem (including ext4, btrfs, ZFS, …). Hibernating one system (e.g. the main Arch Linux) without unmounting its filesystems and later mounting the same filesystem with another system (e.g. Windows, but also Ubuntu, Fedora, or even another Arch Linux, or some USB live system) will cause problems when resuming the first system. There are two reason why I chose to add this section here:

1. Prevalence. UEFI is the default nowadays and next to all multi boot systems suffer from this issue, because the ESP is expected to be mounted in all systems. Sharing other filesystems between systems is a conscious decision of the user otherwise and thus way less common. NTFS on Linux is AFAIK the only filesystem driver that prevents one from mounting a dirty filesystem (even though it seems like the reason for that is that it simply wasn't implemented).
2. Visibility. This needs to be at some place where users can actually find it. Dual boot with Windows is the wrong place no matter what, simply because it's no Windows-speicific issue. Another place could be Power management/Suspend and hibernate, however, it doesn't really belong there either, because one can cause the same issues with virtual machines as well. Maybe File systems… However, since it's a short section anyway, there isn't much of a benefit, because moving it (i.e. without retaining some notice here) doesn't properly address that the ESP is the only partition for which this issue is expected and not caused by some special user setup.

--PhrozenByte (talk) 14:45, 18 May 2025 (UTC)

I concur. In fact, any attempt to reboot into another system after the running one hibernates ought to be considered adventurous to say the least. This definitely deserves a generic warning.

-- YHNdnzj (talk) 19:03, 18 May 2025 (UTC)

Wherever the section is moved to, it can still be linked from other articles (for visibility). Even if we keep it here, a link to it in Dual boot with Windows and Power management/Suspend and hibernate#Troubleshooting would still be useful.

The current solution is ESP-specific, but if it were to be made more generic, then moving the section to File systems would be possible.

-- nl6720 (talk) 10:58, 19 May 2025 (UTC)

I'm not against generalising this section, even though I believe the benefits are limited, I'm more having issues with moving it. This section is intentionally just talking about the ESP and explains a possible solution to this - without a doubt - general issue. However, this solution is no general solution, but one specific to the ESP. The ESP really has a special role here. First, because the ESP is expected to be mounted in all systems and this issue arising isn't the result of some adventurous setup (I like that 😄). Second, because the solution presented here only works reliably under very specific circumstances, which only happen to be true for the ESP. The reason is that one often can't unmount random partitions when hibernating the system, because they are still in use. The ESP is rarely in use, that's why one can usually unmount it safely.

So, we need to differentiate things here. On one hand we have a general issue that always arises when another system mounts a still active (local) filesystem and one proceeds in using that filesystem later - let it be due to hibernating, or when using virtual machines, or things I can't think of right now. I agree that we could explain this issue somewhere else too, but rather additionally than exclusively. Saying, I'm totally fine with adding notices to other articles as well, even though these notices probably just consist of a single sentence like "You can't mount local filesystems in multiple active systems at the same time, and hibernating a system still makes it count as 'active'.". Any suggestions? On the other hand we have a solution that works for the ESP reliable, but probably not for many other. I'm not aware of a general solution to this issue (maybe with autofs / Systemd automount because it maybe has some kind of caching? No idea though, never used that stuff). There might be one, I just don't know it. Any ideas? --PhrozenByte (talk) 11:20, 19 May 2025 (UTC)

Except that this solution for ESP is also totally broken/unsupported (with my systemd developer hat on). Stopping efi.mount or anything required by local-fs.target results in the latter being brought down, which might manifest as ordering problems during shutdown. automount does allow you to circumvent all that and is OK-ish - that said, such practice remains to be highly error-prone and should be strongly discouraged.

-- YHNdnzj (talk) 16:08, 19 May 2025 (UTC)

Why does stopping efi.mount bring down local-fs.target? That IMO doesn't make much sense to begin with… /efi isn't a required mount like e.g. /. Besides, this is totally unexpected to me (and I just checked, it's true). I'm well aware that Systemd adds both implicit and default dependencies to mount units, but this rather sounds like a ConsistsOf or BoundBy instead of WantedBy? I just checked the manpage and couldn't find anything about that. What do I miss?

Anway, how do we tell Systemd to not do things like that? Unless automount somehow allows for cached unmounting I don't see how it's relevant here - it won't solve the issue, unless a timeout is configured and this timeout just happens to have elapsed when hibernating the system. Maybe something like mounting with noauto and adding the necessary x-systemd.wanted-by, x-systemd.before, and x-systemd.after ourselves? Or would Systemd still treat this differently from any other WantedBy dependency? --PhrozenByte (talk) 16:57, 19 May 2025 (UTC)

Because mounts listed in fstab are required by local-fs.target by default, unless you specify nofail on it which downgrades the dep to the weaker Wants=, but I doubt that's what most people want.

-- YHNdnzj (talk) 17:04, 19 May 2025 (UTC)

This very much feels like that one rightfully decided that a boot shouldn't succeed when fstab mounts fail and thus chose Requires, but didn't take the side-effects into account. I can't think of a single use case in which it would make sense from an user's perspective that stopping a mount unit also stops local-fs.target, possibly causing other problems… This feels like a bug (and I don't mean "Requires behaves wrong" by that, but just in the context of mount units). I guess you should discuss this with your fellow Systemd devs?

Anyway, that's off topic, let's get back to topic. So, how do we solve this issue? We still want efi.mount to be required at boot, but don't want local-fs.target to stop, because that simply makes no sense. nofail would make the mount optional, something we definitely don't want. What about the options list I suggested earlier? Would that do the job? --PhrozenByte (talk) 17:47, 19 May 2025 (UTC)

After more than one month of testing I can conclude that stopping efi.mount and consequently also bringing local-fs.target down indeed causes issues. For example, Systemd began auto-masking multiple mount units - including but not limited to efi.mount - as defective, which effectively also prevented remounting efi.mount.

Frankly speaking, the latter makes this whole issue just stupid. Systemd on the one hand considers all mounts in /etc/fstab so crucial that manually unmounting any of them brings down local-fs.target, but on the other hand Systemd happily and silently auto-masks any mount in /etc/fstab if it considers it defective. This behaviour is contradictory and IMO makes zero sense.

Anyway, the solution I suggested earlier indeed works: One must tell Systemd not to imply RequiredBy=local-fs.target, but use WantedBy=local-fs.target instead. Since this also removes the implied ordering depedencies, one must add them manually as well. This seems to work as expected.

I've updated the section accordingly, and have also added notes referencing this section to Dual boot with Windows, and Power management/Suspend and hibernate. --PhrozenByte (talk) 15:38, 22 June 2025 (UTC)