]>
Commit | Line | Data |
---|---|---|
c3e270f4 | 1 | --- |
a0fadf66 | 2 | title: Boot Loader Specification |
4cdca0af | 3 | category: Booting |
b41a3f66 | 4 | layout: default |
0aff7b75 | 5 | SPDX-License-Identifier: LGPL-2.1-or-later |
c3e270f4 FB |
6 | --- |
7 | ||
c3c5eeca LP |
8 | # The Boot Loader Specification |
9 | ||
7bb36d2d ZJS |
10 | This document defines a set of file formats and naming conventions that allow |
11 | the boot loader configuration to be shared between multiple operating systems | |
12 | and boot loaders installed on one device. | |
13 | ||
14 | Operating systems cooperatively manage a boot loader configuration directory | |
15 | that contains drop-in files, making multi-boot scenarios easy to support. Boot | |
16 | menu items are defined via a simple format that can be understood by different | |
17 | boot loader implementations, operating systems, and userspace programs. The | |
18 | same scheme can be used to prepare OS media for cases where the firmware | |
19 | includes a boot loader. | |
20 | ||
21 | ## Target audience | |
22 | ||
23 | The target audience for this specification is: | |
c3c5eeca | 24 | |
49d5e4d0 | 25 | * Boot loader developers, to write a boot loader that directly reads its |
7bb36d2d | 26 | configuration from these files |
49d5e4d0 LP |
27 | * Firmware developers, to add generic boot loading support directly to the |
28 | firmware itself | |
7bb36d2d | 29 | * OS installer developers, to create appropriate partitions and set up the |
0f5a416c | 30 | initial boot loader configuration |
7bb36d2d ZJS |
31 | * Distribution developers, to create appropriate configuration snippets when |
32 | installing or updating kernel packages | |
33 | * UI developers, to implement user interfaces that list and select among the | |
34 | available boot options | |
c3c5eeca | 35 | |
7bb36d2d | 36 | ## The boot partition |
c3c5eeca | 37 | |
7bb36d2d ZJS |
38 | Everything described below is located on a file system that will be called |
39 | `$BOOT`. The boot loader or user-space programs reading the boot loader | |
40 | configuration should pick `$BOOT` according to the following rules: | |
c3c5eeca | 41 | |
7bb36d2d | 42 | * On disks with an MBR partition table: |
c3c5eeca | 43 | |
7bb36d2d | 44 | * A partition with the type ID of 0xEA shall be used as `$BOOT`. |
c3c5eeca | 45 | |
04c31af4 | 46 | * On disks with GPT (GUID Partition Table) |
7bb36d2d ZJS |
47 | |
48 | * If an Extended Boot Loader Partition (XBOOTLDR partition for short) — a | |
49 | partition with GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172` — | |
50 | is found, it should be used as `$BOOT`. | |
51 | ||
52 | * Otherwise, the EFI System Partition (ESP for short) — a partition with | |
53 | GPT type GUID of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b` — should | |
49d5e4d0 | 54 | be used as `$BOOT`. |
7bb36d2d ZJS |
55 | |
56 | An installer for the operating system should use this logic when selecting or | |
57 | creating partitions: | |
58 | ||
59 | * If `$BOOT` is not found, a new suitably sized partition (let's say 500MB) | |
60 | should be created and used as `$BOOT`, matching the characteristics | |
61 | described above. On disks with GPT, just an ESP partition without a | |
62 | XBOOTLDR partition should be created. | |
63 | ||
64 | * If the OS is installed on a disk with GPT and the ESP partition is found | |
65 | but is too small, a new suitably sized (let's say 500MB) XBOOTLDR partition | |
66 | shall be created and used as `$BOOT`. | |
49d5e4d0 LP |
67 | |
68 | This placeholder file system shall be determined during _installation time_, | |
69 | and an fstab entry may be created. It should be mounted to either `/boot/` or | |
70 | `/efi/`. Additional locations like `/boot/efi/` (with `/boot/` being a separate | |
71 | file system) might be supported by implementations. This is not recommended | |
72 | because the mounting of `$BOOT` is then dependent on and requires the mounting | |
73 | of the intermediate file system. | |
74 | ||
7bb36d2d ZJS |
75 | **Note:** _`$BOOT` is **shared** among all OS installations of a system. |
76 | Instead of maintaining one `$BOOT` per installed OS (as `/boot/` was | |
77 | traditionally handled), all installed OSes use the same place for boot-time | |
78 | configuration._ | |
c3c5eeca | 79 | |
e178b335 LP |
80 | For systems where the firmware is able to read file systems directly, `$BOOT` |
81 | must be a file system readable by the firmware. For other systems and generic | |
7bb36d2d ZJS |
82 | installation and live media, `$BOOT` must be a VFAT (16 or 32) file system. |
83 | Applications accessing `$BOOT` should hence not assume that fancier file system | |
84 | features such as symlinks, hardlinks, access control or case sensitivity are | |
85 | supported. | |
86 | ||
87 | ## Boot loader entries | |
c3c5eeca | 88 | |
084a8029 | 89 | This specification defines two types of boot loader entries. The first type is |
7bb36d2d | 90 | text based, very simple, and suitable for a variety of firmware, architecture |
084a8029 | 91 | and image types ("Type #1"). The second type is specific to EFI, but allows |
b2454670 | 92 | single-file images that embed all metadata in the kernel binary itself, which |
084a8029 LP |
93 | is useful to cryptographically sign them as one file for the purpose of |
94 | SecureBoot ("Type #2"). | |
95 | ||
96 | Not all boot loader entries will apply to all systems. For example, Type #1 | |
97 | entries that use the `efi` key and all Type #2 entries only apply to EFI | |
98 | systems. Entries using the `architecture` key might specify an architecture that | |
99 | doesn't match the local one. Boot loaders should ignore all entries that don't | |
100 | match the local platform and what the boot loader can support, and hide them | |
101 | from the user. Only entries matching the feature set of boot loader and system | |
102 | shall be considered and displayed. This allows image builders to put together | |
103 | images that transparently support multiple different architectures. | |
104 | ||
8384ed93 LP |
105 | Note that the `$BOOT` partition is not supposed to be exclusive territory of |
106 | this specification. This specification only defines semantics of the `/loader/` | |
107 | directory inside the file system (see below), but it doesn't intend to define | |
108 | ownership of the whole file system exclusively. Boot loaders, firmware, and | |
7bb36d2d ZJS |
109 | other software implementing this specification may choose to place other files |
110 | and directories in the same file system. For example, boot loaders that | |
111 | implement this specification might install their own boot code on the same | |
112 | partition; on systems where `$BOOT` is the ESP this is a particularly common | |
8384ed93 LP |
113 | setup. Implementations of this specification must be able to operate correctly |
114 | if files or directories other than `/loader/` are found in the top level | |
115 | directory. Implementations that add their own files or directories to the file | |
116 | systems should use well-named directories, to make name collisions between | |
117 | multiple users of the file system unlikely. | |
118 | ||
084a8029 | 119 | ### Type #1 Boot Loader Specification Entries |
5be7bfbc | 120 | |
0f5a416c ZJS |
121 | `$BOOT/loader/` is the main directory containing the configuration for the boot |
122 | loader. | |
49d5e4d0 LP |
123 | |
124 | **Note:** _In all cases the `/loader/` directory should be located directly in | |
125 | the root of the file system. Specifically, if `$BOOT` is the ESP, then | |
126 | `/loader/` directory should be located directly in the root directory of the | |
127 | ESP, and not in the `/EFI/` subdirectory._ | |
5be7bfbc | 128 | |
0f5a416c ZJS |
129 | `$BOOT/loader/entries/` is the directory containing the drop-in snippets |
130 | defining boot entries, one `.conf` file for each boot menu item. Each OS may | |
131 | provide one or more such entries. | |
132 | ||
133 | The file name is used for identification of the boot item but shall never be | |
134 | presented to the user in the UI. The file name may be chosen freely but should | |
135 | be unique enough to avoid clashes between OS installations. More specifically, | |
136 | it is suggested to include the `entry-token` (see | |
137 | [kernel-install](https://www.freedesktop.org/software/systemd/man/kernel-install.html)) | |
138 | or machine ID (see | |
139 | [/etc/machine-id](https://www.freedesktop.org/software/systemd/man/machine-id.html)), | |
140 | and the kernel version (as returned by `uname -r`, including the OS | |
141 | identifier), so that the whole filename is | |
142 | `$BOOT/loader/entries/<entry-token-or-machine-id>-<version>.conf`. | |
7bb36d2d ZJS |
143 | |
144 | Example: `$BOOT/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf`. | |
d9067aba LP |
145 | |
146 | In order to maximize compatibility with file system implementations and | |
147 | restricted boot loader environments, and to minimize conflicting character use | |
49d5e4d0 | 148 | with other programs, file names shall be chosen from a restricted character |
7bb36d2d ZJS |
149 | set: ASCII upper and lower case characters, digits, "+", "-", "_" and ".". |
150 | Also, the file names should have a length of at least one and at most 255 | |
151 | characters (including the file name suffix). | |
152 | ||
153 | These configuration snippets shall be UNIX-style text files (i.e. lines | |
154 | separated by a single newline character), in the UTF-8 encoding. The | |
155 | configuration snippets are loosely inspired by Grub1's configuration syntax. | |
156 | Lines beginning with "#" are used for comments and shall be ignored. The first | |
157 | word of a line is used as key and is separated by one or more spaces from the | |
158 | value. | |
159 | ||
160 | #### Type #1 Boot Loader Entry Keys | |
161 | ||
162 | The following keys are recognized: | |
163 | ||
164 | * `title` is a human-readable title for this menu item to be displayed in the | |
165 | boot menu. It is a good idea to initialize this from the `PRETTY_NAME=` of | |
14bacc74 ZJS |
166 | [os-release](https://www.freedesktop.org/software/systemd/man/os-release.html). |
167 | This name should be descriptive and does not have to be unique. If a boot | |
168 | loader discovers two entries with the same title it should show more than | |
169 | just the raw title in the UI, for example by appending the `version` | |
170 | field. This field is optional. | |
7bb36d2d ZJS |
171 | |
172 | Example: `title Fedora 18 (Spherical Cow)` | |
173 | ||
174 | * `version` is a human-readable version for this menu item. This is usually the | |
175 | kernel version and is intended for use by OSes to install multiple kernel | |
176 | versions with the same `title` field. This field shall be in a syntax that is | |
177 | useful for Debian-style version sorts, so that the boot loader UI can | |
178 | determine the newest version easily and show it first or preselect it | |
179 | automatically. This field is optional. | |
180 | ||
181 | Example: `version 3.7.2-201.fc18.x86_64` | |
182 | ||
183 | * `machine-id` is the machine ID of the OS. This can be used by boot loaders | |
184 | and applications to filter out boot entries, for example to show only a | |
185 | single newest kernel per OS, to group items by OS, or to filter out the | |
186 | currently booted OS when showing only other installed operating systems. | |
187 | This ID shall be formatted as 32 lower case hexadecimal characters | |
188 | (i.e. without any UUID formatting). This key is optional. | |
189 | ||
190 | Example: `machine-id 4098b3f648d74c13b1f04ccfba7798e8` | |
191 | ||
192 | * `sort-key` is a short string used for sorting entries on display. This should | |
193 | typically be initialized from the `IMAGE_ID=` or `ID=` fields of | |
14bacc74 ZJS |
194 | [os-release](https://www.freedesktop.org/software/systemd/man/os-release.html), |
195 | possibly with an additional suffix. This field is optional. If set, it is | |
196 | used as primary sorting key for the entries on display (lexicographically | |
197 | increasing). It does not have to be unique (and usually is not). If | |
198 | non-unique the the `machine-id` (lexicographically increasing) and `version` | |
199 | (lexicographically decreasing, i.e. newest version first) fields described | |
200 | above are used as secondary/ternary sorting keys. If this field is not set | |
201 | entries are typically sorted by the `.conf` file name of the entry. | |
7bb36d2d ZJS |
202 | |
203 | Example: `sort-key fedora` | |
204 | ||
205 | * `linux` is the Linux kernel to spawn and as a path relative to `$BOOT`. It | |
206 | is recommended that every distribution creates a machine id and version | |
207 | specific subdirectory below `$BOOT` and places its kernels and initial RAM | |
208 | disk images there. | |
209 | ||
210 | Example: `linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux` | |
211 | ||
212 | * `initrd` is the initrd to use when executing the kernel. This also | |
49d5e4d0 LP |
213 | shall be a path relative to `$BOOT`. This key is optional. This key may |
214 | appear more than once in which case all specified images are used, in the | |
7bb36d2d ZJS |
215 | order they are listed. |
216 | ||
217 | Example: `initrd 6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd` | |
218 | ||
49d5e4d0 LP |
219 | * `efi` refers to an arbitrary EFI program. This also takes a path relative to |
220 | `$BOOT`. If this key is set, and the system is not an EFI system this entry | |
221 | should be hidden. | |
7bb36d2d | 222 | |
49d5e4d0 LP |
223 | * `options` shall contain kernel parameters to pass to the Linux kernel to |
224 | spawn. This key is optional and may appear more than once in which case all | |
225 | specified parameters are used in the order they are listed. | |
7bb36d2d ZJS |
226 | |
227 | Example: `options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2 quiet` | |
228 | ||
c3c5eeca | 229 | * `devicetree` refers to the binary device tree to use when executing the |
49d5e4d0 | 230 | kernel. This also shall be a path relative to `$BOOT`. This key is |
7bb36d2d ZJS |
231 | optional. |
232 | ||
233 | Example: `devicetree 6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.armv7hl/tegra20-paz00.dtb` | |
234 | ||
09ee387e | 235 | * `devicetree-overlay` refers to a list of device tree overlays that should be |
49d5e4d0 LP |
236 | applied by the boot loader. Multiple overlays are separated by spaces and |
237 | applied in the same order as they are listed. This key is optional but | |
7bb36d2d ZJS |
238 | depends on the `devicetree` key. |
239 | ||
240 | Example: `devicetree-overlay /6a9857a393724b7a981ebb5b8495b9ea/overlays/overlay_A.dtbo /6a9857a393724b7a981ebb5b8495b9ea/overlays/overlay_B.dtbo` | |
241 | ||
242 | * `architecture` refers to the architecture this entry is for. The argument | |
243 | should be an architecture identifier, using the architecture vocabulary | |
244 | defined by the EFI specification (i.e. `IA32`, `x64`, `IA64`, `ARM`, `AA64`, | |
245 | …). If specified and it does not match the local system architecture this | |
246 | entry should be hidden. The comparison should be done case-insensitively. | |
247 | ||
248 | Example: `architecture aa64` | |
49d5e4d0 LP |
249 | |
250 | Each configuration drop-in snippet must include at least a `linux` or an `efi` | |
7bb36d2d | 251 | key. Here is an example for a complete drop-in file: |
c3c5eeca | 252 | |
6e6b351b | 253 | # /boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf |
bdc4c7ac | 254 | title Fedora 19 (Rawhide) |
10119357 | 255 | sort-key fedora |
bdc4c7ac | 256 | machine-id 6a9857a393724b7a981ebb5b8495b9ea |
10119357 | 257 | version 3.8.0-2.fc19.x86_64 |
7bb36d2d | 258 | options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2 quiet |
bdc4c7ac LP |
259 | architecture x64 |
260 | linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux | |
261 | initrd /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd | |
c3c5eeca | 262 | |
e178b335 LP |
263 | On EFI systems all Linux kernel images should be EFI images. In order to |
264 | increase compatibility with EFI systems it is highly recommended only to | |
265 | install EFI kernel images, even on non-EFI systems, if that's applicable and | |
266 | supported on the specific architecture. | |
267 | ||
268 | Conversely, in order to increase compatibility it is recommended to install | |
269 | generic kernel images that make few assumptions about the firmware they run on, | |
270 | i.e. it is a good idea that both images shipped as UEFI PE images and those | |
271 | which are not don't make unnecessary assumption on the underlying firmware, | |
272 | i.e. don't hard depend on legacy BIOS calls or UEFI boot services. | |
c3c5eeca | 273 | |
0f5a416c ZJS |
274 | When Type #1 configuration snippets refer to other files (for `linux`, |
275 | `initrd`, `efi`, `devicetree`, and `devicetree-overlay`), those files must be | |
276 | located on the same partition. The naming of those files can be chosen by | |
277 | the installer. A recommended scheme is described in the next section. | |
278 | ||
279 | ### Recommended Directory Layout for Additional Files | |
280 | ||
281 | It is recommened to place the kernel and other other files comprising a single | |
282 | boot loader entry in a separate directory: | |
283 | `/<entry-token-or-machine-id>/<version>/`. This naming scheme uses the same | |
284 | elements as the boot loader configuration snippet, providing the same level of | |
285 | uniqueness. | |
286 | ||
287 | Example: `$BOOT/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux` | |
288 | `$BOOT/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd` | |
289 | ||
290 | Other naming schemes are possible. In particular, traditionally a flat naming | |
291 | scheme with files in the root directory was used. This is not recommended | |
292 | because it is hard to avoid conflicts in a multi-boot installation. | |
c3c5eeca | 293 | |
7bb36d2d ZJS |
294 | ### Standard-conformance Marker File |
295 | ||
f6ad0282 | 296 | Unfortunately, there are implementations of boot loading infrastructure that |
7bb36d2d ZJS |
297 | are also using the `/loader/entries/` directory, but installing files that do |
298 | not follow this specification. In order to minimize confusion, a boot loader | |
299 | implementation may place the file `/loader/entries.srel` next to the | |
300 | `/loader/entries/` directory containing the ASCII string `type1` (followed by a | |
301 | UNIX newline). Tools that need to determine whether an existing directory | |
302 | implements the semantics described here may check for this file and contents: | |
303 | if it exists and contains the mentioned string, it shall assume a | |
304 | standards-compliant implementation is in place. If it exists but contains a | |
305 | different string it shall assume other semantics are implemented. If the file | |
306 | does not exist, no assumptions should be made. | |
f6ad0282 | 307 | |
084a8029 LP |
308 | ### Type #2 EFI Unified Kernel Images |
309 | ||
310 | A unified kernel image is a single EFI PE executable combining an EFI stub | |
311 | loader, a kernel image, an initramfs image, and the kernel command line. See | |
312 | the description of the `--uefi` option in | |
313 | [dracut(8)](http://man7.org/linux/man-pages/man8/dracut.8.html). Such unified | |
7bb36d2d | 314 | images are installed in the`$BOOT/EFI/Linux/` directory and must have the |
084a8029 LP |
315 | extension `.efi`. Support for images of this type is of course specific to |
316 | systems with EFI firmware. Ignore this section if you work on systems not | |
317 | supporting EFI. | |
5be7bfbc | 318 | |
d9067aba | 319 | Type #2 file names should be chosen from the same restricted character set as |
7bb36d2d ZJS |
320 | Type #1 described above (but with the file name suffix of `.efi` instead of |
321 | `.conf`). | |
d9067aba | 322 | |
084a8029 | 323 | Images of this type have the advantage that all metadata and payload that makes |
7bb36d2d | 324 | up the boot entry is contained in a single PE file that can be signed |
084a8029 | 325 | cryptographically as one for the purpose of EFI SecureBoot. |
5be7bfbc ZJS |
326 | |
327 | A valid unified kernel image must contain two PE sections: | |
328 | ||
7bb36d2d | 329 | * `.cmdline` section with the kernel command line, |
49d5e4d0 LP |
330 | * `.osrel` section with an embedded copy of the |
331 | [os-release](https://www.freedesktop.org/software/systemd/man/os-release.html) | |
7bb36d2d | 332 | file describing the image. |
889cb0ab | 333 | |
7bb36d2d ZJS |
334 | The `PRETTY_NAME=` and `VERSION_ID=` fields in the embedded `os-release` file |
335 | are used the same as `title` and `version` in the Type #1 entries. The | |
336 | `.cmdline` section is used instead of the `options` field. `linux` and `initrd` | |
337 | fields are not necessary, and there is no counterpart for the `machine-id` | |
338 | field. | |
5be7bfbc | 339 | |
084a8029 | 340 | On EFI, any such images shall be added to the list of valid boot entries. |
5be7bfbc ZJS |
341 | |
342 | ### Additional notes | |
343 | ||
49d5e4d0 LP |
344 | Note that these configurations snippets do not need to be the only |
345 | configuration source for a boot loader. It may extend this list of entries with | |
346 | additional items from other configuration files (for example its own native | |
347 | configuration files) or automatically detected other entries without explicit | |
348 | configuration. | |
5be7bfbc | 349 | |
49d5e4d0 LP |
350 | To make this explicitly clear: this specification is designed with "free" |
351 | operating systems in mind, starting Windows or macOS is out of focus with these | |
352 | configuration snippets, use boot-loader specific solutions for that. In the | |
353 | text above, if we say "OS" we hence imply "free", i.e. primarily Linux (though | |
354 | this could be easily be extended to the BSDs and whatnot). | |
c3c5eeca | 355 | |
49d5e4d0 LP |
356 | Note that all paths used in the configuration snippets use a Unix-style "/" as |
357 | path separator. This needs to be converted to an EFI-style "\\" separator in | |
358 | EFI boot loaders. | |
c3c5eeca LP |
359 | |
360 | ||
7bb36d2d | 361 | ## Locating boot entries |
c3c5eeca | 362 | |
7bb36d2d ZJS |
363 | A _boot loader_ locates `$BOOT`, then simply reads all files |
364 | `$BOOT/loader/entries/*.conf`, and populates its boot menu with this. On EFI, | |
365 | it then extends this with any unified kernel images found in | |
366 | `$BOOT/EFI/Linux/*.efi`. It may also add additional entries, for example a | |
367 | "Reboot into firmware" option. Optionally it may sort the menu based on the | |
368 | `sort-key`, `machine-id` and `version` fields, and possibly others. It uses the | |
369 | file name to identify specific items, for example in case it supports storing | |
370 | away default entry information somewhere. A boot loader should generally not | |
371 | modify these files. | |
084a8029 LP |
372 | |
373 | For "Boot Loader Specification Entries" (Type #1), the _kernel package | |
374 | installer_ installs the kernel and initrd images to `$BOOT` (it is recommended | |
375 | to place these files in a vendor and OS and installation specific directory) | |
376 | and then generates a configuration snippet for it, placing this in | |
7bb36d2d ZJS |
377 | `$BOOT/loader/entries/xyz.conf`, with "xyz" as concatenation of machine id and |
378 | version information (see above). The files created by a kernel package are tied | |
379 | to the kernel package and should be removed along with it. | |
084a8029 LP |
380 | |
381 | For "EFI Unified Kernel Images" (Type #2), the vendor or kernel package | |
7bb36d2d ZJS |
382 | installer should create the combined image and drop it into |
383 | `$BOOT/EFI/Linux/`. This file is also tied to the kernel package and should be | |
384 | removed along with it. | |
c3c5eeca | 385 | |
49d5e4d0 | 386 | A _UI application_ intended to show available boot options shall operate |
7bb36d2d ZJS |
387 | similarly to a boot loader, but might apply additional filters, for example by |
388 | filtering the booted OS via the machine ID, or by suppressing all but the | |
49d5e4d0 | 389 | newest kernel versions. |
c3c5eeca | 390 | |
49d5e4d0 | 391 | An _OS installer_ picks the right place for `$BOOT` as defined above (possibly |
7bb36d2d ZJS |
392 | creating a partition and file system for it) and creates the `/loader/entries/` |
393 | directory in it. It then installs an appropriate boot loader that can read | |
394 | these snippets. Finally, it installs one or more kernel packages. | |
395 | ||
396 | ||
397 | ## Additional discussion | |
398 | ||
399 | ### Why is there a need for this specification? | |
400 | ||
401 | This specification brings the following advantages: | |
402 | ||
403 | * Installation of new boot entries is more robust, as no explicit rewriting of | |
404 | configuration files is required. | |
405 | ||
406 | * It allows an out-of-the-box boot experience on any platform without the need | |
407 | of traditional firmware mechanisms (e.g. BIOS calls, UEFI Boot Services). | |
408 | ||
409 | * It improves dual-boot scenarios. Without cooperation, multiple Linux | |
410 | installations tend to fight over which boot loader becomes the primary one in | |
411 | possession of the MBR or the boot partition, and only that one installation | |
412 | can then update the boot loader configuration. Other Linux installs have to | |
413 | be manually configured to never touch the MBR and instead install a | |
414 | chain-loaded boot loader in their own partition headers. In this new scheme | |
415 | all installations share a loader directory and no manual configuration has to | |
416 | take place. All participants implicitly cooperate due to removal of name | |
417 | collisions and can install/remove their own boot menu entries without | |
418 | interfering with the entries of other installed operating systems. | |
419 | ||
420 | * Drop-in directories are now pretty ubiquitous on Linux as an easy way to | |
421 | extend configuration without having to edit, regenerate or manipulate | |
422 | configuration files. For the sake of uniformity, we should do the same for | |
423 | the boot menu. | |
424 | ||
425 | * Userspace code can sanely parse boot loader configuration which is essential | |
426 | with modern firmware which does not necessarily initialize USB keyboards | |
427 | during boot, which makes boot menus hard to reach for the user. If userspace | |
428 | code can parse the boot loader configuration too, UI can be written that | |
429 | select a boot menu item to boot into before rebooting the machine, thus not | |
430 | requiring interactivity during early boot. | |
431 | ||
432 | * To unify and thus simplify configuration of the various boot loaders, which | |
433 | makes configuration of the boot loading process easier for users, | |
434 | administrators, and developers alike. | |
435 | ||
436 | * For boot loaders with configuration _scripts_ such as grub2, adopting this | |
437 | spec allows for mostly static scripts that are generated only once at first | |
438 | installation, but then do not need to be updated anymore as that is done via | |
439 | drop-in files exclusively. | |
440 | ||
441 | ### Why not simply rely on the EFI boot menu logic? | |
c3c5eeca | 442 | |
7bb36d2d ZJS |
443 | EFI is not ubiquitous, especially not in embedded systems. But even on systems |
444 | with EFI, which provides a boot options logic that can offer similar | |
445 | functionality, this specfication is still needed for the following reasons: | |
c3c5eeca | 446 | |
7bb36d2d ZJS |
447 | * The various EFI implementations implement the boot order/boot item logic to |
448 | different levels. Some firmware implementations do not offer a boot menu at | |
449 | all and instead unconditionally follow the EFI boot order, booting the first | |
450 | item that is working. | |
451 | ||
452 | * If the firmware setup is used to reset data, usually all EFI boot entries | |
453 | are lost, making the system entirely unbootable, as the firmware setups | |
454 | generally do not offer a UI to define additional boot items. By placing the | |
455 | menu item information on disk, it is always available, even if the firmware | |
456 | configuration is lost. | |
457 | ||
458 | * Harddisk images should be movable between machines and be bootable without | |
459 | requiring firmare configuration. This also requires that the list | |
460 | of boot options is defined on disk, and not in EFI variables alone. | |
461 | ||
462 | * EFI is not universal yet (especially on non-x86 platforms), this | |
463 | specification is useful both for EFI and non-EFI boot loaders. | |
464 | ||
465 | * Many EFI systems disable USB support during early boot to optimize boot | |
466 | times, thus making keyboard input unavailable in the EFI menu. It is thus | |
467 | useful if the OS UI has a standardized way to discover available boot options | |
468 | which can be booted to. | |
469 | ||
470 | ### Out of Focus | |
c3c5eeca | 471 | |
7957e55d | 472 | There are a couple of items that are out of focus for this specification: |
c3c5eeca | 473 | |
49d5e4d0 LP |
474 | * If userspace can figure out the available boot options, then this is only |
475 | useful so much: we'd still need to come up with a way how userspace could | |
476 | communicate to the boot loader the default boot loader entry temporarily or | |
477 | persistently. Defining a common scheme for this is certainly a good idea, but | |
478 | out of focus for this specification. | |
7bb36d2d | 479 | |
49d5e4d0 LP |
480 | * This specification is just about "Free" Operating systems. Hooking in other |
481 | operating systems (like Windows and macOS) into the boot menu is a different | |
482 | story and should probably happen outside of this specification. For example, | |
483 | boot loaders might choose to detect other available OSes dynamically at | |
484 | runtime without explicit configuration (like `systemd-boot` does it), or via | |
485 | native configuration (for example via explicit Grub2 configuration generated | |
486 | once at installation). | |
7bb36d2d | 487 | |
49d5e4d0 LP |
488 | * This specification leaves undefined what to do about systems which are |
489 | upgraded from an OS that does not implement this specification. As the | |
490 | previous boot loader logic was largely handled by in distribution-specific | |
491 | ways we probably should leave the upgrade path (and whether there actually is | |
492 | one) to the distributions. The simplest solution might be to simply continue | |
493 | with the old scheme for old installations and use this new scheme only for | |
494 | new installations. | |
c3c5eeca | 495 | |
0f5a416c ZJS |
496 | * Referencing kernels or initrds on other partitions other than the partition |
497 | containing the Type #1 boot loader entry. This is by design, as specifying | |
498 | other partitions or devices would require a non-trivial language for denoting | |
499 | device paths. In particular this means that on non-EFI systems configuration | |
500 | snippets following this specification cannot be used to spawn other operating | |
501 | systems (such as Windows). | |
502 | ||
c3c5eeca LP |
503 | |
504 | ## Links | |
505 | ||
b0cda241 | 506 | [GUID Partition Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)<br> |
5c90c67a BF |
507 | [Boot Loader Interface](BOOT_LOADER_INTERFACE.md)<br> |
508 | [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br> | |
a43d2229 LP |
509 | [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br> |
510 | [`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br> | |
511 | [`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html) |