UEFI: Difference between revisions

From Alpine Linux
(moved Tip from introduction section)
 
(35 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{TOC right}}
{{TOC right}}
[https://en.wikipedia.org/wiki/UEFI Unified Extensible Firmware Interface(UEFI)] is a specification for the firmware architecture of a computing platform. This page documents how Alpine Linux works with devices using UEFI firmware.


= UEFI and BIOS definitions and introduction =
== EFI system partition ==  


In the old days, BIOS (for '''B'''asic '''I'''nput '''O'''utput '''S'''ystem) was how computers booted from the 1980s onwards. But now in newer hardware for devices, servers, laptops and desktops computers the UEFI (for '''U'''nified '''E'''xtensible '''F'''irmware '''I'''nterface) defines a software interface between an operating system and platform firmware into the vendor hardware.
UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS [[Bootloaders|bootloader]] apps get installed to. This is also commonly known as ESP partition.


UEFI replaces the BIOS firmware interface originally present in all IBM PC-compatible personal computers, early modern computer's UEFI firmware implementations provide legacy support for BIOS services.
The UEFI specification defines a standard boot path for systems without NVRAM entries as follows:
  <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI


== The history so far ==
Most of the programs that are expected to run in the UEFI environment are bootloaders, but other utilities might exist too. There are also programs to deal with firmware updates from motherboard manufacturers which can run before operating system startup like <Code>fwupdate/fwupd</Code>.


Due newer incoming 64-bit incoming processors the older computers boot process are not more possible. It started life on Itanium (Intel's first 64-bit processor) systems. Itanium had no support for 32-bit, and certainly no embedded 80286, so they had to come up with a different system.
=== EFI bootloaders ===


All this was driven by a problem in the most extensive and used architecture: x86 32-bit, inclusivelly a new 2019's Skylake i7-6700k still has an 80286 embedded in it because all x86 BIOS strictly only supports 16-bit 8088-derivative processors.
When installing Alpine linux in [[System Disk Mode]], the [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/db542902/setup-disk.in#L319-L334 setup-disk script] creates both a named bootloader (in \EFI\alpine\) and a copy at the
standard boot path (in \EFI\boot\) for all architectures as shown in the below table. The installation script does not create NVRAM boot entries.


Intel developed the original Extensible Firmware Interface (EFI) specification. Some of the EFI's practices and data formats mirror those from M$ Redmon's OS. In 2005, UEFI deprecated EFI 1.10 (the final release of EFI). The Unified EFI Forum is the industry body that (seems) "manages" the UEFI specification.  
{| class="wikitable"
! Architecture
! Named Bootloader
! Fallback Bootloader
|-
| x86_64
| {{Path|\EFI\alpine\grubx64.efi}}
| {{Path|\EFI\boot\bootx64.efi}}
|-
| x86 (32-bit)
| {{Path|\EFI\alpine\grubia32.efi}}
| {{Path|\EFI\boot\bootia32.efi}}
|-
| arm*
| {{Path|\EFI\alpine\grubarm.efi}}
| {{Path|\EFI\boot\bootarm.efi}}
|-
| aarch64 (ARM64)
| {{Path|\EFI\alpine\grubaa64.efi}}
| {{Path|\EFI\boot\bootaa64.efi}}
|-
| riscv64
| {{Path|\EFI\alpine\grubriscv64.efi}}
| {{Path|\EFI\boot\bootriscv64.efi}}
|-
| loongarch64
| {{Path|\EFI\alpine\grubloongarch64.efi}}
| {{Path|\EFI\boot\bootloongarch64.efi}}
|}
 
== UEFI boot process ==
 
UEFI has list of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them.  UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.  


= Alpine UEFI support =
These boot entries in NVRAM can be viewed and edited with [[Bootloaders#efibootmgr|efibootmgr]] utility.


Currently are only in basic form, not all the architectures are complete supported.
== BIOS boot process ==


The '''support for
BIOS mainly supports two methods of booting - loading approximately 448 bytes of 8088 machine code from the start of a floppy disk, or the same from the start of a fixed disk. BIOS can only assume one boot loader occupying the start of hard drive. So each OS overwrites it with its own boot loader.  
[https://en.wikipedia.org/wiki/EFI_system_partition EFI System Partition] was started in the [https://alpinelinux.org/posts/Alpine-3.7.0-released.html Alpine 3.7.0 new mayor release]''', preliminary support in that version does not create the  
[https://en.wikipedia.org/wiki/EFI_system_partition EFI Partition], only has support for existing ones or manually created.


Started '''in the [https://alpinelinux.org/posts/Alpine-3.8.0-released.html Alpine 3.8.0 new mayor release] support in the installer for the GRUB boot loader was added''' so now Linux experimental users can play with combinations of solutions and proper
MBR cannot handle disks larger than 2 TiB (2<sup>32</sup> × 512 bytes). Therefore, it is impossible to use any drive space beyond 2 TiB using MBR layout.  
[https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface UEFI] complete installations. Please refer to [[Alpine_and_UEFI#UEFI_and_BIOS_definitions_and_introduction|UEFI_and_BIOS section of this page]] first.


'''[https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#EFI_system_partition EFI System Partition] are not the complete overall of the [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface UEFI], it's just the need minimal infrastructure to property boot by and [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Implementation_and_adoption UEFI modern machine]. See the [[Alpine_and_UEFI#UEFI_mandatory_partition_mechanics|Alpine UEFI partition mechanics notes]] section in this page for details.'''
BIOS is '''deprecated''' since approximately 2011 onwards and modern motherboards are using UEFI.


Please read carefully the [[Alpine_and_UEFI#UEFI_and_BIOS_definitions_and_introduction|UEFI_and_BIOS section of this page]].
== Secure boot process ==
{{Main|UEFI Secure Boot}}


== Minimum Alpine partition sheme ==
When the device is powered ON, secure boot checks the digital signatures of the bootloader and operating system. If the signatures are valid and match the trusted keys stored in the system, the boot process continues. If not, secure boot halts the process to protect against tampering.


Alpine Linux only requires a root partition for system and a swap partition, but, UEFI systems require an EFI system partition. Needs a bootloader program in \EFI\$bootloader.efi on a EFI System Partition, a specially tagged partition. The current status of that mechanics to boot '''in Alpine Linux are still in development and only basic support to existing mades are provided'''. See [[Alpine_and_UEFI#UEFI_mandatory_partition_mechanics|UEFI_mandatory_partition_mechanics]] for details.
Almost all X86 based motherboard has a small list of pre-trusted certificates which includes Microsoft's certificates, which they currently let anyone use for a small fee as a Certification Authority (CA).  


== Notes about the boot flags and boot partition ==
Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have.


UEFI booting does not involve any "boot" flag, that's it's a need only for BIOS booting. The UEFI booting relies solely on the boot entries in NVRAM. Parted and its front-ends use a "boot" flag on GPT to indicate that a partition is an EFI system partition.
{{Tip| To install Alpine Linux ''' Disable''' Secure boot in the UEFI firmware. It can be enabled after Alpine Linux is installed.}}


A BIOS boot partition is only required when using GRUB for BIOS booting from a GPT disk. The partition has nothing to do and it must not be formatted with a file system or mounted.
[[UEFI Secure Boot]] page explains how to generate your own UEFI keys and enrolling those UEFI keys to be used with a Unified Kernel Image.


== Alpine disk layout for UEFI ==
== Disk layout and UEFI ==


You will need a disk layout that your system firmware is capable of booting, you '''will need a boot partition and a root partition'''. Other architectures may have different requirements and not all are supported, please read [[Alpine_and_UEFI#UEFI_mandatory_partition_mechanics|UEFI_mandatory_partition_mechanics]] for details.
[[#UEFI-GPT layout|UEFI-GPT layout]] is the recommended layout for UEFI. UEFI relies on the boot entries in NVRAM and looks for OS bootloaders and runs it.


If you don't already know what filesystem format you want your boot partition, choose '''ext2'''. The '''root partition, and any additional partitions or LVM volume groups, may be in any format that the kernel is capable of reading'''.
=== UEFI-GPT layout ===


==== UEFI/GPT minimal layout ====
Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting.  On GPT disks, the EFI System Partition is identified by its partition type GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B).
 
On UEFI systems, Alpine Linux requires an EFI System Partition(ESP) in addition to the (/) root partition. A minimal UEFI-GPT layout is given below:


{| class="wikitable"
{| class="wikitable"
Line 54: Line 89:
! Recommended minimum size
! Recommended minimum size
|-
|-
| /boot or /efi
| /efi or /boot/efi or /boot
| /dev/sda1
| /dev/sda1
| Boot system partition for EFI
| EFI system partition
| 260 MiB
| 260 MiB
|-
|-
Line 63: Line 98:
| Alpine Linux root system OS
| Alpine Linux root system OS
| 1–32 GiB
| 1–32 GiB
|-
| none
| /dev/sda3
| Linux swap memory
| 1-2Gb
|}
|}


==== BIOS/MBR minimal layout ====
=== BIOS-MBR layout ===
 
BIOS-style booting from MBR-partitioned disks is called BIOS-MBR, regardless of it being performed on UEFI or legacy BIOS-based systems. Such a boot scheme is commonly called UEFI-MBR. 
 
Despite the fact that the UEFI specification requires MBR partition tables to be fully supported, some UEFI firmware implementations may immediately switch to BIOS-based Compatibility Support Module (CSM) booting depending on the type of boot disk's partition table, effectively preventing UEFI booting to be performed from EFI System Partition on MBR-partitioned disks.  CSM is a deprecated feature as of late 2020's.
 
'''Use this only on legacy motherboards using [[#BIOS boot process|BIOS boot process ]]'''. A BIOS boot partition with "boot" flag is required when using this layout.


{| class="wikitable"
{| class="wikitable"
Line 87: Line 123:
| Alpine Linux root system OS
| Alpine Linux root system OS
| 1–32 GiB
| 1–32 GiB
|-
| none
| /dev/sda3
| Linux swap memory
| 1-2Gb
|}
|}


==== BIOS/GPT minimal layout ====
=== BIOS-GPT layout ===
 
Booting legacy BIOS-based systems from GPT disks is also possible, and such a boot scheme is commonly called BIOS-GPT. A BIOS boot partition with "boot" flag is required when using this layout. This partition must '''not''' be formatted with a file system or mounted.


{| class="wikitable"
{| class="wikitable"
Line 111: Line 144:
| Alpine Linux root system OS
| Alpine Linux root system OS
| 1–32 GiB
| 1–32 GiB
|-
 
| none
| /dev/sda3
| Linux swap memory
| 1-2Gb
|}
|}


= BIOS boot process for newbies =
== See also ==
 
BIOS mainly supports two methods of booting - loading approximately 448 bytes of 8088 machine code from the start of a floppy disk, or the same from the start of a fixed IDE disk.
 
BIOS can only assume one boot loader occupying the start of hard drive. So each OS overwrites it with its own boot loader. This is very messy. There's also the 2 TiB issue with MBR.
 
In order to make your drive more useful, it's split up into partitions - chunks of disk space which can be treated as independent drives from inside your OS. Windows (following on from MS-DOS) only supports one method for partitioning its boot drive on BIOS systems, which is MBR.


MBR cannot handle disks larger than 2 TiB (2<sup>32</sup> × 512 bytes). Therefore, it is impossible to use any drive space beyond 2 TiB using MBR layout. So if you're booting from it and use BIOS, you MUST use MBR - and you simply can't use any space beyond that if your boot drive is 2TB or bigger.
* [[UEFI_Secure_Boot|How to enable secure boot]]
 
* [[Bootloaders]]
Modern motherboards (since approximately 2011 onwards) are using UEFI natively, but most can emulate BIOS through the CSM (Compatibility Support Module) to maintain support for BIOS-style booting.
 
= UEFI boot process explained =
 
Well, let's start with installers. It'll read a UDF or FAT32-formatted USB drive or DVD, and look for the file /efi/boot/bootx64.efi and run it. An app, written in the UEFI "OS". It can be anything! Here's classic text adventure Zork, as a UEFI app.
 
It's possible to make boot media which is valid for both UEFI and BIOS. Unfortunately, in a slightly user-unfriendly twist, you (the user) need to pick the right boot entry. For example, on the wife's PC, a USB stick gets listed as both "UEFI: Sandisk Cruzer Edge" and "USB: Sandisk Cruzer Edge". Just... make sure you pick the right entry. It's impossible to change mode after this point.
 
It uses a different partitioning system called GPT instead of MBR, and secondly it creates an extra ~100 meg partition called the "EFI System Partition" - a FAT32 partition where the boot loader apps get installed to (no more boot sectors).
 
Each OS will stick its boot loader somewhere in the ESP, then send a signal to the firmware to write this new loader's location into the CMOS. Each entry installed in this manner will get its own listing in your "boot devices" list on the firmware - so if you installed MACOSX, you'll have "MACOSX Boot Manager" as an entry next to your DVD drive and hard drive after you reboot. This is why you don't do the old "unplug drive A when installing a different OS to drive B" thing, or swap cables, or anything like that. You should only have one ESP, the one on drive A.
 
== UEFI mandatory partition mechanics ==
 
Regular UEFI boot has several lists of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. Unfortunately, a lot of PC UEFI implementations have got this wrong and so don't work properly.
 
The correct way for this to work when booting off local disk is for a boot variable to point to a vendor-specific bootloader program in <code>\EFI\$bootloader.efi</code> on the EFI System Partition (ESP), a specially tagged partition (Some OS's formatted as Fat32.. that's are unnecessary due it's just to able to poor OS's to boot like M$ Redmond OS's). The current status of that mechanics to boot in Alpine Linux are still in development and only basic support to existing made are provided.
 
== What's this infamous "Secure Boot"? ==
 
It's a way for your motherboard to prevent tampering of your OS (e.g. boot-sector viruses, or backdoors installed without your knowledge). You can provide a list of certificates you trust, then the firmware enforces that everything involved with the boot process (not just the boot loader, but the OS kernel itself, and all your device firmware like your GPU BIOS) are signed with a trusted key.
 
It works using cryptographic checksums and signatures. It '''stops your system from booting unsigned code'''. You can sign your own, and trust the certificate you used to do that signing. Or you can get the boot code signed by Microsoft - every motherboard has a small list of pre-trusted certificates which almost (always) includes Microsoft's certificates, which they currently let anyone use for a small fee.
 
Most of the programs that are expected to run in the UEFI environment are boot loaders, but others exist too. There are also programs to deal with firmware updates before operating system startup (like fwupdate and fwupd), and other utilities may live here too.
 
Due the "Unsigned code curse", Alpine linux [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#EFI_system_partition EFI System Partition] '''are not the complete overall of the [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface UEFI], it's just the need minimal infrastructure to property boot''' it!
 
== How to boot unsigned code? ==
 
'''You must disable Secure Boot. Alpine has no support for Secure Boot as it does not have a certificate''' which some other Linux distributions (mostly enterprise-related) have. This means that on many new computer systems, users have to first disable Secure Boot to be able to install Alpine Linux and the methods for doing this vary massively from one system to another, making this potentially quite difficult for users.
 
This is due to Microsoft's actions as a Certification Authority (CA) for Secure Boot. They sign programs/bootloaders on behalf of other trusted organizations so that their programs will run, but at great cost.. and there's nothing related to free software but affects to.. There's no Alpine Linux Certification like are with other enterprise related Linux.
 
Take in consideration that for Alpine linux [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#EFI_system_partition EFI System Partition] are not the complete overall of the [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface UEFI], it's '''just the need minimal infrastructure to property boot''' by an [https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Implementation_and_adoption UEFI modern machine]. See the [[Alpine_and_UEFI#UEFI_mandatory_partition_mechanics|Alpine UEFI partition mechanics notes]] section in this page for details.
 
= Overall notes and conclusions =
 
Currently Alpine UEFI and Secure Boot are very early stage.. Initial support was added and enabled for UEFI, but Secure Boot must be disabled.
 
BIOS computers (or UEFI computers with Compatibility Support Module) are the easiest and most reliable way to install Linux distributions in general. They do not need the new EFI partition to boot nor new special files.
 
UEFI-only computers are very common nowadays and are more challenging machines in which to install Alpine linux. They will need the the new EFI partition to boot containing special files.
 
= See Also =
 
* [[Newbie_Alpine_Ecosystem]]
* [[Alpine_newbie_install_manual|Alpine Installation]]
* [[Create a Bootable Compact Flash]]
* [[Create a Bootable USB]]
* [[Create UEFI boot USB]]
* [[Create UEFI secureboot USB]]
* [[Create UEFI secureboot USB]]
 
* [[Setting_up_disks_manually#Manual_partitioning | Manual partitioning]]
[[Category:Newbie]]
* [https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface UEFI - Archwiki]
[[Category:Installation]]
* [https://en.wikipedia.org/wiki/EFI_system_partition EFI System Partition - Wikipedia]
[[Category:Installation]][[Category:UEFI]]

Latest revision as of 16:58, 1 November 2025

Unified Extensible Firmware Interface(UEFI) is a specification for the firmware architecture of a computing platform. This page documents how Alpine Linux works with devices using UEFI firmware.

EFI system partition

UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS bootloader apps get installed to. This is also commonly known as ESP partition.

The UEFI specification defines a standard boot path for systems without NVRAM entries as follows: 

 <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI

Most of the programs that are expected to run in the UEFI environment are bootloaders, but other utilities might exist too. There are also programs to deal with firmware updates from motherboard manufacturers which can run before operating system startup like fwupdate/fwupd.

EFI bootloaders

When installing Alpine linux in System Disk Mode, the setup-disk script creates both a named bootloader (in \EFI\alpine\) and a copy at the standard boot path (in \EFI\boot\) for all architectures as shown in the below table. The installation script does not create NVRAM boot entries.

Architecture Named Bootloader Fallback Bootloader
x86_64 \EFI\alpine\grubx64.efi \EFI\boot\bootx64.efi
x86 (32-bit) \EFI\alpine\grubia32.efi \EFI\boot\bootia32.efi
arm* \EFI\alpine\grubarm.efi \EFI\boot\bootarm.efi
aarch64 (ARM64) \EFI\alpine\grubaa64.efi \EFI\boot\bootaa64.efi
riscv64 \EFI\alpine\grubriscv64.efi \EFI\boot\bootriscv64.efi
loongarch64 \EFI\alpine\grubloongarch64.efi \EFI\boot\bootloongarch64.efi

UEFI boot process

UEFI has list of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.

These boot entries in NVRAM can be viewed and edited with efibootmgr utility.

BIOS boot process

BIOS mainly supports two methods of booting - loading approximately 448 bytes of 8088 machine code from the start of a floppy disk, or the same from the start of a fixed disk. BIOS can only assume one boot loader occupying the start of hard drive. So each OS overwrites it with its own boot loader.

MBR cannot handle disks larger than 2 TiB (232 × 512 bytes). Therefore, it is impossible to use any drive space beyond 2 TiB using MBR layout.

BIOS is deprecated since approximately 2011 onwards and modern motherboards are using UEFI.

Secure boot process

Main article: UEFI Secure Boot

When the device is powered ON, secure boot checks the digital signatures of the bootloader and operating system. If the signatures are valid and match the trusted keys stored in the system, the boot process continues. If not, secure boot halts the process to protect against tampering.

Almost all X86 based motherboard has a small list of pre-trusted certificates which includes Microsoft's certificates, which they currently let anyone use for a small fee as a Certification Authority (CA).

Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have.

Tip: To install Alpine Linux Disable Secure boot in the UEFI firmware. It can be enabled after Alpine Linux is installed.

UEFI Secure Boot page explains how to generate your own UEFI keys and enrolling those UEFI keys to be used with a Unified Kernel Image.

Disk layout and UEFI

UEFI-GPT layout is the recommended layout for UEFI. UEFI relies on the boot entries in NVRAM and looks for OS bootloaders and runs it.

UEFI-GPT layout

Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. On GPT disks, the EFI System Partition is identified by its partition type GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B).

On UEFI systems, Alpine Linux requires an EFI System Partition(ESP) in addition to the (/) root partition. A minimal UEFI-GPT layout is given below:

Mount point Partition Partition type Purpose Recommended minimum size
/efi or /boot/efi or /boot /dev/sda1 EFI system partition 260 MiB
/ /dev/sda2 Alpine Linux root system OS 1–32 GiB

BIOS-MBR layout

BIOS-style booting from MBR-partitioned disks is called BIOS-MBR, regardless of it being performed on UEFI or legacy BIOS-based systems. Such a boot scheme is commonly called UEFI-MBR.

Despite the fact that the UEFI specification requires MBR partition tables to be fully supported, some UEFI firmware implementations may immediately switch to BIOS-based Compatibility Support Module (CSM) booting depending on the type of boot disk's partition table, effectively preventing UEFI booting to be performed from EFI System Partition on MBR-partitioned disks. CSM is a deprecated feature as of late 2020's.

Use this only on legacy motherboards using BIOS boot process . A BIOS boot partition with "boot" flag is required when using this layout.

Mount point Partition Partition type Purpose Recommended minimum size
/boot /dev/sda1 Boot grub partition (optional) 100 MiB
/ /dev/sda2 Alpine Linux root system OS 1–32 GiB

BIOS-GPT layout

Booting legacy BIOS-based systems from GPT disks is also possible, and such a boot scheme is commonly called BIOS-GPT. A BIOS boot partition with "boot" flag is required when using this layout. This partition must not be formatted with a file system or mounted.

Mount point Partition Partition type Purpose Recommended minimum size
None /dev/sda1 BIOS boot partition 8 MiB
/ /dev/sda2 Alpine Linux root system OS 1–32 GiB

See also

Retrieved from "https://wiki.alpinelinux.org/w/index.php?title=UEFI&oldid=31347"