Merge pull request #25379 from keszybz/update-doc-links

Update doc links

6 files changed, 34 insertions, 32 deletions

diff --git a/docs/AUTOMATIC_BOOT_ASSESSMENT.md b/docs/AUTOMATIC_BOOT_ASSESSMENT.md
index c2a53f48dc..91e2c5b094 100644
--- a/docs/AUTOMATIC_BOOT_ASSESSMENT.md
+++ b/docs/AUTOMATIC_BOOT_ASSESSMENT.md
@@ -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`).
diff --git a/docs/BOOT_LOADER_INTERFACE.md b/docs/BOOT_LOADER_INTERFACE.md
index 5be4d1ad17..267fcc55a0 100644
--- a/docs/BOOT_LOADER_INTERFACE.md
+++ b/docs/BOOT_LOADER_INTERFACE.md
@@ -112,10 +112,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/)
+   files, the identifier should be derived directly from the file name,
+   but with the `.conf` (Type #1 snippets) or `.efi` (Type #2 images)
+   suffix removed.
 
 2. Entries automatically discovered by the boot loader (as opposed to being
    configured in configuration files) should generally have an identifier
@@ -128,7 +129,7 @@ names for them in UIs.
    discovered Windows installation might have the identifier `auto-windows` or
    `auto-windows-10` or so.).
 
-4. Similar, boot menu entries referring to Apple macOS installations should
+4. Similarly, boot menu entries referring to Apple macOS installations should
    use the identifier `osx` or one that is prefixed with `osx-`. If such an
    entry is automatically discovered by the boot loader use `auto-osx` as
    identifier, or `auto-osx-` as prefix for the identifier, see above.
@@ -143,8 +144,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)
diff --git a/docs/BUILDING_IMAGES.md b/docs/BUILDING_IMAGES.md
index 955dd90e55..1a96ed0083 100644
--- a/docs/BUILDING_IMAGES.md
+++ b/docs/BUILDING_IMAGES.md
@@ -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>
diff --git a/docs/ENVIRONMENT.md b/docs/ENVIRONMENT.md
index b4aaf10100..32bd9598b7 100644
--- a/docs/ENVIRONMENT.md
+++ b/docs/ENVIRONMENT.md
@@ -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.
diff --git a/docs/PORTABLE_SERVICES.md b/docs/PORTABLE_SERVICES.md
index 4f02ddb477..7a9c7f512d 100644
--- a/docs/PORTABLE_SERVICES.md
+++ b/docs/PORTABLE_SERVICES.md
@@ -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,
diff --git a/docs/PORTING_TO_NEW_ARCHITECTURES.md b/docs/PORTING_TO_NEW_ARCHITECTURES.md
index 5c61481486..1038336010 100644
--- a/docs/PORTING_TO_NEW_ARCHITECTURES.md
+++ b/docs/PORTING_TO_NEW_ARCHITECTURES.md
@@ -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