1
0
mirror of https://github.com/systemd/systemd synced 2026-03-25 08:14:54 +01:00

Compare commits

..

9 Commits

Author SHA1 Message Date
Luca Boccassi
90f4c0473a core: set Result=start-limit-hit when a unit is rate limited
There is currently no way to figure out a rate limit was hit on a unit,
as the last result is stripped in order to keep reporting the first
result, which is useful in case of a watchdog failure, which is the
reason why it was changed as such.

But rate limiting is also an important information to provide to
users, so allow the Result property to reflect it when it
happens.
2025-12-18 00:19:09 +01:00
Luca Boccassi
2a1193d4cc Bump version in meson.version 2025-12-17 23:14:11 +00:00
Luca Boccassi
9ca433482f Finalize meson.version for v259 2025-12-17 23:02:36 +00:00
Luca Boccassi
b262ded0bd
Boot loader menu docs and tweaks (#39842) 2025-12-17 23:00:59 +00:00
Zbigniew Jędrzejewski-Szmek
3cdd80d3e0 sd-boot: correct typos 2025-12-17 22:55:38 +01:00
Zbigniew Jędrzejewski-Szmek
221a33c412 TODO: remove resolved entry
Done in 677b722bb8.
2025-12-17 22:55:38 +01:00
Zbigniew Jędrzejewski-Szmek
755637b04a docs/BLI: add missing descriptions of feature bits
Follow up for 2553a5482c77980429565d14662f309e385bd472,
92bb46c464ffc6f04b633f7d82686a766663ad69,
e15d18b4c64e13c37a4c676bf61a5ecf8bba04a3,
a67f22c4a73a22312a61dd9352504cd2a960b8a8,
e1f1b5fc62f721a3a4c14d97ad01447b2ac07d6d.
2025-12-17 22:55:38 +01:00
Zbigniew Jędrzejewski-Szmek
3e2b026da3 man/systemd-boot: say that /EFI/systemd/drivers is for hardware
In aad0d11e7c6f1f7dcc7b00173140c74b8abf88cc we stopped supporting XBOOTLDR
with a different fs driver. This was the primary example that comes to mind
when we talk about loading filesystem drivers in the firmware. Since we don't
want people to do load such drivers, use a different example.
2025-12-17 22:55:38 +01:00
Zbigniew Jędrzejewski-Szmek
1228429908 docs/BOOT_LOADER_INTERFACE: use full variable names once
We said in the header that "all EFI variables use the vendor UUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f", but people not familiar with
UEFI might not know that this is concatenated with the variable name.
Let's use the full form once — when introducing the variable — to
make it easier to grep and search for.

While at it, use sembreaks in the document. This makes subsequent
changes much easier to review. (It also shows that some sentences
are rather long and thus hard to understand.)
2025-12-17 22:55:23 +01:00
13 changed files with 161 additions and 124 deletions

7
TODO
View File

@ -1392,9 +1392,6 @@ Features:
* chase(): take inspiration from path_extract_filename() and return * chase(): take inspiration from path_extract_filename() and return
O_DIRECTORY if input path contains trailing slash. O_DIRECTORY if input path contains trailing slash.
* document in boot loader spec that symlinks in XBOOTLDR/ESP are not OK even if
non-VFAT fs is used.
* measure credentials picked up from SMBIOS to some suitable PCR * measure credentials picked up from SMBIOS to some suitable PCR
* measure GPT and LUKS headers somewhere when we use them (i.e. in * measure GPT and LUKS headers somewhere when we use them (i.e. in
@ -2319,9 +2316,11 @@ Features:
ConditionConfigSearchPathNotEmpty= or different syntax? See the discussion starting at ConditionConfigSearchPathNotEmpty= or different syntax? See the discussion starting at
https://github.com/systemd/systemd/pull/15109#issuecomment-607740136. https://github.com/systemd/systemd/pull/15109#issuecomment-607740136.
* BootLoaderSpec: Define a way how an installer can figure out whether a BLS * BootLoaderSpec: define a way how an installer can figure out whether a BLS
compliant boot loader is installed. compliant boot loader is installed.
* BootLoaderSpec: document @saved pseudo-entry, update mention in BLI
* think about requeuing jobs when daemon-reload is issued? use case: * think about requeuing jobs when daemon-reload is issued? use case:
the initrd issues a reload after fstab from the host is accessible the initrd issues a reload after fstab from the host is accessible
and we might want to requeue the mounts local-fs acquired through and we might want to requeue the mounts local-fs acquired through

View File

@ -7,84 +7,97 @@ SPDX-License-Identifier: LGPL-2.1-or-later
# The Boot Loader Interface # The Boot Loader Interface
systemd can interface with the boot loader to receive performance data and systemd can interface with the boot loader
other information, and pass control information. This is only supported on EFI to receive performance data and other information,
systems. Data is transferred between the boot loader and systemd in EFI and pass control information.
variables. All EFI variables use the vendor UUID This is only supported on EFI systems.
`4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`. Data is transferred between the boot loader and systemd in EFI variables.
All EFI variables use the vendor UUID `4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`.
Variables will be listed below using the Linux efivarfs naming,
`<name>-<vendoruuid>`.
* The EFI Variable `LoaderTimeInitUSec` contains the timestamp in microseconds * The EFI Variable `LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
when the loader was initialized. This value is the time spent in the firmware contains the timestamp in microseconds when the loader was initialized.
for initialization, it is formatted as numeric, NUL-terminated, decimal This value is the time spent in the firmware for initialization.
string, in UTF-16. It is formatted as numeric, NUL-terminated, decimal string, in UTF-16.
* The EFI Variable `LoaderTimeExecUSec` contains the timestamp in microseconds * The EFI Variable `LoaderTimeExecUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
when the loader finished its work and is about to execute the kernel. The contains the timestamp in microseconds when the loader finished its work and is about to execute the kernel.
time spent in the loader is the difference between `LoaderTimeExecUSec` and The time spent in the loader is the difference between `LoaderTimeExecUSec` and `LoaderTimeInitUSec`.
`LoaderTimeInitUSec`. This value is formatted the same way as This value is formatted the same way as `LoaderTimeInitUSec`.
`LoaderTimeInitUSec`.
* The EFI variable `LoaderDevicePartUUID` contains the partition GUID of the * The EFI variable `LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
ESP the boot loader was run from formatted as NUL-terminated UTF16 string, in contains the partition GUID of the ESP the boot loader was run from
normal GUID syntax. formatted as NUL-terminated UTF16 string, in normal GUID syntax.
* The EFI variable `LoaderConfigTimeout` contains the boot menu timeout * The EFI variable `LoaderConfigTimeout-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
currently in use. It may be modified both by the boot loader and by the contains the boot menu timeout currently in use.
host. The value should be formatted as numeric, NUL-terminated, decimal It may be modified both by the boot loader and by the host.
string, in UTF-16. The time is specified in seconds. In addition some The value should be formatted as numeric, NUL-terminated, decimal string, in UTF-16.
non-numeric string values are also accepted. A value of `menu-force` The time is specified in seconds.
will disable the timeout and show the menu indefinitely. If set to `0` or In addition some non-numeric string values are also accepted.
`menu-hidden` the default entry is booted immediately without showing a menu. A value of `menu-force` will disable the timeout and show the menu indefinitely.
Unless a value of `menu-disabled` is set, the boot loader should provide a If set to `0` or `menu-hidden` the default entry is booted immediately without showing a menu.
way to interrupt this by for example listening for key presses for a brief Unless a value of `menu-disabled` is set,
moment before booting. the boot loader should provide a way to interrupt this
by for example listening for key presses for a brief moment before booting.
* Similarly, the EFI variable `LoaderConfigTimeoutOneShot` contains a boot menu * Similarly, the EFI variable `LoaderConfigTimeoutOneShot-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
timeout for a single following boot. It is set by the OS in order to request contains a boot menu timeout for a single following boot.
display of the boot menu on the following boot. When set overrides It is set by the OS in order to request display of the boot menu on the following boot.
`LoaderConfigTimeout`. It is removed automatically after being read by the When set overrides `LoaderConfigTimeout`.
boot loader, to ensure it only takes effect a single time. This value is It is removed automatically after being read by the boot loader,
formatted the same way as `LoaderConfigTimeout`. If set to `0` the boot menu to ensure it only takes effect a single time.
timeout is turned off, and the menu is shown indefinitely. This value is formatted the same way as `LoaderConfigTimeout`.
If set to `0` the boot menu timeout is turned off,
and the menu is shown indefinitely.
* The EFI variable `LoaderEntries` may contain a series of boot loader entry * The EFI variable `LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
identifiers, one after the other, each individually NUL terminated. This may may contain a series of boot loader entry identifiers,
be used to let the OS know which boot menu entries were discovered by the one after the other, each individually NUL terminated.
boot loader. A boot loader entry identifier should be a short, non-empty This may be used to let the OS know which boot menu entries were discovered by the boot loader.
alphanumeric string (possibly containing `-`, too). The list should be in the A boot loader entry identifier should be a short, non-empty alphanumeric string
order the entries are shown on screen during boot. See below regarding the (possibly containing `-`, too).
recommended vocabulary for boot loader entry identifiers. The list should be in the 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 * The EFI variable `LoaderEntryDefault-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
to use. It contains a NUL-terminated boot loader entry identifier. contains the default boot loader entry to use.
It contains a NUL-terminated boot loader entry identifier.
* The EFI variable `LoaderEntrySysFail` specifies the boot loader entry to be * The EFI variable `LoaderEntrySysFail-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
used in case of a system failure. System failure (SysFail) boot entries can specifies the boot loader entry to be used in case of a system failure.
optionally modify the automatic selection order in the event of a failure, System failure (SysFail) boot entries
such as a boot firmware update failure with the failure status recorded in can optionally modify the automatic selection order in the event of a failure,
the EFI system table. If a system failure occurs and `LoaderEntrySysFail` is such as a boot firmware update failure with the failure status recorded in the EFI system table.
set, systemd-boot will use this boot entry, and store the actual SysFail If a system failure occurs and `LoaderEntrySysFail` is set,
reason in the `LoaderSysFailReason` EFI variable. 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. * The EFI variable `LoaderSysFailReason-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
contains the system failure reason.
This variable is used in cooperation with `LoaderEntrySysFail` boot entry. This variable is used in cooperation with `LoaderEntrySysFail` boot entry.
If system failure doesn't occur, `LoaderSysFailReason` is not set. If system failure doesn't occur, `LoaderSysFailReason` is not set.
* Similarly, the EFI variable `LoaderEntryOneShot` contains the default boot * Similarly, the EFI variable `LoaderEntryOneShot-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
loader entry to use for a single following boot. It is set by the OS in order contains the default boot loader entry to use for a single following boot.
to request booting into a specific menu entry on the following boot. When set It is set by the OS
overrides `LoaderEntryDefault`. It is removed automatically after being read in order to request booting into a specific menu entry on the following boot.
by the boot loader, to ensure it only takes effect a single time. This value When set overrides `LoaderEntryDefault`.
is formatted the same way as `LoaderEntryDefault`. It is removed automatically after being read by the boot loader,
to ensure it only takes effect a single time.
This value is formatted the same way as `LoaderEntryDefault`.
* The EFI variable `LoaderEntrySelected` contains the boot loader entry * The EFI variable `LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
identifier that was booted. It is set by the boot loader and read by contains the boot loader entry identifier that was booted.
the OS in order to identify which entry has been used for the current boot. It is set by the boot loader and read by the OS
in order to identify which entry has been used for the current boot.
* The EFI variable `LoaderFeatures` contains a 64-bit unsigned integer with a * The EFI variable `LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
number of flags bits that are set by the boot loader and passed to the OS and contains a 64-bit unsigned integer with a number of flags bits
indicate the features the boot loader supports. Specifically, the following that are set by the boot loader and passed to the OS
bits are defined: and indicate the features the boot loader supports.
Specifically, the following bits are defined:
* `1 << 0` → The boot loader honours `LoaderConfigTimeout` when set. * `1 << 0` → The boot loader honours `LoaderConfigTimeout` when set.
* `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set. * `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set.
@ -93,29 +106,53 @@ variables. All EFI variables use the vendor UUID
* `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](/AUTOMATIC_BOOT_ASSESSMENT). * `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](/AUTOMATIC_BOOT_ASSESSMENT).
* `1 << 5` → The boot loader supports looking for boot menu entries in the Extended Boot Loader Partition. * `1 << 5` → The boot loader supports looking for boot menu entries in the Extended Boot Loader Partition.
* `1 << 6` → The boot loader supports passing a random seed to the OS. * `1 << 6` → The boot loader supports passing a random seed to the OS.
* `1 << 7` → The boot loader supports loading of drop-in drivers from the `/EFI/systemd/drivers/` directory on the ESP,
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html).
* `1 << 8` → The boot loader supports the `sort-key` field defined by the
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
* `1 << 9` → The boot loader supports the `@saved` pseudo-entry
* `1 << 10` → The boot loader supports the `devicetree` field defined by the
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
* `1 << 11` → The boot loader support automatic enrollment of SecureBoot keys,
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html).
* `1 << 12` → The boot loader will set EFI variable `ShimRetainProtocol-605dab50-e046-4300-abb6-3dd810dd8b23`
for `shim` to make its protocol available to the booted binary.
* `1 << 13` → The boot loader honours `menu-disabled` option when set. * `1 << 13` → The boot loader honours `menu-disabled` option when set.
* `1 << 14` → The boot loader supports multi-profile Unified Kernel Images (UKIs)
* `1 << 15` → The boot loader sets the `LoaderDeviceURL` variable when appropriate.
* `1 << 16` → The boot loader supports the `uki` field defined by the
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
* `1 << 17` → The boot loader supports the `uki-url` field defined by the
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
* `1 << 18` → The boot loader reports active TPM2 PCR banks in the
EFI variable `LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`.
* The EFI variable `LoaderSystemToken` contains binary random data, * The EFI variable `LoaderSystemToken-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
persistently set by the OS installer. Boot loaders that support passing contains binary random data,
random seeds to the OS should use this data and combine it with the random persistently set by the OS installer.
seed file read from the ESP. By combining this random data with the random Boot loaders that support passing random seeds to the OS
seed read off the disk before generating a seed to pass to the OS and a new should use this data and combine it with the random seed file read from the ESP.
seed to store in the ESP the boot loader can protect itself from situations By combining this random data with the random seed read off the disk
where "golden" OS images that include a random seed are replicated and used before generating a seed to pass to the OS and a new seed to store in the ESP
on multiple systems. Since the EFI variable storage is usually independent the boot loader can protect itself from situations where
(i.e. in physical NVRAM) of the ESP file system storage, and only the latter "golden" OS images that include a random seed are replicated and used on multiple systems.
is part of "golden" OS images, this ensures that different systems still come Since the EFI variable storage is usually independent
up with different random seeds. Note that the `LoaderSystemToken` is (i.e. in physical NVRAM) of the ESP file system storage,
generally only written once, by the OS installer, and is usually not touched and only the latter is part of "golden" OS images,
after that. this ensures that different systems still come up with different random seeds.
Note that the `LoaderSystemToken` is generally only written once,
by the OS installer,
and is usually not touched after that.
* The EFI variable `LoaderDeviceURL` contains the URL the boot loader was * The EFI variable `LoaderDeviceURL-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
downloaded from, in UTF-16 format. Only set in case of network boots. contains the URL the boot loader was downloaded from,
in UTF-16 format.
Only set in case of network boots.
* The EFI variable `LoaderTpm2ActivePcrBanks` contains a hexadecimal string * The EFI variable `LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`
representation of a bitmask with values defined by the TCG EFI Protocol contains a hexadecimal string representation of a bitmask with values defined by
Specification for TPM 2.0 as EFI_TCG2_BOOT_HASH_ALG_*. If no TPM2 support or the TCG EFI ProtocolSpecification for TPM 2.0 as `EFI_TCG2_BOOT_HASH_ALG_*`.
no active banks were detected, will be set to `0`. If no TPM2 support or no active banks were detected, will be set to `0`.
If `LoaderTimeInitUSec` and `LoaderTimeExecUSec` are set, `systemd-analyze` If `LoaderTimeInitUSec` and `LoaderTimeExecUSec` are set, `systemd-analyze`
will include them in its boot-time analysis. If `LoaderDevicePartUUID` is set, will include them in its boot-time analysis. If `LoaderDevicePartUUID` is set,
@ -128,12 +165,11 @@ variables.
## Boot Loader Entry Identifiers ## Boot Loader Entry Identifiers
While boot loader entries may be named relatively freely, it's highly While boot loader entries may be named relatively freely,
recommended to follow the following rules when picking identifiers for the it's highly recommended to follow the following rules when picking identifiers for the entries,
entries, so that programs (and users) can derive basic context and meaning from so that programs (and users) can derive basic context and meaning from the identifiers
the identifiers as passed in `LoaderEntries`, `LoaderEntryDefault`, as passed in `LoaderEntries`, `LoaderEntryDefault`, `LoaderEntryOneShot`, `LoaderEntrySelected`,
`LoaderEntryOneShot`, `LoaderEntrySelected`, and possibly show nicely localized and possibly show nicely localized names for them in UIs.
names for them in UIs.
1. When boot loader entries are defined through the 1. When boot loader entries are defined through the
[BOOT.1 Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/) [BOOT.1 Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/)
@ -141,29 +177,30 @@ names for them in UIs.
but with the `.conf` (Type #1 snippets) or `.efi` (Type #2 images) but with the `.conf` (Type #1 snippets) or `.efi` (Type #2 images)
suffix removed. suffix removed.
2. Entries automatically discovered by the boot loader (as opposed to being 2. Entries automatically discovered by the boot loader
configured in configuration files) should generally have an identifier (as opposed to being configured in configuration files)
prefixed with `auto-`. should generally have an identifier prefixed with `auto-`.
3. Boot menu entries referring to Microsoft Windows installations should either 3. Boot menu entries referring to Microsoft Windows installations
use the identifier `windows` or use the `windows-` prefix for the should either use the identifier `windows`
identifier. If a menu entry is automatically discovered, it should be or use the `windows-` prefix for the identifier.
prefixed with `auto-`, see above (Example: this means an automatically If a menu entry is automatically discovered,
discovered Windows installation might have the identifier `auto-windows` or it should be prefixed with `auto-`, see above.
`auto-windows-10` or so.). (Example: this means an automatically discovered Windows installation
might have the identifier `auto-windows` or `auto-windows-10` or so.).
4. Similarly, boot menu entries referring to Apple macOS installations should 4. Similarly, boot menu entries referring to Apple macOS installations
use the identifier `osx` or one that is prefixed with `osx-`. If such an should use the identifier `osx` or one that is prefixed with `osx-`.
entry is automatically discovered by the boot loader use `auto-osx` as If such an entry is automatically discovered by the boot loader use `auto-osx` as identifier,
identifier, or `auto-osx-` as prefix for the identifier, see above. or `auto-osx-` as prefix for the identifier, see above.
5. If a boot menu entry encapsulates the EFI shell program, it should use the 5. If a boot menu entry encapsulates the EFI shell program,
identifier `efi-shell` (or when automatically discovered: `auto-efi-shell`, it should use the identifier `efi-shell`
see above). (or when automatically discovered: `auto-efi-shell`, see above).
6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature, 6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature,
it should use the identifier `reboot-to-firmware-setup` (or it should use the identifier `reboot-to-firmware-setup`
`auto-reboot-to-firmware-setup` in case it is automatically discovered). (or `auto-reboot-to-firmware-setup` in case it is automatically discovered).
## Links ## Links

View File

@ -57,7 +57,7 @@
<listitem><para>A <literal>Reboot Into Firmware Interface</literal> option, if supported by the UEFI <listitem><para>A <literal>Reboot Into Firmware Interface</literal> option, if supported by the UEFI
firmware.</para></listitem> firmware.</para></listitem>
<listitem><para>Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided <listitem><para>Secure Boot variable enrollment if the UEFI firmware is in setup mode and files are provided
on the ESP.</para></listitem> on the ESP.</para></listitem>
</itemizedlist> </itemizedlist>
@ -97,7 +97,7 @@
entropy pool initialization, providing a full entropy pool during early boot.</para></listitem> entropy pool initialization, providing a full entropy pool during early boot.</para></listitem>
<listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is <listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is
in setup-mode. Additionally, variables can be automatically enrolled if configured.</para></listitem> in setup mode. Additionally, variables can be automatically enrolled if configured.</para></listitem>
</itemizedlist> </itemizedlist>
<para><citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> <para><citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
@ -386,8 +386,8 @@
<para>During initialization, <command>systemd-boot</command> automatically loads all driver files placed <para>During initialization, <command>systemd-boot</command> automatically loads all driver files placed
in the <filename>/EFI/systemd/drivers/</filename> directory of the ESP. The files placed there must have in the <filename>/EFI/systemd/drivers/</filename> directory of the ESP. The files placed there must have
an extension of the EFI architecture ID followed by <filename>.efi</filename> (e.g. for x86-64 this means an extension of the EFI architecture ID followed by <filename>.efi</filename> (e.g. for x86-64 this means
a suffix of <filename>x64.efi</filename>). This may be used to automatically load file system drivers and a suffix of <filename>x64.efi</filename>). This may be used e.g. to add support for hardware not
similar, to extend the native firmware support.</para> supported natively by the firmware.</para>
<para>Enrollment of Secure Boot variables can be performed manually or automatically if files are available <para>Enrollment of Secure Boot variables can be performed manually or automatically if files are available
under <filename>/loader/keys/<replaceable>NAME</replaceable>/{db,dbx,KEK,PK}.auth</filename>, <replaceable>NAME</replaceable> under <filename>/loader/keys/<replaceable>NAME</replaceable>/{db,dbx,KEK,PK}.auth</filename>, <replaceable>NAME</replaceable>

View File

@ -1 +1 @@
259~rc3 260~devel

View File

@ -424,7 +424,7 @@ int verb_status(int argc, char *argv[], void *userdata) {
{ EFI_LOADER_FEATURE_REPORT_URL, "Loader reports network boot URL" }, { EFI_LOADER_FEATURE_REPORT_URL, "Loader reports network boot URL" },
{ EFI_LOADER_FEATURE_TYPE1_UKI, "Support Type #1 uki field" }, { EFI_LOADER_FEATURE_TYPE1_UKI, "Support Type #1 uki field" },
{ EFI_LOADER_FEATURE_TYPE1_UKI_URL, "Support Type #1 uki-url field" }, { EFI_LOADER_FEATURE_TYPE1_UKI_URL, "Support Type #1 uki-url field" },
{ EFI_LOADER_FEATURE_TPM2_ACTIVE_PCR_BANKS, "Loader reports TPM2 active PCR banks" }, { EFI_LOADER_FEATURE_TPM2_ACTIVE_PCR_BANKS, "Loader reports active TPM2 PCR banks" },
}; };
static const struct { static const struct {
uint64_t flag; uint64_t flag;

View File

@ -324,7 +324,7 @@ static void automount_dump(Unit *u, FILE *f, const char *prefix) {
static void automount_enter_dead(Automount *a, AutomountResult f) { static void automount_enter_dead(Automount *a, AutomountResult f) {
assert(a); assert(a);
if (a->result == AUTOMOUNT_SUCCESS) if (a->result == AUTOMOUNT_SUCCESS || IN_SET(f, AUTOMOUNT_FAILURE_MOUNT_START_LIMIT_HIT, AUTOMOUNT_FAILURE_START_LIMIT_HIT))
a->result = f; a->result = f;
unit_log_result(UNIT(a), a->result == AUTOMOUNT_SUCCESS, automount_result_to_string(a->result)); unit_log_result(UNIT(a), a->result == AUTOMOUNT_SUCCESS, automount_result_to_string(a->result));

View File

@ -893,7 +893,7 @@ static int mount_spawn(Mount *m, ExecCommand *c, ExecFlags flags, PidRef *ret_pi
static void mount_enter_dead(Mount *m, MountResult f, bool flush_result) { static void mount_enter_dead(Mount *m, MountResult f, bool flush_result) {
assert(m); assert(m);
if (m->result == MOUNT_SUCCESS || flush_result) if (m->result == MOUNT_SUCCESS || f == MOUNT_FAILURE_START_LIMIT_HIT || flush_result)
m->result = f; m->result = f;
unit_log_result(UNIT(m), m->result == MOUNT_SUCCESS, mount_result_to_string(m->result)); unit_log_result(UNIT(m), m->result == MOUNT_SUCCESS, mount_result_to_string(m->result));

View File

@ -502,7 +502,7 @@ static int path_coldplug(Unit *u) {
static void path_enter_dead(Path *p, PathResult f) { static void path_enter_dead(Path *p, PathResult f) {
assert(p); assert(p);
if (p->result == PATH_SUCCESS) if (p->result == PATH_SUCCESS || IN_SET(f, PATH_FAILURE_START_LIMIT_HIT, PATH_FAILURE_UNIT_START_LIMIT_HIT))
p->result = f; p->result = f;
unit_log_result(UNIT(p), p->result == PATH_SUCCESS, path_result_to_string(p->result)); unit_log_result(UNIT(p), p->result == PATH_SUCCESS, path_result_to_string(p->result));

View File

@ -2115,7 +2115,7 @@ static void service_enter_dead(Service *s, ServiceResult f, bool allow_restart)
if (unit_stop_pending(UNIT(s))) if (unit_stop_pending(UNIT(s)))
allow_restart = false; allow_restart = false;
if (s->result == SERVICE_SUCCESS) if (s->result == SERVICE_SUCCESS || f == SERVICE_FAILURE_START_LIMIT_HIT)
s->result = f; s->result = f;
if (s->result == SERVICE_SUCCESS) { if (s->result == SERVICE_SUCCESS) {

View File

@ -2116,7 +2116,7 @@ static int socket_chown(Socket *s, PidRef *ret_pid) {
static void socket_enter_dead(Socket *s, SocketResult f) { static void socket_enter_dead(Socket *s, SocketResult f) {
assert(s); assert(s);
if (s->result == SOCKET_SUCCESS) if (s->result == SOCKET_SUCCESS || IN_SET(f, SOCKET_FAILURE_SERVICE_START_LIMIT_HIT, SOCKET_FAILURE_START_LIMIT_HIT))
s->result = f; s->result = f;
if (s->result == SOCKET_SUCCESS) if (s->result == SOCKET_SUCCESS)

View File

@ -668,7 +668,7 @@ static int swap_spawn(Swap *s, ExecCommand *c, PidRef *ret_pid) {
static void swap_enter_dead(Swap *s, SwapResult f) { static void swap_enter_dead(Swap *s, SwapResult f) {
assert(s); assert(s);
if (s->result == SWAP_SUCCESS) if (s->result == SWAP_SUCCESS || f == SWAP_FAILURE_START_LIMIT_HIT)
s->result = f; s->result = f;
unit_log_result(UNIT(s), s->result == SWAP_SUCCESS, swap_result_to_string(s->result)); unit_log_result(UNIT(s), s->result == SWAP_SUCCESS, swap_result_to_string(s->result));

View File

@ -324,7 +324,7 @@ static int timer_coldplug(Unit *u) {
static void timer_enter_dead(Timer *t, TimerResult f) { static void timer_enter_dead(Timer *t, TimerResult f) {
assert(t); assert(t);
if (t->result == TIMER_SUCCESS) if (t->result == TIMER_SUCCESS || f == TIMER_FAILURE_START_LIMIT_HIT)
t->result = f; t->result = f;
unit_log_result(UNIT(t), t->result == TIMER_SUCCESS, timer_result_to_string(t->result)); unit_log_result(UNIT(t), t->result == TIMER_SUCCESS, timer_result_to_string(t->result));

View File

@ -14,3 +14,4 @@ while [[ "$active_state" == "activating" || "$active_state" =~ ^(in)?active$ ]];
done done
systemctl is-failed issue3166-fail-on-restart.service || exit 1 systemctl is-failed issue3166-fail-on-restart.service || exit 1
[[ "$(systemctl show --value --property NRestarts issue3166-fail-on-restart.service)" -le 3 ]] || exit 1 [[ "$(systemctl show --value --property NRestarts issue3166-fail-on-restart.service)" -le 3 ]] || exit 1
[[ "$(systemctl show --value --property Result issue3166-fail-on-restart.service)" = "start-limit-hit" ]] || exit 1