5

On old computers (using BIOS) we had to create 2 partitions, one to mount / and second for swap.
But on new systems with UEFI we need to create third partition EFI System in addition to those two partitions. What is the purpose of this partition?

Update: does this partition is shared between a Linux distribution and Windows?

Gilles 'SO- stop being evil'
  • 829,060
Alex Jones
  • 6,353

2 Answers2

11

Beside the meaning of the ESP(EFI System Partition), is really just any partition formatted with one of the UEFI spec-defined variants of FAT and given a specific GPT partition type to help the firmware find it. This way, all EFI executables will be stored at one place, and "chainload" the Operating System specific loader or other EFI executables

The steps of booting with this setup are:

  1. System on - POST(Power On Self Test)
  2. UEFI loads it's firmwares, and initializes all hardware required for booting.
  3. Firmware determine what is the partition to be read, and where the UEFI applications are stored
  4. Firmware reads Boot Manager data to decide based on a list what EFI application have the highest priority to boot. Some UEFI systems are less flexible, and expect only one UEFI application that needs to be stored at <ESP>/EFI/BOOT/BOOTX64.EFI.
  5. UEFI application is launched. It may launch/chain another UEFI application(like an UEFI shell/menu) or load the initramfs and the kernel.

Basically, it's a FAT partition where you store EFI applications. The advantage here is that you don't need a "boot sector" anymore. It is a partition where you store binaries(efi files) and do whatever you want(depends on how your motherboard implements the specification).

Update answer: This partition will be shared in a way that a Linux related EFI(Gummiboot, rEFInd or Grub) and the Windows 8 standard EFI loader (\EFI\Microsoft\Boot\bootmgfw.efi) will be stored on the same partition. Is up to you if you want to create menus directly on the EFI Firmware or using Grub to create entries to Windows and Linux. Example.

Unfortunately, Windows 7 32bit, and Windows Vista and older(no matter 32 or 64 bits) do not support EFI+GPT. You will have to use Bios + MBR solutions to dual boot.

Further Reading:

  • sir can you please explain the meaning of "chainload" in a word or two? – Alex Jones Apr 07 '15 at 14:20
  • For sure. One efi executable that executes another efi executable . Example: You have a GRUB EFI called loader.efi inside this partition, and other file called shellx64_v2.efi. Your Firmware is set to load as default loader.efi, and this guy will have on it's configuration files a menu entry called menuentry "UEFI Shell x86_64 v2" that will execute shellx64_v2.efi. It's one EFI(Grub) chainloading another EFI(the EFI Shell). EFI shell is just a "generic" program to probe EFI. –  Apr 07 '15 at 14:28
  • sir I have added an update, can you please answer that also? – Alex Jones Apr 07 '15 at 16:11
  • updated my answer Mr. Torvalds :) –  Apr 07 '15 at 17:03
  • Why "unfortunately"? Does anyone actually want to use EFI to boot when there's an option not to? – R.. GitHub STOP HELPING ICE Apr 07 '15 at 19:33
  • 1
    No. I expressed the "Unfortunately" because there is no way to stay with EFI and at the same time load those operation systems that highly depends on MBR + BIOS. Bios is pretty OLD and MBR have a lot of limitations. Its a more than 30 years old standard that needs to be put aside and the only thing that keeps us using it is an "apparent simplicity" while we have to thinker with bootloaders instead of using a Unified way to create menus and load OS's. There is of course the other side, with vendor locks, but its the same thing with a Knife: "Could be used" to slice a bread or to kill... –  Apr 07 '15 at 20:08
  • 2
    @r: sure, why not? just because you happen to have had a bad experience with (U)EFI does not mean it has no advantages for anyone else; one might as well ask why would anyone want to use non-EFI boot methods when there's an option not to? – u1686_grawity Apr 07 '15 at 20:09
  • @nwildner - what do you mean by create menus in a unified way exactly? it's my impression that the uefi spec has very little to say at all regarding the actual user interface - such as menus and similar. – mikeserv Apr 07 '15 at 22:09
  • http://www.rodsbooks.com/efi-bootloaders/installation.html#register - efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\newloader\\loadername.efi -L NewLoader for example will create a new efiloader entry inside the EFI internal boot menu with the name of "NewLoader". The command inside Windows to manipulate EFI entries is bcdedit –  Apr 07 '15 at 22:44
  • Oh - well bcdedit is about the bcd mainly - which is a hidden windows registry hive. it can be given the option to add an entry to boot manager's list. efibootmgr does the same stuff - they affect NVRAM variables. but none of that is necessarily related to a boot menu and there is no specification for a boot menu at all - the UEFI spec is intentionally quiet on the issue - all of its member organizations are of the kind that stand to profit by developing their own, competing interfaces. if an implementation provides a menu it may or may not be directly linked to the bootmgrs list. – mikeserv Apr 07 '15 at 22:54
  • Maybe "boot menu" was a simple way to explain that the NVRAM is easly writable to new loader entries, and that you have to thinker with grub2-efi to efiload other EFI binaries on specific cases. Of course that UEFI is open enough to allow hardware players to inject firmware or prevent "Other OS" from loading, the same way Broken BIOS implementations caused headaches to Linux/*BSD users. –  Apr 07 '15 at 23:31
  • You don't really have to tinker with it - and in fact, of them all, I would say grub is the worst EFI management interface altogether. I do just the ESP, a folder w/ refind in it, and I keep my linux kernel and initramfs on the ESP - but bind-mount that folder over /boot at start-up so the package manager handles system updates per usual. It's all transparent - and there's no tinkering. rEFInd is drop-dead simple and the only config needed is two lines in /etc/fstab. The linux kernel is its own bootloader. grub is dead weight. – mikeserv Apr 07 '15 at 23:51
  • Sounds great. My latest efi setup was using Arch and gummiboot. I should try to migrate to rEFInd as soon as possible since there is no dual boot or specific EFI Shell that i need as an additional entry. –  Apr 08 '15 at 00:03
  • I haven't tried it yet, but Rod's 12/2014 changelog notes that a big change is in the new (but experimental) support for network booting, with the help of iPXE. See the BUILDING.txt file in the source package for details on how to build and install the necessary file. Sounds cool to me, but I'm always worried about messing with a good thing. – mikeserv Apr 08 '15 at 00:39
3

Via Wikipedia:

ESP (EFI System Partition) contains the boot loader programs for all installed operating systems (which are contained in other partitions on the same or other storage device), device driver files for devices present in a computer that are used by the firmware at boot time, system utility programs that are intended to be run before an operating system is booted, and data files such as error logs.

Further, relating it to BIOS-mode booting:

UEFI provides backward compatibility with legacy systems by reserving the first block (sector) of the partition for compatibility code, effectively creating a legacy boot sector. On legacy BIOS-based systems, the first sector of a partition is loaded into memory and execution is transferred to this code. UEFI firmwares do not execute the code in the Master Boot Record (MBR), except when booting in legacy BIOS mode through the Compatibility Support Module (CSM).

glibdud
  • 313