UEFI - Revision history

Prabuanand: moved Tip from introduction section

2025-11-01T16:58:33Z

moved Tip from introduction section

← Older revision		Revision as of 16:58, 1 November 2025
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.		[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.

	~~{{Tip\|To [[Installation\|install]] Alpine Linux''' Disable Secure Boot''' in UEFI firmware. [[UEFI_Secure_Boot\|Secure boot]] page has instructions for enabling it after Alpine Linux is installed.}}~~

	== EFI system partition ==		== EFI system partition ==
Line 69:		Line 67:
	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).		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. ~~This means, users have to first~~ ''' ~~disable~~ Secure ~~Boot to~~ be ~~able to install~~ Alpine Linux~~'''~~.		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.		[[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.

Prabuanand: moved headings so easier to follow

2025-11-01T16:46:11Z

moved headings so easier to follow

@@ Line 54: / Line 54: @@
 These boot entries in NVRAM can be viewed and edited with [[Bootloaders#efibootmgr|efibootmgr]] utility.
-== Disk layout for UEFI ==
+== BIOS boot process ==
-[[#UEFI-GPT layout|UEFI-GPT layout]] is the recommended layout for UEFI.
+BIOS is '''deprecated''' since approximately 2011 onwards and modern motherboards are using UEFI.
-The UEFI booting relies on the boot entries in NVRAM and looks for OS boot loaders and runs it. On GPT disks, the EFI System Partition is identified by its partition type GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B).
+== Secure boot process ==
 === UEFI-GPT layout ===
-Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. 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:
+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).
 {| class="wikitable"
@@ Line 105: / Line 124: @@
 | 1–32 GiB
 |}
 === BIOS-GPT layout ===
@@ Line 135: / Line 146: @@
 |}
 == See also ==

Prabuanand: added bootloader files and location, replaced boot flag reference by GUID for gpt disks

2025-11-01T16:19:17Z

added bootloader files and location, replaced boot flag reference by GUID for gpt disks

← Older revision		Revision as of 16:19, 1 November 2025
Line 6:		Line 6:
	== EFI system partition ==		== EFI system partition ==

	UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS [[Bootloaders\|bootloader]] apps get installed to.		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.

	The ~~format of the file~~ path ~~is defined~~ as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI~~; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture.~~		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 <Code>fwupdate/fwupd</Code>.		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>.

			=== EFI bootloaders ===

			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.

			{\| 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 boot process ==
Line 16:		Line 52:
	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.		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 [[Bootloaders#efibootmgr\|efibootmgr]] utility.		These boot entries in NVRAM can be viewed and edited with [[Bootloaders#efibootmgr\|efibootmgr]] utility.

	== Disk layout for UEFI ==		== Disk layout for UEFI ==
Line 22:		Line 58:
	[[#UEFI-GPT layout\|UEFI-GPT layout]] is the recommended layout for UEFI.		[[#UEFI-GPT layout\|UEFI-GPT layout]] is the recommended layout for UEFI.

	The UEFI booting relies on the boot entries in NVRAM and looks for OS boot loaders and runs it. ~~Parted and its front-ends use a "boot" flag on~~ GPT ~~to indicate that a partition~~ is ~~an EFI system~~ partition(~~ESP~~)~~, but the "boot" flag is not used by [[#UEFI boot process\|UEFI boot process]]~~.		The UEFI booting relies on the boot entries in NVRAM and looks for OS boot loaders and runs it. On GPT disks, the EFI System Partition is identified by its partition type GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B).

	=== UEFI-GPT layout ===		=== UEFI-GPT layout ===
Line 34:		Line 70:
	! Recommended minimum size		! Recommended minimum size
	\|-		\|-
	\| /boot or /efi or /boot~~/efi~~		\| /efi or /boot/efi or /boot
	\| /dev/sda1		\| /dev/sda1
	\| EFI system partition		\| EFI system partition
Line 51:		Line 87:
	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.		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 [[#BIOS boot process\|BIOS ~~only motherboards~~]]'''. A BIOS boot partition with "boot" flag ~~may be~~ required when using this layout~~, depending on the firmware implementation~~.		'''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"

Prabuanand: added wikilink

2025-11-01T10:20:03Z

added wikilink

← Older revision		Revision as of 10:20, 1 November 2025
Line 16:		Line 16:
	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.		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 ~~<Code>~~efibootmgr~~</Code> utility available in the {{pkg~~\|efibootmgr~~}} package~~.		These boot entries in NVRAM can be viewed and edited with [[Bootloaders#efibootmgr\|efibootmgr]] utility.

	== Disk layout for UEFI ==		== Disk layout for UEFI ==

Prabuanand: minor rewording

2025-11-01T10:18:18Z

minor rewording

← Older revision		Revision as of 10:18, 1 November 2025
Line 8:		Line 8:
	UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS [[Bootloaders\|bootloader]] apps get installed to.		UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS [[Bootloaders\|bootloader]] apps get installed to.

	~~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 from motherboard manufacturers which can run before operating system startup (like <~~Code~~>~~fwupdate/fwupd~~<~~/Code~~>), and ~~other utilities may live here too~~.		The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture.

	~~The format~~ of the ~~file path is defined as~~ <~~EFI_SYSTEM_PARTITION~~>~~\EFI\BOOT\BOOT~~<~~MACHINE_TYPE_SHORT_NAME~~>~~.EFI; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture~~.		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>.

	== UEFI boot process ==		== UEFI boot process ==

Prabuanand: added more headings and moved information

2025-11-01T10:14:27Z

added more headings and moved information

← Older revision		Revision as of 10:14, 1 November 2025
Line 4:		Line 4:
	{{Tip\|To [[Installation\|install]] Alpine Linux''' Disable Secure Boot''' in UEFI firmware. [[UEFI_Secure_Boot\|Secure boot]] page has instructions for enabling it after Alpine Linux is installed.}}		{{Tip\|To [[Installation\|install]] Alpine Linux''' Disable Secure Boot''' in UEFI firmware. [[UEFI_Secure_Boot\|Secure boot]] page has instructions for enabling it after Alpine Linux is installed.}}

	== ~~UEFI boot process~~ ==		== EFI system partition ==

	UEFI ~~has list of possible boot entries, stored in UEFI config variables~~ (~~normally in NVRAM~~)~~, and boot order config variables stored alongside them. These boot entries can be viewed and edited with <Code>efibootmgr</Code> utility available in~~ the ~~{{pkg~~\|~~efibootmgr}} package~~.		UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS [[Bootloaders\|bootloader]] apps get installed to.

	~~UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where~~ the ~~OS bootloader apps get installed~~ to. ~~UEFI~~ firmware can ~~read ESP partition, a UDF or FAT32-formatted USB drive or DVD~~, and ~~look for OS boot loaders and runs it~~.		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 from motherboard manufacturers which can run before operating system startup (like <Code>fwupdate/fwupd</Code>), and other utilities may live here too.

	The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture.		The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture.

			== 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 <Code>efibootmgr</Code> utility available in the {{pkg\|efibootmgr}} package.

	== Disk layout for UEFI ==		== Disk layout for UEFI ==
Line 97:		Line 103:
	{{Main\|UEFI Secure Boot}}		{{Main\|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. 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.		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 ~~new computer systems i.e 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~~. 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 a cost~~.		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. This means ~~that on new computer systems~~, users have to first ''' disable Secure Boot to be able to install Alpine Linux'''.		Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have. This means, users have to first ''' disable Secure Boot to be able to install Alpine Linux'''.

	~~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 from motherboard manufacturers which can run before operating system startup (like <Code>fwupdate/fwupd</Code>), and other utilities may live here too~~.		[[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.

	== See also ==		== See also ==

Prabuanand: changed heading for Secure boot

2025-11-01T09:58:03Z

changed heading for Secure boot

← Older revision		Revision as of 09:58, 1 November 2025
Line 94:		Line 94:
	\|}		\|}

	== Secure boot ==		== Secure boot process ==
	{{Main\|UEFI Secure Boot}}		{{Main\|UEFI Secure Boot}}

Prabuanand: changed from "is" to "may"

2025-11-01T09:52:47Z

changed from "is" to "may"

← Older revision		Revision as of 09:52, 1 November 2025
Line 41:		Line 41:
	=== BIOS-MBR 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. ~~A BIOS boot partition with "boot" flag is required when using this 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.		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 [[#BIOS boot process\|BIOS only motherboards]]'''.		'''Use this only on [[#BIOS boot process\|BIOS only motherboards]]'''. A BIOS boot partition with "boot" flag may be required when using this layout, depending on the firmware implementation.

	{\| class="wikitable"		{\| class="wikitable"

Prabuanand: changes to make the information more accurate

2025-11-01T09:43:53Z

changes to make the information more accurate

← Older revision		Revision as of 09:43, 1 November 2025
Line 6:		Line 6:
	== UEFI boot process ==		== UEFI boot process ==

	UEFI has ~~several lists~~ of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. These boot entries can be viewed and edited with <Code>efibootmgr</Code> utility available in the {{pkg\|efibootmgr}} package.		UEFI has list of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. These boot entries can be viewed and edited with <Code>efibootmgr</Code> utility available in the {{pkg\|efibootmgr}} package.

	UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS bootloader apps get installed to. UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.		UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS bootloader apps get installed to. UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.
Line 14:		Line 14:
	== Disk layout for UEFI ==		== Disk layout for UEFI ==

	[[#UEFI-GPT layout\|UEFI-GPT layout]] is the recommended layout for UEFI. 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~~. UEFI booting does not involve any~~ "boot" flag~~, as that's it's a need only for BIOS booting~~.		[[#UEFI-GPT layout\|UEFI-GPT layout]] is the recommended layout for UEFI.

			The UEFI booting relies on the boot entries in NVRAM and looks for OS boot loaders and runs it. Parted and its front-ends use a "boot" flag on GPT to indicate that a partition is an EFI system partition(ESP), but the "boot" flag is not used by [[#UEFI boot process\|UEFI boot process]].

	=== UEFI-GPT layout ===		=== UEFI-GPT layout ===
Line 39:		Line 41:
	=== BIOS-MBR 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.		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. A BIOS boot partition with "boot" flag is required when using this layout.

			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.

	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.~~ ''~~'Avoid~~ this ~~except~~ on [[#BIOS boot process\|BIOS only motherboards]] ~~and CSM is a deprecated feature as of late 2020's~~'''.		'''Use this only on [[#BIOS boot process\|BIOS only motherboards]]'''.

	{\| class="wikitable"		{\| class="wikitable"
Line 70:		Line 74:
	=== BIOS-GPT 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 ~~only~~ required when using this layout. This partition must '''not''' be formatted with a file system or mounted. ~~'''Not recommended'''~~		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"

Prabuanand: updated the contents of the page

2025-11-01T08:02:22Z

updated the contents of the page

← Older revision		Revision as of 08:02, 1 November 2025
Line 1:		Line 1:
	{{TOC right}}		{{TOC right}}
	Unified Extensible Firmware Interface (UEFI) is a specification for the firmware architecture of a computing platform~~. When a computer is powered on, the UEFI-implementation is typically the first that runs, before starting the operating system~~. This page documents how Alpine Linux works with devices using UEFI firmware.		[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.

	{{~~Todo~~\|~~This article~~ is ~~written~~ with a ~~PC-centric~~ (~~i686+x86_64~~) ~~point of view~~. ~~Help making this article more applicable to other~~ UEFI ~~Architectures~~, ~~particularly ARM~~, ~~would be greatly appreciated~~.}}		{{Tip\|To [[Installation\|install]] Alpine Linux''' Disable Secure Boot''' in UEFI firmware. [[UEFI_Secure_Boot\|Secure boot]] page has instructions for enabling it after Alpine Linux is installed.}}

			== UEFI boot process ==

			UEFI has several lists of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. These boot entries can be viewed and edited with <Code>efibootmgr</Code> utility available in the {{pkg\|efibootmgr}} package.

			UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS bootloader apps get installed to. UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.

			The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is {{Path\|\efi\boot\bootx64.efi}} and {{Path\|\efi\boot\bootaa64.efi}} on ARM64 architecture.

	== Disk layout for UEFI ==		== Disk layout for UEFI ==
	Alpine Linux requires a root partition, but on UEFI systems an EFI System Partition(ESP) is also required. The EFI System Partition must contain a bootloader program in {{path\|\EFI\$bootloader.efi}}.{{citation needed}}

	~~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~~. ~~These~~ boot ~~entries can be viewed and edited with <Code>efibootmgr</Code> utility available in the {{pkg\|efibootmgr}} package~~.		[[#UEFI-GPT layout\|UEFI-GPT layout]] is the recommended layout for UEFI. 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. UEFI booting does not involve any "boot" flag, as that's it's a need only for BIOS booting.

	~~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.~~		=== UEFI-GPT layout ===

	~~The recommended filesystem format for your~~ EFI System Partition (ESP) ~~is '''vfat'''~~ (~~i.e. FAT16 or FAT32~~)~~. The '''~~root partition~~''', and any additional partitions or LVM volume groups, may be in any format that the kernel is capable of reading~~.		Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. 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:

	~~===~~ UEFI/GPT ~~minimal~~ layout ~~===~~

	{\| class="wikitable"		{\| class="wikitable"
Line 32:		Line 37:
	\|}		\|}

	=== BIOS ~~layouts~~ ===		=== 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.

	~~==== BIOS/~~MBR ~~minimal layout ====~~		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. '''Avoid this except on [[#BIOS boot process\|BIOS only motherboards]] and CSM is a deprecated feature as of late 2020's'''.
	UEFI ~~replaced the~~ BIOS ~~that was present in~~ the boot ~~ROM of all personal computers that are IBM PC compatible~~. ~~UEFI provide backwards compatibility with the~~ BIOS ~~using~~ CSM ~~booting~~.

	{\| class="wikitable"		{\| class="wikitable"
Line 54:		Line 60:
	\|}		\|}

	==== BIOS/GPT ~~minimal~~ layout ====		== 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 (2<sup>32</sup> × 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.

			=== 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 only required when using this layout. This partition must '''not''' be formatted with a file system or mounted. '''Not recommended'''

	{\| class="wikitable"		{\| class="wikitable"
Line 73:		Line 89:

	\|}		\|}

	~~=== Boot flags and boot partition ===~~

	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.

	~~A BIOS boot partition is only required when using GRUB for BIOS booting from a GPT disk. This partition must not be formatted with a file system or mounted.~~

	~~== Boot process ==~~
	~~=== 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 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.~~

	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.

	~~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 ===~~

	~~UEFI firmware can read a UDF or FAT32-formatted USB drive or DVD, and look for the file /efi/boot/bootx64.efi and run it.~~

	~~UEFI uses a partitioning system called GPT instead of MBR, and needs a partition called "EFI System Partition" (ESP) - a FAT32 partition where the boot loader apps get installed to.~~

	Each OS will stick its boot loader somewhere in the ESP and 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.

	== Secure boot ==		== Secure boot ==
Line 107:		Line 98:

	Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have. This means that on new computer systems, users have to first ''' disable Secure Boot to be able to install Alpine Linux'''.		Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have. This means that on new computer systems, users have to first ''' disable Secure Boot to be able to install Alpine Linux'''.

	~~{{Tip\|''' Disable Secure Boot in UEFI''' firmware to be able to [[Installation\|install]] Alpine Linux. Refer [[UEFI_Secure_Boot\|Secure boot]] page for enabling it after Alpine Linux is installed.}}~~

	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 from motherboard manufacturers which can run before operating system startup (like <Code>fwupdate/fwupd</Code>), and other utilities may live here too.		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 from motherboard manufacturers which can run before operating system startup (like <Code>fwupdate/fwupd</Code>), and other utilities may live here too.