diff options
| author | Lennart Poettering <lennart@poettering.net> | 2022-03-17 18:35:53 +0100 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2022-03-22 00:34:33 +0100 |
| commit | f6ad0282c9b9260076e74195e35a4c0c278537c7 (patch) | |
| tree | 16627a3ea0d1782825c0ae407e2bddde63b90e6a /docs | |
| parent | ffc97a1cc4d3ebf7ca68c15567f60e9e8c27d85e (diff) | |
| download | systemd-f6ad0282c9b9260076e74195e35a4c0c278537c7.tar.gz | |
docs: add /loader/entries.srel to the boot loader spec
This new file is supposed to address conflicts with Fedora/Grub's
frankenbootloaderspec implementation, that squatted the /loader/entries/
dir, but place incompatible files in them (that do variable expansion?).
A simple text file /loader/entries.srel shall indicate which spec is
implemented. If it contains the string "type1\n" then the
/loader/entries/ directory implements our standard spec, otherwise
something else.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/BOOT_LOADER_SPECIFICATION.md | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/docs/BOOT_LOADER_SPECIFICATION.md b/docs/BOOT_LOADER_SPECIFICATION.md index 7f15a23164..375efeb1d1 100644 --- a/docs/BOOT_LOADER_SPECIFICATION.md +++ b/docs/BOOT_LOADER_SPECIFICATION.md @@ -309,6 +309,18 @@ focus for this specification. More specifically, on non-EFI systems configuration snippets following this specification cannot be used to spawn other operating systems (such as Windows). +Unfortunately, there are implementations of boot loading infrastructure that +are also using the /loader/entries/ directory, but place files in them that are +not valid by this specification. In order to minimize confusion a boot loader +implementation may place a file /loader/entries.srel next to the +/loader/entries/ directory containing the ASCII string "type1" (suffixed +with a UNIX newline). Tools that need to determine whether an existing +directory implements the semantics described here may check for this file and +contents: if it exists and contains the mentioned string, it shall assume a +standards compliant implementation is in place. If it exists but contains a +different string it shall assume non-standard semantics are implemented. If the +file 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 |