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