From Mageia wiki
Jump to: navigation, search
EFI BASICS, This page aims to de-mystify EFI (or UEFI) about which there has been an unreasonable amount of fear & suspicion in the Linux world, partly due to its association with GPT and Secure Boot. The page is written off the top of my head according to my own experience, which was early in the day of EFI. Any additions, clarifications or corrections are welcome.


EFI = Extensible Firmware Interface
UEFI = Unified Extensible Firmware Interface
Effectively the same things.

EFI is primarily about booting. It is aimed at replacing the historic system of booting PCs via boot sectors, notably the Master Boot Record (MBR) supplemented by Primary, Secondary and Logical partition boot sectors. In a multi-boot system, this requires that one party takes the initial control and by various means hands it over to other systems. EFI aims at better separating the boot processes, putting them into the realm of the EFI Firmware. It has been documented for a very long time, but only implemented in earnest on PCs since about 2012, roughly coincident with Win8. Implicitly it is x64.

EFI is often associated with GPT and Secure Boot (both outlined below).

  • GPT is independent of EFI. Some EFI systems require GPT (or they'll automatically switch to CSM mode). Other EFI systems are ok with MBR partition tables.
  • EFI does not require Secure Boot, but Secure boot requires EFI.

To alter an EFI system, you must know how to (what key to press on power-up):

  • Get into the Firmware Setup.
  • Raise the EFI boot menu (F12 in my case).

GPT (GUID Partition Table)

Simply, all partitions are equal - with duplication of the partition table. Partitions are numbered 1-n as they are created; if you delete and re-create partitions, partition numbers may not reflect their physical order on the disk. You can forget the hodge-podge of Primary, Secondary, and Logical partitions, all their boot sectors, the MBR. GPT has been around for years, is standard on Macs, and possible on some pre-EFI PCs.
Until recently, you needed to use gdisk instead of fdisk, but the fdisk man page now says "It understands GPT, MBR, Sun, SGI and BSD partition tables." Use gdisk anyway! Better still, GParted handles GPT discs.

  • gdisk example:
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5EC9A9ED-B16C-48B2-9DFA-D856B13BCC5D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 333614445 sectors (159.1 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
  1            2048          821247   400.0 MiB   2700  Basic data partition
  2          821248         1435647   300.0 MiB   EF00  EFI system partition
  3         1435648         1697791   128.0 MiB   0C01  Microsoft reserved part
  4         1697792       104310783   48.9 GiB    0700  Basic data partition
  5       104310784       105232383   450.0 MiB   2700  [Extra Win8.1 thingy]
  6       105234432      1153810431   500.0 GiB   0700  [Data]
  7      1153812480      1166387199   6.0 GiB     8200  [Swap]
  8      1166389248      1249886207   39.8 GiB    0700  Manjaro
  9      1249888256      1333387263   39.8 GiB    0700  Suse
 10      1333389312      1416886271   39.8 GiB    0700  Korora
 11      1416888320      1458636799   19.9 GiB    8300  Mageia
 12      1458636800      1500387327   19.9 GiB    8300  Linux filesystem
 13      1500389376      1542332415   20.0 GiB    0700  [MGALive]
 14      1542334464      1584277503   20.0 GiB    0700  [MintDebian]
 15      1917872128      1953523711   17.0 GiB    2700  Basic data partition
  • fdisk example
# fdisk -l /dev/sda

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5EC9A9ED-B16C-48B2-9DFA-D856B13BCC5D

Device            Start          End   Size Type
/dev/sda1          2048       821247   400M Windows recovery environment
/dev/sda2        821248      1435647   300M EFI System
/dev/sda3       1435648      1697791   128M Microsoft reserved
/dev/sda4       1697792    104310783    49G Microsoft basic data
/dev/sda5     104310784    105232383   450M Windows recovery environment
/dev/sda6     105234432   1153810431   500G Microsoft basic data
/dev/sda7    1153812480   1166387199     6G Linux swap
/dev/sda8    1166389248   1249886207  39.8G Microsoft basic data
/dev/sda9    1249888256   1333387263  39.8G Microsoft basic data
/dev/sda10   1333389312   1416886271  39.8G Microsoft basic data
/dev/sda11   1416888320   1458636799  19.9G Linux filesystem
/dev/sda12   1458636800   1500387327  19.9G Linux filesystem
/dev/sda13   1500389376   1542332415    20G Microsoft basic data
/dev/sda14   1542334464   1584277503    20G Microsoft basic data
/dev/sda15   1917872128   1953523711    17G Windows recovery environment

GPT makes provision for pretending to be an old MBR system, called Compatibility Mode, which is implemented in the Firmware setup. You must use one or the other, they cannot be mixed. Many people used this frigs to install Linux on EFI hardware. On any native EFI/GPT system, use of Compatibility Mode just complicates life.

Secure Boot

This add-on to EFI is a thinly disguised marketing ruse by Microsoft (hand-in-glove with the hardware manufacturers) to stop other systems being installed on a Windows box. It is a complicated system of signed start-up elements which in itself has intense security merit - recognized by the Linux community - but is effectively closed shop, Microsoft being the sole signing authority.
The obvious escape is to disable Secure Boot in the Firmware Setup, so do that immediately. However, this option may disappear one day - it is already impossible on ARM boxes - and Linux will *have* to cope with it.
Linux is, very slowly, taking on board Secure Boot, if at the expense of licking the boots [sic] of Microsoft. It will win in the end. There is even documentation about how to make yourself the real Secure Boot owner of your box and sign your own thingies (CentOS ? Arch Wiki), but it is fantastically complicated.

EFI at last


EFI booting is defined by an NVRAM array of installed (& declared) systems, which point to the equivalent bootloaders in a dedicated disc partition called the EFI System Partition (ESP). So having said that with GPT all partitions are equal, for EFI that is not the case: to work, it requires an ESP. Broadly:-

NVRAM Boot0000 -> its bootloader in the ESP
NVRAM Boot0001 -> its bootloader in the ESP
NVRAM Boot0002 -> its bootloader in the ESP
NVRAM Boot0003 -> its bootloader in the ESP

So EFI booting hangs on which NVRAM array entry gets picked. More on this later, as well as the array itself and the ESP. If you have a simple setup with just one copy of Mageia, you should not need to bother with the details.

The main Linux tools for handling EFI booting are:

  • grub2-efi for establishing the bootloader.
  • efibootmgr for manipulating the NVRAM array.
  • rEFInd, a third-party bootloader.

The NVRAM array

The easiest way to understand this is, in summary:-

# efibootmgr
BootCurrent: 0002
Timeout: 5 seconds
BootOrder: 0002,0003,0001,0008,0005,0009,0004,0000
Boot0000  opensuse
Boot0001  manjaro_grub
Boot0002* UEFI: ST1000DM003-9YN162
Boot0003* Windows Boot Manager
Boot0004  mageia
Boot0005  Fedora
Boot0006* rEFInd
Boot0008  Korora
Boot0009  rEFInd

which shows all the declared installed systems. Plus here one for the disc itself. If bootable media is present on startup, that gets temporarily included too. If you raise the EFI boot menu at power-on, it will probably list the array as shown plus any bootable media present.

The extra items are:-

  • BootCurrent is the entry which was used this time.
  • BootNext (if defined) is the entry that will be chosen next time once only. In theory.
  • BootOrder is of fundamental importance, because in theory it defines the boot pecking order: array entries should be tried in the defined order, the first one to fly (which would normally be the first) wins. You can omit entries from BootOrder (but see Active below), and include the same entry more than once. The worst problems arise from BootOrder being adjusted by the firmware, or not being respected.
  • The '*' means 'Active'. In theory, only Active entries are tried.

To see the full picture, showing the device & path to the equivalent bootloaders:-

# efibootmgr -v
BootCurrent: 0002
Timeout: 5 seconds
BootOrder: 0002,0003,0001,0008,0005,0009,0004,0000
Boot0000  opensuse	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\opensuse\grubx64.efi)
Boot0001  manjaro_grub	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\manjaro_grub\grubx64.efi)
Boot0002* UEFI: ST1000DM003-9YN162	ACPI(a0341d0,0)PCI(11,0)03120a000000ffff0000HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)AMBO
Boot0003* Windows Boot Manager	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...o.............?...
Boot0004  mageia	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\mageia\grubx64.efi)
Boot0005  Fedora	ACPI(a0341d0,0)PCI(11,0)03120a000000ffff0000HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\FEDORA\shim.efi)..
Boot0006* rEFInd	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\refind\refindx64.efi)
Boot0008  Korora	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\fedora\shim.efi)
Boot0009  rEFInd	HD(2,c8800,96000,cabda21a-3435-4869-93bd-9f550b7ea29a)File(\EFI\refind\refindx64.efi)

[Please can someone explain the ACPI entries?]

You can with efibootmgr freely create, delete, [de]activate these Bootxxxx entries - but not, here, the special hard disc entry; (nor the Win8 one apart from deleting it and re-instating it simply as per the others. Perhaps its difference is down to Secure Boot). You can also define BootNext and BootOrder; but they may not be honoured.

Note that you can have multiple NVRAM entries for the same installed system.
Note also that you can install a system without creating an NVRAM entry for it, and still get it booted via a third party bootloader like rEFInd.
Conversely, if you create an NVRAM entry with no equivalent bootloader, it will simply fail.

What gets booted

Accepting that any boot which works does not return, any which fail return:-

if BootNext is defined (&, in theory, Active)
then boot that entry             [and unset BootNext]

for each entry in BootOrder
  if it is (in theory) Active
  then boot the entry

boot the default bootloader	[See the next section]


The ESP is a shared boot partition in which each installed system has its own space and bootloader. It is formatted as a variant of FAT (which is all the Firmware understands) with the partition type EF and GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B. It is normally the first or second partition, and typically around 300Mb. There is conventionally a top-level directory \EFI\ under which systems put their stuff in discrete sub-directories for tidiness. You can (as root) access and manipulate the ESP just like normal filestore; it is commonly /boot/efi/ with \EFI\ as its top directory. Think of it exactly like the old independent and shared /boot partition when Linux had to be booted from below a certain cylinder number. The following listing illustrates it:-

# tree /boot/efi/EFI
├── Boot
│   ├── bootx64.efi		[The default bootloader]
│   ├── bootx64.OEM		[Backup of same as delivered]
├── fedora			[Plus other things at the root /boot/efi/ level]
│   ├── BOOT.CSV
│   ├── fonts
│   │   └── unicode.pf2
│   ├── gcdx64.efi
│   ├── grub.cfg
│   ├── grubx64.efi
│   ├── MokManager.efi
│   ├── shim.efi
│   └── shim-fedora.efi
├── mageia			[Standard latest Mageia bootloader]
│   └── grubx64.efi
├── mageia4			[Separated out by me]
│   └── grubx64.efi
├── mageia5			[Separated out by me]
│   └── grubx64.efi
├── manjaro_grub
│   ├── grubx64.efi
├── Microsoft
│   └── Boot
│       ├── bootmgfw.efi	[The standard Win8 bootloader]
│       ├── bootmgr.efi
├── opensuse
│   └── grubx64.efi
├── refind			[added EFI boot manager]
│   ├── icons
│   │   ├── arrow_left.icns
│   │   └── vol_optical.icns
│   ├── refind.conf
│   └── refind_x64.efi
└── tools
    └── drivers_x64
        ├── ext2_x64.efi
        ├── hfs_x64.efi
        ├── iso9660_x64.efi
        └── reiserfs_x64.efi

So you see the simple and neat picture:-


which for Linux is normally grubx64.efi . Some explanations are warranted, however.

  • \EFI\Boot\bootx64.efi is the default bootloader when nothing else works (BootNext, BootOrder). In theory it should never be used... On a box delivered with Windows, it will invoke \EFI\Microsoft\Boot\bootmgfw.efi . You can put here whatever you like if you need to - but keep a copy of the original. I have rEFInd here (as well as its correct place \EFI\refind\refindx64.efi).

I suspect that this is the bootloader used for the NVRAM "UEFI" disc entry.

  • Most of the Fedora stuff (for Korora) is related to Secure Boot. Not shown are several additional items at the \ level; it really is intrusive.
  • All the 'refind' and 'tools' stuff is about rEFInd, an EFI boot manager, more of which later. Normally only refindx64.efi is absolutely essential.
  • The most truculent boxes may load directly \EFI\Microsoft\Boot\bootmgfw.efi , so to get it to do anything else you have to replace that; again, backup the original.
  • Apparently OpenDesktop recommends throwing everything into the ESP - kernels and initrds. This seems to contradict the separatist spirit of EFI; a bad idea.
  • You can install an OS bootloader into the ESP without creating an NVRAM entry for it; this is an oversight (or laziness)... But a boot manager like rEFInd will still find it. I have not bothered [yet] to add my mageia4/5 specials to NVRAM for this very reason: compare the NVRAM and ESP mageia entries.

Putting the two together

The installer merely needs to create its own sub-directory in \EFI\ (conventionally mounted on /boot/efi), put into it the generated grub2-efi bootloader grubx64.efi, and create the necessary NVRAM entry. grub2-install alone does all this on an EFI box, e.g.

# grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=<OSname>

[I suspect that <OSname> is the sub-directory name]

efibootmgr is available to manage NVRAM independently e.g.

# efibootmgr -c -d /dev/sda -p 1 -L mageia -l \\EFI\\mageia\\grubx64.efi

-c = create
-d = bootloader device
-p = & partition, the ESP
-L = distribution name for the EFI boot menu
-l = loader path [use \\ for one \].
Both commands supposedly put the new entry first in BootOrder, meaning it should get booted next time...

Multi-booting & EFI Boot Managers

This section covers multiple operating systems, Windows included. It does not apply if your box is devoted to just one installation, which should get booted because there is no alternative.

- If a system is declared in NVRAM (pointing to a valid bootloader in the ESP), it will show up on the EFI boot menu and any boot manager. This is the normal situation.
- If a system bootloader is installed in the ESP without an equivalent NVRAM entry, it will not be visible in the EFI boot menu, but will be to a boot manager.
- Any installed system lacking its own individual ESP entry (e.g. due to multiple installations of the same Linux) will not show up either in the EFI boot menu, nor a boot manager which only checks the ESP.
However, it does normally show up in more recent Grub2 menus, thanks to OSprober; and recent rEFInd.

  • At power-up, pressing the appropriate key will display the EFI boot menu, from which you can select any entry. This menu will show the NVRAM entries, plus bootable media like DVD or USB, and possibly an entry for the hard disc [which I think goes to the default boot loader \EFI\Boot\bootx64.efi].
  • If your box is well behaved (i.e. it does not mess up BootOrder) and really boots hands-off, consistently, the most recently installed Linux, the Grub2 menu of that should show and enable booting of all other installed systems, including other instances of the same distribution.
  • Install an independent boot manager and make sure by fair means or foul that it always gets booted. There are various ruses to try:

- If your box honours BootOrder, using efibootmgr ensure the boot manager is first in the BootOrder list - and stays there.
- Put the boot manager's bootloader as \EFI\Boot\bootx64.efi [copy the original file first].
- See below more for Windows.

There are two boot manager candidates, both of which offer installation & configuration advice:
This, like Grub, is driven by a config file which you must define & maintain.

- rEFInd

A product of EFI guru Rod Smith - who also wrote gdisk. It really is magic: it finds automatically everything in the ESP - even those with no NVRAM entry - and all recent linux's (i.e. with a boot stub) installed on the disc, regardless of whether they have an ESP bootloader or not.
It offers a menu (iconised if possible, otherwise text) to select from. It even works without its config file and icons, just bare refind_x64.efi - copied if needs be to the default bootloader \EFI\Boot\bootx64.efi , or that of Windows \EFI\Microsoft\Boot\bootmgfw.efi .

Windows is [still] booted

- Put the boot manager's bootloader as \EFI\Microsoft\Boot\bootmgfw.efi [copy the original file first].
- Make Windows boot the boot manager as follows:
Depending on which version of Windows you use, the Command Prompt may or may not appear in a menu somewhere, but the executable program is always \Windows\System32\cmd.exe. Either way, right-click on the menu entry or the file, and a pop-up menu will give you the option of "Run as administrator".
Assuming e.g. rEFInd has been installed in /boot/EFI/EFI/refind, the command to type is:

  bcdedit /set {bootmgr} path \EFI\refind\refind_x64.efi

Other points

  • EFI shell

There exists an EFI shell for interacting directly with the firmware. Some boxes come with it; otherwise it can be downloaded and installed; in the hope that it will show in a boot menu (EFI or boot manager). An advanced topic not covered here [yet].

  • Bootable media

EFI will recognize a valid ISO DVD or USB stick to boot from. In both cases, it is probably easier to select the device from the EFI boot menu (if it is shown there) rather than fiddle with the firmware setup boot order.

  • Multiple instances of a distribution

If you have a recent rEFInd, you need do nothing because it finds & shows all systems installed on the disc regardless of their NVRAM or even ESP presence. To avoid confusion between different instances, it is strongly recommended to uniquely label their *filesystems* since rEFInd shows this label if present.
Otherwise, any distribution installed to boot via Grub2 creates a uniquely named sub-directory in \EFI\ for its grubx64.efi bootloader; and a uniquely named entry in NVRAM referencing that. You can cheerfully install into different partitions several instances of the same distribution, but each one overwrites its predecessor's EFI boot information, and only the latest one gets booted.
You get away with it because the most recent Grub2 menu of an installed distribution has entries for all other OS's, including other instances of itself.
To create distinctly named & directly bootable entries for multiple instances, do the following - remembering that the last installed will carry the plain 'distro' name:

  1. Copy the 'distro' subdirectory to another with a different name, e.g. \EFI\mageia\ to \EFI\mageia4\ .
  2. For most convenience, add with efibootmgr a new NVRAM entry for the new name. It will now be visible and bootable as that from the EFI boot menu. (You can skip this if you use a boot manager, which will find the distinct ESP boot entry).
  3. Install the new instance. It will take over the plain 'mageia' sub-directory & NVRAM label, and be bootable as such. If you want to preserve its individuality, repeat steps 1-2.
  4. Repeat for any further instances as you install them.
  • Linux Stubs

These are a method for directly loading specially compiled Linux kernels, without needing Grub2. rEFInd can find, list and directly load such systems with stubs.

  • Some references