Merge pull request #24521 from poettering/boot-loader-spec-dollar-boot-fix
boot loader spec fixes
This commit is contained in:
Lennart Poettering
+192
-136
@@ -8,12 +8,12 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
# The Boot Loader Specification
|
||||
|
||||
This document defines a set of file formats and naming conventions that allow
|
||||
the boot loader configuration to be shared between multiple operating systems
|
||||
the boot loader menu entries to be shared between multiple operating systems
|
||||
and boot loaders installed on one device.
|
||||
|
||||
Operating systems cooperatively manage a boot loader configuration directory
|
||||
that contains drop-in files, making multi-boot scenarios easy to support. Boot
|
||||
menu items are defined via a simple format that can be understood by different
|
||||
Operating systems cooperatively manage boot loader menu entry directories that
|
||||
contain drop-in files, making multi-boot scenarios easy to support. Boot menu
|
||||
entries are defined via two simple formats that can be understood by different
|
||||
boot loader implementations, operating systems, and userspace programs. The
|
||||
same scheme can be used to prepare OS media for cases where the firmware
|
||||
includes a boot loader.
|
||||
@@ -23,72 +23,105 @@ includes a boot loader.
|
||||
The target audience for this specification is:
|
||||
|
||||
* Boot loader developers, to write a boot loader that directly reads its
|
||||
configuration from these files
|
||||
menu entries from these files
|
||||
* Firmware developers, to add generic boot loading support directly to the
|
||||
firmware itself
|
||||
* OS installer developers, to create appropriate partitions and set up the
|
||||
initial boot loader configuration
|
||||
* Distribution developers, to create appropriate configuration snippets when
|
||||
initial boot loader menu entries
|
||||
* Distribution developers, to create appropriate menu entry snippets when
|
||||
installing or updating kernel packages
|
||||
* UI developers, to implement user interfaces that list and select among the
|
||||
available boot options
|
||||
|
||||
## The Boot Partition
|
||||
## The Partitions
|
||||
|
||||
Everything described below is located on one or two partitions. The boot loader
|
||||
or user-space programs reading the boot loader configuration should locate them
|
||||
or user-space programs reading the boot loader menu entries should locate them
|
||||
in the following manner:
|
||||
|
||||
* On disks with an MBR partition table:
|
||||
|
||||
* The boot partition — partition with the type ID of 0xEA — shall be used
|
||||
for boot loader configuration and entries.
|
||||
* The boot partition — a partition with the type ID of `0xEA` — shall be used
|
||||
as the single location for boot loader menu entries.
|
||||
|
||||
* On disks with GPT (GUID Partition Table)
|
||||
|
||||
* The EFI System Partition (ESP for short) — a partition with GPT type GUID
|
||||
of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b` — should be used for boot loader
|
||||
configuration and boot entries.
|
||||
* The EFI System Partition (ESP for short) — a partition with a GPT type GUID
|
||||
of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b` — may be used as one of two locations for
|
||||
boot loader menu entries.
|
||||
|
||||
* Optionally, an Extended Boot Loader Partition (XBOOTLDR partition for
|
||||
short) — a partition with GPT type GUID of
|
||||
`bc13c2ff-59e6-4262-a352-b275fd6f7172` — may be used as an additional
|
||||
location for boot loader entries. This partition must be located on the
|
||||
same disk as the ESP.
|
||||
`bc13c2ff-59e6-4262-a352-b275fd6f7172` — may be used as the second of two
|
||||
locations for boot loader menu entries. This partition must be located on
|
||||
the same disk as the ESP.
|
||||
|
||||
In the text below, `$BOOT` will be used to refer to (the root of) the first of
|
||||
the two partitions (the boot partition on MBR disks and the ESP on GPT disks),
|
||||
and `$XBOOTLDR` will be used to refer to (the root of) the optional second
|
||||
partition.
|
||||
There may be at most one partition of each of the types listed above on the
|
||||
same disk.
|
||||
|
||||
An installer for the operating system should use this logic when selecting or
|
||||
creating partitions:
|
||||
|
||||
* If `$BOOT` is not found, a new suitably sized partition (let's say 500MB)
|
||||
should be created, matching the characteristics described above. On disks
|
||||
with GPT, only the ESP partition without the XBOOTLDR partition should be
|
||||
created.
|
||||
|
||||
* If the OS is installed on a disk with GPT and the ESP partition is found
|
||||
but is too small, a new suitably sized (let's say 500MB) XBOOTLDR partition
|
||||
shall be created.
|
||||
|
||||
Those file systems shall be determined during _installation time_, and an fstab
|
||||
entry may be created. If only one partition is used, it should be mounted on
|
||||
`/boot/`. If both XBOOTLDR partition and the ESP are used, they should be
|
||||
mounted on `/boot` and `/efi`, or on `/boot` and `/boot/efi`.
|
||||
|
||||
**Note:** _Those file systems are **shared** among all OS installations on the
|
||||
system. Instead of maintaining one boot partition per installed OS (as `/boot/`
|
||||
was traditionally handled), all installed OSes use the same place for boot-time
|
||||
configuration._
|
||||
**Note:** _These partitions are **shared** among all OS installations on the
|
||||
same disk. Instead of maintaining one boot partition per installed OS (as
|
||||
`/boot/` was traditionally handled), all installed OSes use the same place for
|
||||
boot loader menu entries._
|
||||
|
||||
For systems where the firmware is able to read file systems directly, the ESP
|
||||
must — and the XBOOTLDR partition should — be a file system readable by the
|
||||
firmware. For most systems this means VFAT (16 or 32 bit). Applications
|
||||
accessing both partitions should hence not assume that fancier file system
|
||||
features such as symlinks, hardlinks, access control or case sensitivity are
|
||||
supported.
|
||||
must — and the MBR boot and GPT XBOOTLDR partition should — be a file system
|
||||
readable by the firmware. For most systems this means VFAT (16 or 32
|
||||
bit). Applications accessing both partitions should hence not assume that
|
||||
fancier file system features such as symlinks, hardlinks, access control or
|
||||
case sensitivity are supported.
|
||||
|
||||
### The `$BOOT` Partition Placeholder
|
||||
|
||||
In the text below, the placeholder `$BOOT` will be used to refer to the
|
||||
partition determined as follows:
|
||||
|
||||
1. On disks with an MBR partition table: → the boot partition, as described above
|
||||
|
||||
2. On disks with a GPT partition table: → the XBOOTLDR partition if it exists
|
||||
|
||||
3. Otherwise, on disks with a GPT partition table: → the ESP
|
||||
|
||||
`$BOOT` is the *primary* place to put boot menu entry resources into, but
|
||||
typically not the only one. Most importantly, boot loaders should also pick up
|
||||
menu entries from the ESP, even if XBOOTLDR exists (for details see below).
|
||||
|
||||
### Creating These Partitions
|
||||
|
||||
An installer for an operating system should use this logic when selecting or
|
||||
creating partitions:
|
||||
|
||||
* If a boot partition (in case of MBR) or an XBOOTLDR partition (in case of
|
||||
GPT) already exists it should be used as `$BOOT` and used as primary
|
||||
location to place boot loader menu resources in.
|
||||
|
||||
* Otherwise, if on GPT and an ESP is found and it is large enough (let's say
|
||||
at least 1G) it should be used as `$BOOT` and used as primary location to
|
||||
place boot loader menu resources in.
|
||||
|
||||
* Otherwise, if on GPT and neither XBOOTLDR nor ESP exist, an ESP should be
|
||||
created of the appropriate size and be used as `$BOOT`, and used as primary
|
||||
location to place boot loader menu resources in.
|
||||
|
||||
* Otherwise, a boot partition (in case of MBR) or XBOOTLDR partition (in case
|
||||
of GPT) should be created of an appropriate size, and be used as `$BOOT`,
|
||||
and used as primary location to place boot loader menu resources in.
|
||||
|
||||
These partitions shall be determined during _installation time_, and
|
||||
`/etc/fstab` entries may be created.
|
||||
|
||||
### Mount Points
|
||||
|
||||
It is recommended to mount `$BOOT` to `/boot/`, and the ESP to `/efi/`. If
|
||||
`$BOOT` and the ESP are the same, then either a bind mount or a symlink should
|
||||
be established making the partition available under both paths.
|
||||
|
||||
(Mounting the ESP to `/boot/efi/`, as was traditionally done, is not
|
||||
recommended. Such a nested setup complicates an implementation via direct
|
||||
`autofs` mounts — as implemented by `systemd` for example —, as establishing
|
||||
the inner `autofs` will trigger the outer one. Mounting the two partitions via
|
||||
`autofs` is recommended because the simple VFAT file system has weak data
|
||||
integrity properties and should remain unmounted whenever possible.)
|
||||
|
||||
## Boot Loader Entries
|
||||
|
||||
@@ -108,37 +141,43 @@ from the user. Only entries matching the feature set of boot loader and system
|
||||
shall be considered and displayed. This allows image builders to put together
|
||||
images that transparently support multiple different architectures.
|
||||
|
||||
Note that the boot partitions are not supposed to be the exclusive territory of
|
||||
this specification. This specification only defines semantics of the `/loader/`
|
||||
directory inside the file system (see below), but it doesn't intend to define
|
||||
ownership of the whole file system. Boot loaders, firmware, and other software
|
||||
implementing this specification may choose to place other files and directories
|
||||
in the same file system. For example, boot loaders that implement this
|
||||
specification might install their own boot code on the same partition; this is
|
||||
particularly common in the case of the ESP. Implementations of this specification
|
||||
must be able to operate correctly if files or directories other than `/loader/`
|
||||
are found in the top level directory. Implementations that add their own files
|
||||
or directories to the file systems should use well-named directories, to make
|
||||
name collisions between multiple users of the file system unlikely.
|
||||
Note that the three partitions described above are not supposed to be the
|
||||
exclusive territory of this specification. This specification only defines
|
||||
semantics of the `/loader/entries/` directory (along with the companion file
|
||||
`/loader/entries.srel`) and the `/EFI/Linux/` directory inside the file system,
|
||||
but it doesn't intend to define contents of the rest of the file system. Boot
|
||||
loaders, firmware, and other software implementing this specification may
|
||||
choose to place other files and directories in the same file system. For
|
||||
example, boot loaders that implement this specification might install their own
|
||||
boot code on the same partition; this is particularly common in the case of the
|
||||
ESP. Implementations of this specification must be able to operate correctly if
|
||||
files or directories other than `/loader/entries/` and `/EFI/Linux/` are found
|
||||
in the top level directory. Implementations that add their own files or
|
||||
directories to the file systems should use well-named directories, to make name
|
||||
collisions between multiple users of the file system unlikely.
|
||||
|
||||
### Type #1 Boot Loader Specification Entries
|
||||
|
||||
`$ESP/loader/` is the main directory containing the configuration for the boot
|
||||
loader.
|
||||
`/loader/entries/` in `$BOOT` is the primary directory containing Type #1
|
||||
drop-in snippets defining boot entries, one `.conf` file for each boot menu
|
||||
item. Each OS may provide one or more such entries.
|
||||
|
||||
**Note:** _In all cases the `/loader/` directory should be located directly in
|
||||
the root of the file system. Specifically, the `/loader/` directory should
|
||||
**not** be located under the `/EFI/` subdirectory on the ESP._
|
||||
If the ESP is separate from `$BOOT` it may also contain a `/loader/entries/`
|
||||
directory, where the boot loader should look for boot entry snippets, as an
|
||||
additional source. The boot loader should enumerate both directories and
|
||||
present a merged list to the user. Note that this is done for compatibility
|
||||
only: while boot loaders should look in both places, OSes should only add their
|
||||
files to `$BOOT`.
|
||||
|
||||
`$BOOT/loader/entries/` and `$XBOOTLDR/loader/entries/` are the directories
|
||||
containing the drop-in snippets defining boot entries, one `.conf` file for
|
||||
each boot menu item. Each OS may provide one or more such entries. The boot
|
||||
loader should enumerate both directories and provide a merged list.
|
||||
**Note:** _In all cases the `/loader/entries/` directory should be located
|
||||
directly in the root of the file system. Specifically, the `/loader/entries/`
|
||||
directory should **not** be located under the `/EFI/` subdirectory on the ESP._
|
||||
|
||||
The file name is used for identification of the boot item but shall never be
|
||||
presented to the user in the UI. The file name may be chosen freely but should
|
||||
be unique enough to avoid clashes between OS installations. More specifically,
|
||||
it is suggested to include the `entry-token` (see
|
||||
The file name of the boot entry snippets is used for identification of the boot
|
||||
item but shall never be presented to the user in the UI. The file name may be
|
||||
chosen freely but should be unique enough to avoid clashes between OS
|
||||
installations. More specifically, it is suggested to include the `entry-token`
|
||||
(see
|
||||
[kernel-install](https://www.freedesktop.org/software/systemd/man/kernel-install.html))
|
||||
or machine ID (see
|
||||
[/etc/machine-id](https://www.freedesktop.org/software/systemd/man/machine-id.html)),
|
||||
@@ -155,9 +194,9 @@ set: ASCII upper and lower case characters, digits, "+", "-", "_" and ".".
|
||||
Also, the file names should have a length of at least one and at most 255
|
||||
characters (including the file name suffix).
|
||||
|
||||
These configuration snippets shall be UNIX-style text files (i.e. lines
|
||||
These boot loader menu snippets shall be UNIX-style text files (i.e. lines
|
||||
separated by a single newline character), in the UTF-8 encoding. The
|
||||
configuration snippets are loosely inspired by Grub1's configuration syntax.
|
||||
boot loader menu snippets are loosely inspired by Grub1's configuration syntax.
|
||||
Lines beginning with "#" are used for comments and shall be ignored. The first
|
||||
word of a line is used as key and is separated by one or more spaces from the
|
||||
value.
|
||||
@@ -202,16 +241,17 @@ The following keys are recognized:
|
||||
|
||||
Example: `sort-key fedora`
|
||||
|
||||
* `linux` is the Linux kernel to spawn and as a path relative to file system
|
||||
root. It is recommended that every distribution creates a machine id and
|
||||
version specific subdirectory and places its kernels and initial RAM disk
|
||||
images there.
|
||||
* `linux` is the Linux kernel image to execute and takes a path relative to the
|
||||
root of the file system containing the boot entry snippet itself. It is
|
||||
recommended that every distribution creates an entry-token/machine-id and
|
||||
version specific subdirectory and places its kernels and initrd images there
|
||||
(see below).
|
||||
|
||||
Example: `linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux`
|
||||
|
||||
* `initrd` is the initrd to use when executing the kernel. This key is
|
||||
optional. This key may appear more than once in which case all specified
|
||||
images are used, in the order they are listed.
|
||||
* `initrd` is the initrd `cpio` image to use when executing the kernel. This key
|
||||
may appear more than once in which case all specified images are used, in the
|
||||
order they are listed.
|
||||
|
||||
Example: `initrd 6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd`
|
||||
|
||||
@@ -220,7 +260,7 @@ The following keys are recognized:
|
||||
|
||||
* `options` shall contain kernel parameters to pass to the Linux kernel to
|
||||
spawn. This key is optional and may appear more than once in which case all
|
||||
specified parameters are used in the order they are listed.
|
||||
specified parameters are combined in the order they are listed.
|
||||
|
||||
Example: `options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2 quiet`
|
||||
|
||||
@@ -244,7 +284,7 @@ The following keys are recognized:
|
||||
|
||||
Example: `architecture aa64`
|
||||
|
||||
Each configuration drop-in snippet must include at least a `linux` or an `efi`
|
||||
Each boot loader menu entry drop-in snippet must include at least a `linux` or an `efi`
|
||||
key. Here is an example for a complete drop-in file:
|
||||
|
||||
# /boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf
|
||||
@@ -268,18 +308,27 @@ i.e. it is a good idea that both images shipped as UEFI PE images and those
|
||||
which are not don't make unnecessary assumption on the underlying firmware,
|
||||
i.e. don't hard depend on legacy BIOS calls or UEFI boot services.
|
||||
|
||||
When Type #1 configuration snippets refer to other files (for `linux`,
|
||||
When Type #1 boot loader menu entry snippets refer to other files (for `linux`,
|
||||
`initrd`, `efi`, `devicetree`, and `devicetree-overlay`), those files must be
|
||||
located on the same partition, and the paths must be absolute paths relative to
|
||||
the root of that file system. The naming of those files can be chosen by the
|
||||
installer. A recommended scheme is described in the next section.
|
||||
installer. A recommended scheme is described in the next section. Paths should
|
||||
be normalized, i.e. not include `..`, `.` or a sequence of more than one
|
||||
`/`. Paths may be prefixed with a `/`, but this is optional and has the same
|
||||
effect as paths without it: all paths are always relative to the root directory
|
||||
of the partition they are referenced from.
|
||||
|
||||
Even though the backing file system is typically case-insensitive (i.e. VFAT)
|
||||
it is strongly recommended to reference files in the casing actually used for
|
||||
the directories/files, so that placing these files on other file systems is
|
||||
still safe and robust.
|
||||
|
||||
### Recommended Directory Layout for Additional Files
|
||||
|
||||
It is recommended to place the kernel and other other files comprising a single
|
||||
boot loader entry in a separate directory:
|
||||
`/<entry-token-or-machine-id>/<version>/`. This naming scheme uses the same
|
||||
elements as the boot loader configuration snippet, providing the same level of
|
||||
elements as the boot loader menu entry snippet, providing the same level of
|
||||
uniqueness.
|
||||
|
||||
Example: `$BOOT/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux`
|
||||
@@ -292,8 +341,8 @@ because it is hard to avoid conflicts in a multi-boot installation.
|
||||
### Standard-conformance Marker File
|
||||
|
||||
Unfortunately, there are implementations of boot loading infrastructure that
|
||||
are also using the `/loader/entries/` directory, but installing files that do
|
||||
not follow this specification. In order to minimize confusion, a boot loader
|
||||
are also using the `/loader/entries/` directory, but install files that do not
|
||||
follow this specification. In order to minimize confusion, a boot loader
|
||||
implementation may place the file `/loader/entries.srel` next to the
|
||||
`/loader/entries/` directory containing the ASCII string `type1` (followed by a
|
||||
UNIX newline). Tools that need to determine whether an existing directory
|
||||
@@ -306,13 +355,16 @@ does not exist, no assumptions should be made.
|
||||
### Type #2 EFI Unified Kernel Images
|
||||
|
||||
A unified kernel image is a single EFI PE executable combining an EFI stub
|
||||
loader, a kernel image, an initramfs image, and the kernel command line. See
|
||||
the description of the `--uefi` option in
|
||||
[dracut(8)](https://man7.org/linux/man-pages/man8/dracut.8.html). Such unified
|
||||
images are installed in the`$BOOT/EFI/Linux/` and `$XBOOTLDR/EFI/Linux/`
|
||||
directories and must have the extension `.efi`.
|
||||
Support for images of this type is of course specific to systems with EFI
|
||||
firmware. Ignore this section if you work on systems not supporting EFI.
|
||||
loader, a kernel image, an initrd image, and the kernel command line. See
|
||||
[systemd-stub(7)](https://www.freedesktop.org/software/systemd/man/systemd-stub.html)
|
||||
for details. The primary place for such unified images is the `/EFI/Linux/`
|
||||
directory in `$BOOT`. Operating systems should place unified EFI kernels only
|
||||
in the `$BOOT` partition. Boot loaders should also look in the `/EFI/Linux/` of
|
||||
the ESP — if it is different from `$BOOT` — and present a merged list of menu
|
||||
entries from both partitions. Regardless if placed in the primary or secondary
|
||||
location: the files must have the extension `.efi`. Support for images of this
|
||||
type is of course specific to systems with EFI firmware. Ignore this section if
|
||||
you work on systems not supporting EFI.
|
||||
|
||||
Type #2 file names should be chosen from the same restricted character set as
|
||||
Type #1 described above (but with the file name suffix of `.efi` instead of
|
||||
@@ -322,7 +374,7 @@ Images of this type have the advantage that all metadata and payload that makes
|
||||
up the boot entry is contained in a single PE file that can be signed
|
||||
cryptographically as one for the purpose of EFI SecureBoot.
|
||||
|
||||
A valid unified kernel image must contain two PE sections:
|
||||
A valid unified kernel image in the `/EFI/Linux/` directory must contain two PE sections:
|
||||
|
||||
* `.cmdline` section with the kernel command line,
|
||||
* `.osrel` section with an embedded copy of the
|
||||
@@ -339,42 +391,44 @@ On EFI, any such images shall be added to the list of valid boot entries.
|
||||
|
||||
### Additional Notes
|
||||
|
||||
Note that these configurations snippets do not need to be the only
|
||||
configuration source for a boot loader. It may extend this list of entries with
|
||||
additional items from other configuration files (for example its own native
|
||||
configuration files) or automatically detected other entries without explicit
|
||||
configuration.
|
||||
Note that these boot entry snippets and unified kernels do not need to be the
|
||||
only menu entry sources for a boot loader. It may extend this list of
|
||||
entries with additional items from other configuration files (for example its
|
||||
own native configuration files) or automatically detected other entries without
|
||||
explicit configuration.
|
||||
|
||||
To make this explicitly clear: this specification is designed with "free"
|
||||
operating systems in mind, starting Windows or macOS is out of focus with these
|
||||
configuration snippets, use boot-loader specific solutions for that. In the
|
||||
text above, if we say "OS" we hence imply "free", i.e. primarily Linux (though
|
||||
this could be easily be extended to the BSDs and whatnot).
|
||||
operating systems in mind, starting Windows or MacOS is out of focus with these
|
||||
boot loader menu entry snippets, use boot-loader specific solutions for
|
||||
that. In the text above, if we say "OS" we hence imply "free", i.e. primarily
|
||||
Linux (though this could be easily be extended to the BSDs and whatnot).
|
||||
|
||||
Note that all paths used in the configuration snippets use a Unix-style "/" as
|
||||
path separator. This needs to be converted to an EFI-style "\\" separator in
|
||||
EFI boot loaders.
|
||||
Note that all paths used in the boot loader menu entry snippets use a
|
||||
Unix-style "/" as path separator. This needs to be converted to an EFI-style
|
||||
"\\" separator in EFI boot loaders.
|
||||
|
||||
|
||||
## Locating Boot Entries
|
||||
|
||||
A _boot loader_ locates `$BOOT` and `$XBOOTLDR`, then simply reads all the
|
||||
files `$BOOT/loader/entries/*.conf` and `$XBOOTLDR/loader/entries/*.conf`, and
|
||||
populates its boot menu. On EFI, it then extends this with any unified kernel
|
||||
images found in `$BOOT/EFI/Linux/*.efi` and `$XBOOTLDR/EFI/Linux/*.efi`. It may
|
||||
also add additional entries, for example a "Reboot into firmware" option.
|
||||
Optionally it may sort the menu based on the `sort-key`, `machine-id` and
|
||||
`version` fields, and possibly others. It uses the file name to identify
|
||||
specific items, for example in case it supports storing away default entry
|
||||
information somewhere. A boot loader should generally not modify these files.
|
||||
A _boot loader_ locates the XBOOTLDR partition and the ESP, then simply reads
|
||||
all the files `/loader/entries/*.conf` in them, and populates its boot menu
|
||||
(and handle gracefully if one of the two partitions is missing). On EFI, it
|
||||
then extends this with any unified kernel images found in `/EFI/Linux/*.efi` in
|
||||
the two partitions. It may also add additional entries, for example a "Reboot
|
||||
into firmware" option. Optionally it may sort the menu based on the
|
||||
`sort-key`, `machine-id` and `version` fields, and possibly others. It uses the
|
||||
file name to identify specific items, for example in case it supports storing
|
||||
away default entry information somewhere. A boot loader should generally not
|
||||
modify these files.
|
||||
|
||||
For "Boot Loader Specification Entries" (Type #1), the _kernel package
|
||||
installer_ installs the kernel and initrd images to `$XBOOTLDR` (if used) or
|
||||
`$BOOT`. It is recommended to place these files in a vendor and OS and
|
||||
installation specific directory. It then generates a configuration snippet,
|
||||
placing it in `$BOOT/loader/entries/xyz.conf`, with "xyz" as concatenation of
|
||||
machine id and version information (see above). The files created by a kernel
|
||||
package are tied to the kernel package and should be removed along with it.
|
||||
installer_ installs the kernel and initrd images to `$BOOT`. It is recommended
|
||||
to place these files in a vendor and OS and installation specific directory. It
|
||||
then generates a boot loader menu entry snippet, placing it in
|
||||
`$BOOT/loader/entries/xyz.conf`, with "xyz" as concatenation of
|
||||
entry-token/machine-id and version information (see above). The files created
|
||||
by a kernel package are tied to the kernel package and should be removed along
|
||||
with it.
|
||||
|
||||
For "EFI Unified Kernel Images" (Type #2), the vendor or kernel package
|
||||
installer should create the combined image and drop it into
|
||||
@@ -382,14 +436,16 @@ installer should create the combined image and drop it into
|
||||
removed along with it.
|
||||
|
||||
A _UI application_ intended to show available boot options shall operate
|
||||
similarly to a boot loader, but might apply additional filters, for example by
|
||||
filtering the booted OS via the machine ID, or by suppressing all but the
|
||||
newest kernel versions.
|
||||
similarly to a boot loader (and thus search both `$BOOT` and the ESP if
|
||||
distinct), but might apply additional filters, for example by filtering the
|
||||
booted OS via the machine ID, or by suppressing all but the newest kernel
|
||||
versions.
|
||||
|
||||
An _OS installer_ picks the right place for `$BOOT` as defined above (possibly
|
||||
creating a partition and file system for it) and creates the `/loader/entries/`
|
||||
directory in it. It then installs an appropriate boot loader that can read
|
||||
these snippets. Finally, it installs one or more kernel packages.
|
||||
directory and the `/loader/entries.srel` file in it (the latter only if the
|
||||
directory didn't exist yet). It then installs an appropriate boot loader that
|
||||
can read these snippets. Finally, it installs one or more kernel packages.
|
||||
|
||||
## Boot counting
|
||||
|
||||
@@ -403,7 +459,7 @@ boots is exhausted, the entry is marked as "bad".
|
||||
Which boots are "successful" is determined by the operating system. systemd
|
||||
provides a generic mechanism that can be extended with arbitrary checks and
|
||||
actions, see [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT.md), but the
|
||||
boot counting mechanism described in this specifaction can also be used with
|
||||
boot counting mechanism described in this specification can also be used with
|
||||
other implementations.
|
||||
|
||||
The boot counting data is stored in the name of the boot loader entry. A boot
|
||||
@@ -562,18 +618,18 @@ This specification brings the following advantages:
|
||||
interfering with the entries of other installed operating systems.
|
||||
|
||||
* Drop-in directories are now pretty ubiquitous on Linux as an easy way to
|
||||
extend configuration without having to edit, regenerate or manipulate
|
||||
extend boot loader menus without having to edit, regenerate or manipulate
|
||||
configuration files. For the sake of uniformity, we should do the same for
|
||||
the boot menu.
|
||||
|
||||
* Userspace code can sanely parse boot loader configuration which is essential
|
||||
* Userspace code can sanely parse boot loader menu entries which is essential
|
||||
with modern firmware which does not necessarily initialize USB keyboards
|
||||
during boot, which makes boot menus hard to reach for the user. If userspace
|
||||
code can parse the boot loader configuration too, UI can be written that
|
||||
code can parse the boot loader menu entries too, UI can be written that
|
||||
select a boot menu item to boot into before rebooting the machine, thus not
|
||||
requiring interactivity during early boot.
|
||||
|
||||
* To unify and thus simplify configuration of the various boot loaders, which
|
||||
* To unify and thus simplify menu entries of the various boot loaders, which
|
||||
makes configuration of the boot loading process easier for users,
|
||||
administrators, and developers alike.
|
||||
|
||||
@@ -673,9 +729,9 @@ There are a couple of items that are out of focus for this specification:
|
||||
* Referencing kernels or initrds on other partitions other than the partition
|
||||
containing the Type #1 boot loader entry. This is by design, as specifying
|
||||
other partitions or devices would require a non-trivial language for denoting
|
||||
device paths. In particular this means that on non-EFI systems configuration
|
||||
snippets following this specification cannot be used to spawn other operating
|
||||
systems (such as Windows).
|
||||
device paths. In particular this means that on non-EFI systems boot loader
|
||||
menu entry snippets following this specification cannot be used to spawn
|
||||
other operating systems (such as Windows).
|
||||
|
||||
|
||||
## Links
|
||||
|
||||
Reference in New Issue
Block a user