Lines Matching refs:and
10 _TL;DR: Currently there's no common boot scheme across architectures and
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
21 between various boot loader implementations, operating systems, and userspace
29 * Distribution and Core OS developers, in order to create these snippets at
33 * OS Installer developers, to prepare their installation media and for setting
46 MBR, and only that one installation can then update the boot loader
48 configured to never touch the MBR and instead install a chain-loaded boot
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,
64 * To unify and thus simplify configuration of the various boot loaders around,
66 administrators and developers alike.
80 all and instead unconditionally follow the EFI boot order, booting the first
87 * Harddisk images should be movable between machines and be bootable without
89 of boot options is defined on disk, and not in EFI variables alone.
91 specification is useful both for EFI and non-EFI boot loaders.
103 * If the OS is installed on a disk with an MBR partition table, and a
108 (let's say 500MB), and it should be used as `$BOOT`.
110 * If the OS is installed on a disk with GPT, and an Extended Boot Loader
114 * Otherwise, if the OS is installed on a disk with GPT, and an EFI System
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
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
126 and an fstab entry may be created. It should be mounted to either `/boot/` or
129 because the mounting of `$BOOT` is then dependent on and requires the mounting
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
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
152 entries that use the `efi` key and all Type #2 entries only apply to EFI
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
163 ownership of the whole file system exclusively. Boot loaders, firmware, and
165 files and directories in the same file system. For example, boot loaders that
187 ESP, and not in the `/EFI/` subdirectory._
196 `/etc/machine-id`), the kernel version (as returned by `uname -r`) and an OS
200 In order to maximize compatibility with file system implementations and
201 restricted boot loader environments, and to minimize conflicting character use
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
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
217 be descriptive and does not have to be unique. If a boot loader discovers two
222 item. This is usually the kernel version and is intended for use by OSes to
226 easily and show it first or preselect it automatically. This field is
229 is useful for boot loaders and applications to filter out boot entries, for
240 does not have to be unique (and usually is not). If non-unique the the
241 `machine-id` (lexicographically increasing) and `version` (lexicographically
245 * `linux` refers to the Linux kernel to spawn and shall be a path relative to
246 `$BOOT`. It is recommended that every distribution creates a machine id and
247 version specific subdirectory below `$BOOT` and places its kernels and
256 `$BOOT`. If this key is set, and the system is not an EFI system this entry
259 spawn. This key is optional and may appear more than once in which case all
266 applied by the boot loader. Multiple overlays are separated by spaces and
274 `ARM`, `AA64`, …). If specified and this does not match (case insensitively)
278 key and is otherwise not valid. Here's an example for a complete drop-in file:
292 install EFI kernel images, even on non-EFI systems, if that's applicable and
297 i.e. it is a good idea that both images shipped as UEFI PE images and those
301 Note that these configuration snippets may only reference kernels (and EFI
307 configuration, using its own specific device path language, and this is out of
318 directory implements the semantics described here may check for this file and
319 contents: if it exists and contains the mentioned string, it shall assume a
327 loader, a kernel image, an initramfs image, and the kernel command line. See
330 images will be searched for under `$BOOT/EFI/Linux/` and must have the
339 Images of this type have the advantage that all metadata and payload that makes
350 The `PRETTY_NAME=` and `VERSION_ID=` fields in the embedded os-release file are
351 used the same as `title` and `version` in the "boot loader specification"
353 and `initrd` fields are not necessary, and there is no counterpart for the
370 this could be easily be extended to the BSDs and whatnot).
379 A _boot loader_ needs a file system driver to discover and read `$BOOT`, then
380 simply reads all files `$BOOT/loader/entries/*.conf`, and populates its boot
384 on the `sort-key`, `machine-id` and `version` fields, and possibly others. It
390 installer_ installs the kernel and initrd images to `$BOOT` (it is recommended
391 to place these files in a vendor and OS and installation specific directory)
392 and then generates a configuration snippet for it, placing this in
393 `$BOOT/loader/entries/xyz.conf`, with xyz as concatenation of machine id and
395 private property of the kernel package and should be removed along with it.
398 installer creates the combined image and drops it into `$BOOT/EFI/Linux/`. This
399 file is also private property of the kernel package and should be removed along
408 creating a partition and file system for it) and pre-creates the
423 operating systems (like Windows and macOS) into the boot menu is a different
424 story and should probably happen outside of this specification. For example,
432 ways we probably should leave the upgrade path (and whether there actually is
434 with the old scheme for old installations and use this new scheme only for