Lines Matching refs:this

13 setups. We'd like to improve this situation by getting everybody to commit to a
23 firmware includes a boot loader. The target audience for this specification is:
36 ## Why is there a need for this specification?
38 Of course, without this specification things already work mostly fine. But here's why we think this…
49   loader in their own partition headers. In this new scheme as all
61   code can parse the boot loader configuration, too, this allows for UIs that
67 * For boot loaders with configuration _scripts_ such as grub2, adopting this
90 * EFI is not universal yet (especially on non-x86 platforms), this
161 this specification. This specification only defines semantics of the `/loader/`
164 other software implementing this specification may choose to place other
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
214 * `title` shall contain a human readable title string for this menu item. This
216   initialize this from the `PRETTY_NAME` of `/etc/os-release`. This name should
221 * `version` shall contain a human readable version string for this menu
243   secondary/ternary sorting keys. If this field is not set entries are
256   `$BOOT`. If this key is set, and the system is not an EFI system this entry
271 * `architecture` refers to the architecture this entry is defined for. The
274   `ARM`, `AA64`, …). If specified and this does not match (case insensitively)
275   the local system architecture this entry should be hidden.
306 read from other partitions/disks the boot loader can do this in its own native
307 configuration, using its own specific device path language, and this is out of
308 focus for this specification. More specifically, on non-EFI systems
309 configuration snippets following this specification cannot be used to spawn
314 not valid by this specification. In order to minimize confusion a boot loader
318 directory implements the semantics described here may check for this file and
331 extension `.efi`. Support for images of this type is of course specific to
332 systems with EFI firmware. Ignore this section if you work on systems not
339 Images of this type have the advantage that all metadata and payload that makes
361 configuration source for a boot loader. It may extend this list of entries with
366 To make this explicitly clear: this specification is designed with "free"
370 this could be easily be extended to the BSDs and whatnot).
381 menu with this. On EFI, it then extends this with any unified kernel images
392 and then generates a configuration snippet for it, placing this in
415 There are a couple of items that are out of focus for this specification:
417 * If userspace can figure out the available boot options, then this is only
420   persistently. Defining a common scheme for this is certainly a good idea, but
421   out of focus for this specification.
424   story and should probably happen outside of this specification. For example,
430   upgraded from an OS that does not implement this specification. As the
434   with the old scheme for old installations and use this new scheme only for