 |
Andere talen English ; Nederlands ; |
| Synopsis: 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. |
Contents
Background
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 for x64 systems, but BEWARE: hybrid hardware exists where the firmware itself is 32-bit, which complicates bootable media and bootloader installation.
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 (Arch Wiki ?), but it is fantastically complicated.
EFI at last
Summary
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), more of which below. 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 etc
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.4.7.9.5.}...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
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), normally FAT32; with the partition type EF and GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B ; with a boot flag, possibly also esp. 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/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:-
\EFI\<distribution>\<bootloader>
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.
Reminders:
- 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:
- GUMMIBOOT
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.
BEWARE: it does not work for hybrid boxes with 32-bit firmware.
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
Either:
- Put the boot manager's bootloader as \EFI\Microsoft\Boot\bootmgfw.efi [copy the original file first].
Or:
- 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". Recent Windows show 'adminstrator console' in menus, or try menukey/X.
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:
- Copy the 'distro' subdirectory to another with a different name, e.g. \EFI\mageia\ to \EFI\mageia4\ .
- 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).
- 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.
- 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
- http://www.uefi.org/
- https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
- http://www.rodsbooks.com/
