Minor docs cleanups (#37439)

This commit is contained in:
Luca Boccassi
2025-05-14 17:16:05 +01:00
committed by GitHub
3 changed files with 8 additions and 8 deletions

View File

@@ -52,7 +52,7 @@ variables. All EFI variables use the vendor UUID
be used to let the OS know which boot menu entries were discovered by the
boot loader. A boot loader entry identifier should be a short, non-empty
alphanumeric string (possibly containing `-`, too). The list should be in the
order the entries are shown on screen during boot. See below regarding a
order the entries are shown on screen during boot. See below regarding the
recommended vocabulary for boot loader entry identifiers.
* The EFI variable `LoaderEntryDefault` contains the default boot loader entry
@@ -62,13 +62,13 @@ variables. All EFI variables use the vendor UUID
used in case of a system failure. System failure (SysFail) boot entries can
optionally modify the automatic selection order in the event of a failure,
such as a boot firmware update failure with the failure status recorded in
the EFI system table. If a system failure occurs and `LoaderEntrySysFail` is set,
systemd-boot will use this boot entry and store the actual SysFail reason in
the `LoaderSysFailReason` EFI variable.
the EFI system table. If a system failure occurs and `LoaderEntrySysFail` is
set, systemd-boot will use this boot entry, and store the actual SysFail
reason in the `LoaderSysFailReason` EFI variable.
* The EFI variable `LoaderSysFailReason` contains the system failure reason.
This variable is used in cooperation with `LoaderEntrySysFail` boot entry.
If system failure doesn't occur `LoaderSysFailReason` is not set at all.
If system failure doesn't occur, `LoaderSysFailReason` is not set.
* Similarly, the EFI variable `LoaderEntryOneShot` contains the default boot
loader entry to use for a single following boot. It is set by the OS in order

View File

@@ -23,7 +23,7 @@ or the shadow structure `struct sgrp`'s `sg_namp` field.
`uuid` -> A string containing a lowercase UUID that identifies this group.
The same considerations apply to this field as they do to the corresponding field of user records.
Users and groups MUST NOT share the same UUID unless they are semantically
the same security principal e.g. if a system synthesizes a single-user group from
the same security principal, e.g. if a system synthesizes a single-user group from
user records to be the user's primary group.
`realm` → The "realm" the group belongs to, conceptually identical to the same field of user records.

View File

@@ -236,9 +236,9 @@ should be normalized to the primary name.
`uuid` -> A string containing a lowercase UUID that identifies this user.
The UUID should be assigned to the user at creation, be the same across multiple machines,
and never change (even if the user's username, realm or other identifying attributes change).
and never change (even if the user's username, realm, or other identifying attributes change).
When the user database is backed by Microsoft Active Directory, this field should contain
he value from the [objectGUID](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/937eb5c6-f6b3-4652-a276-5d6bb8979658)
the value from the [objectGUID](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/937eb5c6-f6b3-4652-a276-5d6bb8979658)
attribute. The same UUID can be retrieved via `mbr_uid_to_uuid` on macOS.
`blobDirectory` → The absolute path to a world-readable copy of the user's blob