mirror of
https://github.com/morgan9e/systemd
synced 2026-04-14 00:14:32 +09:00
Minor docs cleanups (#37439)
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user