Talk:EFI system partition

From ArchWiki
Revision as of 11:41, 3 August 2018 by Nl6720 (talk | contribs) (/boot/efi -> /efi: re, close)
Jump to navigation Jump to search

ESP mount point /boot <-> /boot/efi

I think we should decide on a standard here. This article (and others) always use /boot/efi/, but:

  • the gummiboot setup tool expects it to be mounted to /boot by default (this is only available in the [testing] package atm). Considering that the setup tool is called in post_install/post_upgrade, this will simply not work for people using /boot/efi.
  • the next systemd version has a nice feature, as it will automatically create an automount unit to mount the ESP partition to /boot (it knows the ESP from the bootloader, see http://freedesktop.org/wiki/Software/systemd/BootLoaderInterface )
  • Does using /boot/efi actually provide any kind of benefit? The boot partition has always been mounted to /boot and I don't see any reason to change that.

Other opinions? If there are no objections, I would change the paths to /boot in the corresponding articles. 65kid (talk) 15:41, 2 March 2013 (UTC)

This sounds like a sensible approach. Would it be worth adding a section on migrating; just to ease the pain?
Jasonwryan (talk) 19:58, 5 March 2013 (UTC)
For reference, there is still a long discussion about this here: https://bbs.archlinux.org/viewtopic.php?pid=1241590
65kid (talk) 19:02, 8 March 2013 (UTC)
Just mentioning that this topic has been touched also in Talk:GRUB#EFI. -- Lahwaacz (talk) 12:19, 16 November 2013 (UTC)
I myself think ESP mount to /boot is better, but anyone know why /boot/efi is chosen in the first place?
ESP itself deserve a seperate page, and some EFISTUB section is actually belong to ESP too. --Fengchao (talk) 01:38, 25 February 2016 (UTC)
If no objective, I will create ESP page soon. --Fengchao (talk) 07:28, 31 March 2016 (UTC)
Just to answer the /boot/efi question above, that path is required for example in Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB). — Kynikos (talk) 08:19, 1 April 2016 (UTC)
This discussion has a lot of overlap with Talk:EFISTUB#ESP mount points. The current suggestion there is to go with /boot or /boot/efi (if your bootloader can read other file systems) and to have alternative options discussed separately. Also the sections should be merged. Silverhammermba (talk) 16:13, 10 January 2017 (UTC)
This discussion has been twice superseded by other discussions. Closing. -- nl6720 (talk) 07:12, 24 July 2018 (UTC)

/boot/efi -> /efi

I plan to change the mountpoint in EFI system partition#Mount the partition from /boot/efi to /efi next month (2018-08).

The rationale is:

Previously the only thing preventing /efi usage was rEFInd. Before version 0.11.3 refind-install didn't support /efi, now it does. Since refind-efi is included in the "Arch Linux Live/Rescue CD" it's better to wait until the next iso is released.

Other pages that will need updating:

-- nl6720 (talk) 07:09, 24 July 2018 (UTC)

Mountpoint updated. If anyone finds any more references to /boot/efi, please change them to /efi -- nl6720 (talk) 11:41, 3 August 2018 (UTC)

FAT12 support, accuracy

I'm curious what is seen as inaccurate here? My initial reading of this when adding the section in the first place, was due to that exact paragraph. The UEFI spec is as usual pretty badly worded by incompetent standards bodies (cf. using any version of FAT in the first place rather than something decent and free like ext), but they pretty unambiguously declare that the UEFI must have filesystem driver support.

Given filesystem driver support, I literally don't comprehend their disclaimer that FAT12 FAT16 are "encompassed" for removable media. It's a filesystem driver. How do you write a filesystem driver so that it doesn't work for the first filesystem you mount but only works for the second and later filesystems you mount?

Moreover, I could read their wording as saying that FAT32 is not supported for removable media, and only FAT12/FAT16 are, but I doubt people will seriously take that as gospel... -- Eschwartz (talk) 03:32, 29 July 2018 (UTC)

Using Template:Accuracy probably wasn't correct, I changed it to Template:Expansion.
The UEFI spec has annoying inconsistencies regarding ESP, FAT and media types. There are multiple UEFI implementations that don't like anything other than FAT32 for the ESP on HDD, so my intention was to not give false hope about it supporting FAT12 and FAT16. And IIRC Macs don't use HFS+ for ESP anymore, they uses one of the FAT filesystems now.
-- nl6720 (talk) 07:00, 29 July 2018 (UTC)
Have Macs really changed? Interesting, my google-fu does not turn this up. Anyway... the UEFI spec has many annoying consistencies, but this was why I chose to basically just ignore that and go with what common sense says will be the result of their mandating some form of FAT12 driver support. Since I'm not terribly knowledgeable about UEFI implementations besides "what works on my laptop" and "what the spec says should work", could you refer me to these troublesome UEFI implementations? And, in which situations would they accept FAT12 then? -- Eschwartz (talk) 07:16, 29 July 2018 (UTC)
I forgot where I read it, but IIRC it changed since Apple started using APFS.
I'm too lazy to lookup crappy UEFI examples, but I'll link to you the best example I remember: http://www.rodsbooks.com/gb-hybrid-efi/ (I actually have access to one motherboard with that firmware). I won't find anything regarding FAT12, since I don't think anyone besides you is using FAT12 on ESP :)
-- nl6720 (talk) 07:35, 29 July 2018 (UTC)
"Using FAT12/FAT16 may result in pathologically buggy UEFI firmware from a given vendor to flake out with even more alarming regularity than using FAT32", very interesting. :) On the other hand, I wonder if that unfortunate thing is noncompliant w.r.t. supporting these as removable media either.
I'm decidedly unsure what the best thing to do here is, except suggest people shell out lots of money and buy all new hardware because maaaaaan that hardware seems like a bad thing to have to deal with either way. Still interested to hear if there's firmware that basically correctly implements UEFI but does so in a way which is incompatible with FAT12 on the ESP. Keep in mind that we already do suggest later on to use FAT32 "To avoid potential problems with some UEFI implementations", so we're probably covered there -- I guess it would still be a matter of technical correctness to continue to specify that, per the spec, FAT12 should work.
Also, you're wrong, I know at least one other person who uses it, so there's definitely a minimum of two people in the world! Earnest uses it too... I got the idea from him. -- Eschwartz (talk) 09:10, 29 July 2018 (UTC)
I can't remember, but I think the only removable media that thing supports booting in UEFI mode is an optical disc. I'll need to check tomorrow to make sure.
You're right that there's a suggestion to use FAT32 later on in the page, I removed the template. When I'll find a reference for ESP filesystem used on Macs I'll remove the line about HFS+.
-- nl6720 (talk) 09:35, 29 July 2018 (UTC)
It can't boot in UEFI mode from USB flash drive. Also I can't find any source for my Mac ESP claims, maybe I dreamt it... Forget I said anything. -- nl6720 (talk) 10:02, 30 July 2018 (UTC)