tree-wide: BLS and DPS are now on uapi-group website

2022-11-21 12:26:35 +01:00
parent 244c2a8344
commit db81144428
28 changed files with 88 additions and 85 deletions
@@ -9,7 +9,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later

 systemd provides support for automatically reverting back to the previous
 version of the OS or kernel in case the system consistently fails to boot. The
-[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md#boot-counting)
+[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting)
 describes how to annotate boot loader entries with a counter that specifies how
 many attempts should be made to boot it. This document describes how systemd
 implements this scheme.
@@ -28,7 +28,7 @@ Here's a brief overview of the complete set of components:
 * The
  [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
  boot loader optionally maintains a per-boot-loader-entry counter described by
-  the [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md#boot-counting)
+  the [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting)
  that is decreased by one on each attempt to boot the entry, prioritizing
  entries that have non-zero counters over those which already reached a
  counter of zero when choosing the entry to boot.
@@ -60,7 +60,8 @@ Here's a brief overview of the complete set of components:

 ## Details

-As described in [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md#boot-counting),
+As described in the
+[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting),
 the boot counting data is stored in the file name of the boot loader entries as
 a plus (`+`), followed by a number, optionally followed by `-` and another
 number, right before the file name suffix (`.conf` or `.efi`).
@@ -119,10 +119,11 @@ the identifiers as passed in `LoaderEntries`, `LoaderEntryDefault`,
 `LoaderEntryOneShot`, `LoaderEntrySelected`, and possibly show nicely localized
 names for them in UIs.

-1. When boot loader entries are defined through
-   [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md) drop-in files
-   the identifier should be derived directly from the drop-in snippet name, but
-   with the `.conf` (or `.efi` in case of Type #2 entries) suffix removed.
+1. When boot loader entries are defined through the
+   [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/)
+   drop-in files the identifier should be derived directly from the drop-in
+   snippet name, but with the `.conf` (or `.efi` in case of Type #2 entries)
+   suffix removed.

 2. Entries automatically discovered by the boot loader (as opposed to being
   configured in configuration files) should generally have an identifier
@@ -150,8 +151,8 @@ names for them in UIs.

 ## Links

-[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md)<br>
-[Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br>
+[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)<br>
+[Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)<br>
 [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
 [`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
 [`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
@@ -67,14 +67,14 @@ boot. For that it's essential to:
 The
 [`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
 logic used to generate
-[Boot Loader Specification Type 1](BOOT_LOADER_SPECIFICATION.md) entries by
-default uses the machine ID as stored in `/etc/machine-id` for naming boot menu
-entries and the directories in the ESP to place kernel images in. This is done
-in order to allow multiple installations of the same OS on the same system
-without conflicts. However, this is problematic if the machine ID shall be
-generated automatically on first boot: if the ID is not known before the first
-boot it cannot be used to name the most basic resources required for the boot
-process to complete.
+[Boot Loader Specification Type #1](https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-specification-entries)
+entries by default uses the machine ID as stored in `/etc/machine-id` for
+naming boot menu entries and the directories in the ESP to place kernel images
+in. This is done in order to allow multiple installations of the same OS on the
+same system without conflicts. However, this is problematic if the machine ID
+shall be generated automatically on first boot: if the ID is not known before
+the first boot it cannot be used to name the most basic resources required for
+the boot process to complete.

 Thus, for images that shall acquire their identity on first boot only, it is
 required to use a different identifier for naming boot menu entries. To allow
@@ -203,8 +203,8 @@ it, then format it.
   in. The `x-systemd.growfs` mount option in `/etc/fstab` is sufficient to
   enable this logic for specific mounts. Alternatively appropriately set up
   partitions can set GPT partition flag 59 to request this behaviour, see the
-   [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md) for
-   details. If the file system is already grown it executes no operation.
+   [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)
+   for details. If the file system is already grown it executes no operation.

 3. Similar, the `systemd-makefs@.service` and `systemd-makeswap@.service`
   services can format file systems and swap spaces before first use, if they
@@ -267,8 +267,8 @@ fields.
 [`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html)<br>
 [`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)<br>
 [`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html)<br>
-[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md)<br>
-[Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br>
+[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)<br>
+[Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)<br>
 [`mkosi`](https://github.com/systemd/mkosi)<br>
 [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
 [`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)<br>
@@ -188,12 +188,12 @@ All tools:
  file may be checked for by services run during system shutdown in order to
  request the appropriate operation from the boot loader in an alternative
  fashion. Note that by default only boot loader entries which follow the
-  [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md) and are
-  placed in the ESP or the Extended Boot Loader partition may be selected this
-  way. However, if a directory `/run/boot-loader-entries/` exists, the entries
-  are loaded from there instead. The directory should contain the usual
-  directory hierarchy mandated by the Boot Loader Specification, i.e. the entry
-  drop-ins should be placed in
+  [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)
+  and are placed in the ESP or the Extended Boot Loader partition may be
+  selected this way. However, if a directory `/run/boot-loader-entries/`
+  exists, the entries are loaded from there instead. The directory should
+  contain the usual directory hierarchy mandated by the Boot Loader
+  Specification, i.e. the entry drop-ins should be placed in
  `/run/boot-loader-entries/loader/entries/*.conf`, and the files referenced by
  the drop-ins (including the kernels and initrds) somewhere else below
  `/run/boot-loader-entries/`. Note that all these files may be (and are
@@ -384,7 +384,7 @@ disk images with `--image=` or similar:
  to load the embedded Verity signature data. If enabled (which is the
  default), Verity root hash information and a suitable signature is
  automatically acquired from a signature partition, following the
-  [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md).
+  [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification).
  If disabled any such partition is ignored. Note that this only disables
  discovery of the root hash and its signature, the Verity data partition
  itself is still searched in the GPT image.
@@ -169,7 +169,7 @@ requirements are made for an image that can be attached/detached with
   an image with a partition table understood by the Linux kernel with only a
   single partition defined, or alternatively, a GPT partition table with a set
   of properly marked partitions following the
-   [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md).
+   [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification).

 3. The image must at least contain one matching unit file, with the right name
   prefix and suffix (see above). The unit file is searched in the usual paths,
@@ -27,8 +27,8 @@ architecture.
   partitions. Use `systemd-id128 new -p` to generate new suitable UUIDs you
   can use for this. Make sure to register your new types in the various
   functions in `gpt.c`. Also make sure to update the tables in
-   `docs/DISCOVERABLE_PARTITIONS.md` and `man/systemd-gpt-auto-generator.xml`
-   accordingly.
+   [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)
+   and `man/systemd-gpt-auto-generator.xml` accordingly.

 3. If your architecture supports UEFI, make sure to update the `efi_arch`
   variable logic in `meson.build` to be set to the right architecture string