Commit Graph
234 Commits
Author SHA1 Message Date
Lennart Poettering 8a2c423870 find-esp: introduce _full() flavour of ESP/XBOOTLDR discovery functions
These functions take so many return paramaters, and in many of our cases
we don't actually needt them. Hence introduce _full() flavours of the
funcs, and hide the params by default.
2026-03-18 10:25:59 +00:00
Oblivionsage b3a2444ba5 pe-binary: wrap remaining LE fields with byte-swap macros
Follow-up to 02cab70acf. pe_hash(),
section_offset_cmp() and uki_hash() still had a bunch of raw accesses
to LE fields (e_lfanew, SizeOfHeaders, PointerToRawData, SizeOfRawData,
VirtualSize, certificate_table->Size) without le32toh(), so they'd
produce garbage on big-endian.

Also wrap VirtualSize in bootspec.c for consistency.
2026-02-19 07:34:44 +09:00
Yu Watanabe 43c4ecc951 bootspec: add missing else
Otherwise, OOM error will never checked, and the "preferred" setting
always emits warning that the field is unknown.

Follow-up for 450e0dce02.
Fixes CID#1645063.
2026-02-18 06:37:44 +01:00
r-vdp 450e0dce02 systemd-boot: add a preferred setting that's similar to default but avoids booting known-bad entries
Motivation:
Currently, when setting the default boot pattern, boot assessment status
is not taken into account. This means that with boot assessment enabled,
when an explicit boot entry is configured as the default entry using an
EFI var, as is common for instance in A/B boot schemes, the configured
entry will be booted indefinitly, regardless of the entry's boot
assessment status.
In order to allow for this use case in combination with boot assessment,
we introduce a new `preferred` keyword, both in the config file and in the
bootctl CLI, that acts very similar to the existing `default` keyword but
takes boot assessment into account and never selects any entries that
have been marked as bad.
If the preferred pattern does not resolve to any bootable entry, and a
default pattern is also specified, then the default pattern will be
considered next, and we may then still select a known-bad entry to be
booted.

Fixes: https://github.com/systemd/systemd/issues/31215
Fixes: https://github.com/systemd/systemd/issues/40192
2026-02-18 03:28:12 +09:00
Daan De Meyer 6a9f0641cd tree-wide: Fix declaration/definition parameter name mismatches 2025-11-26 19:02:31 +09:00
Jelle van der Waa 21ebaaf627 shared: prefer using SD_JSON_BUILD_PAIR_* over SD_JSON_BUILD_PAIR()
No functional change, just refactoring.
2025-11-24 21:05:10 +01:00
Jelle van der Waa 7dda32a544 shared: prefer using SD_JSON_BUILD_PAIR_* over SD_JSON_BUILD_PAIR()
No functional change, just refactoring.
2025-11-21 17:34:43 +01:00
Lennart Poettering 9bb47f9ce9 bootspec: also process uki-url boot loader spec field
Let's also add support for "uki-url", which was added at the same time to
the spec as "uki".

Follow-up for: 4a94a1b83f
2025-10-06 16:12:27 +02:00
Felix Pehla 0b89d8cfec shared/bootspec: update valid loader.conf options 2025-09-29 23:46:59 +02:00
Felix Pehla aaa3e6880d shared/bootspec: parse loader.conf options added in v258 2025-09-29 23:14:11 +02:00
Felix Pehla 5fb90fa319 shared/bootspec: parse 'profile' boot entry option
Commit 1e9c9773b9 makes sd-boot recognize
a 'profile' option in a boot loader entry but bootctl and other
components parsing said config do not know about it.

This commit makes the option get parsed correctly and displays it too.
2025-09-29 23:01:12 +02:00
Felix Pehla 4a94a1b83f shared/bootspec: parse 'uki' boot entry option
Commit e2a3d56218 (as part of #36314)
makes sd-boot recognize a 'uki' stanza in a boot loader entry and
uapi-group/specifications@3f2bd8236d adds
it to the BLS, but bootctl and other components parsing said config do
not know about it, leading to the error message
`Unknown line 'uki', ignoring.` when attempting to parse the same entry.

This commit makes it get parsed the same way that that 'efi' is.
2025-09-29 22:59:49 +02:00
Zbigniew Jędrzejewski-Szmek 57684a2554 bootctl: print location/status of loader.conf
The usual pattern of using colors to distinguish the mount path (/efi/)
and the rest is used. If the file cannot be read for reasons other than
-ENOENT, the error message is highlighted.

I considered a few places where to add this, but this section seems the
most reaosonable. We already print the 'token' there, which is also part of
the configuration.

Boot Loader Entry Locations:
          ESP: /efi (/dev/disk/by-partuuid/31659406-5a17-46ec-8195-0dea1667db58)
       config: /efi//loader/loader.conf
     XBOOTLDR: /boot (/dev/disk/by-partuuid/4f8a8fe9-4b45-4070-9e9b-a681be51c902, $BOOT)
        token: fedora
2025-07-29 11:36:21 +02:00
Li Tian b6d4997683 Add --entry-type=type1|type2 option to kernel-install.
Both kernel-core and kernel-uki-virt call kernel-install upon removal. Need an additional argument to avoid complete removal for both traditional kernel and UKI.

Signed-off-by: Li Tian <litian@redhat.com>
2025-07-10 18:07:23 +02:00
Lennart Poettering 1e7ba4780d bootspec: boot_entry_source_to_json_string() to boot_entry_source_to_string()
As with the previous changes for BootEntryType, let's also clean up the
naming for BootEntrySource.
2025-07-07 18:26:59 +02:00
Lennart Poettering 2030922e2d bootspec: rename boot_entry_source_to_string() to boot_entry_source_description_to_string()
Similar to the previous changes, let's make clear this string table
contains *descriptive*, i.e. meaningful human-readable strings.
2025-07-07 18:25:22 +02:00
Lennart Poettering 9880c7f103 bootspec: rename BootEntryType values
So we exposed different names for the entry types in JSON than we named
our enum values. Which is very confusing. Let's unify that. Given that
the JSON fields are externally visible let's stick to that naming, even
though I think "unified" and "conf" would have been more descriptive.

This ensures we follow our usual logic that the enum identifiers and the
strings they map to use the same naming.
2025-07-07 18:23:59 +02:00
Lennart Poettering a1c7aa6a95 bootspec: include 'UKI' in descriptive name for type #2
I am pretty sure that "UKI" is the best known name for type #2 boot
loader spec entries, hence we really should put it in the name.
2025-07-07 18:13:06 +02:00
Lennart Poettering 199989e168 bootspec: rename boot_entry_type_to_string() to boot_entry_type_description_to_string()
This helper does not translate BootEntryType to a string matching the
enum's value names, but instead returns a human readable descriptive
string. Let's make it clearer what this, by including "description" in
the name.
2025-07-07 18:13:06 +02:00
Lennart Poettering 1bd9a3c916 bootspec: ensure memory free in one error path 2025-06-24 00:49:46 +09:00
Yu Watanabe 91c60ff528 bootctl: do not print slash more than once
When bootctl is called by an unprivileged user, then previously we got
```
Failed to read "/boot/EFI/systemd": Permission denied
Failed to open '/boot//loader/loader.conf': Permission denied
```
Now, with this patch, we get
```
Failed to read "/boot/EFI/systemd": Permission denied
Failed to open '/boot/loader/loader.conf': Permission denied
```
2025-05-31 13:53:04 +02:00
Daan De Meyer 69a283c5f2 shared: Clean up includes
Split out of #37344.
2025-05-24 14:00:44 +02:00
Jelle van der Waa 346c62f9ca treewide: correct argument comments 2025-05-15 15:39:20 +02:00
Jelle van der Waa b52f095e9a shared: bootspec: use argument comment name auto_only 2025-05-14 11:15:45 +02:00
Igor Opaniuk 004e3e4082 sd-boot: add support for a sysfail entry
Add support for a sysfail boot entry. Sysfail boot entries can be
used for optional tweaking the automatic selection order in case a
failure state of the system in some form is detected (boot firmware
failure etc).

The EFI variable `LoaderEntrySysFail` holds the boot loader entry to
be used in the event of a system failure. If a failure occurs, the reason
will be stored in the `LoaderSysFailReason` EFI variable.

sysfail_check() expected to be extented to support possible
conditions when we should boot sysfail("recovery") boot entry.

Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
2025-05-12 15:37:46 +02:00
Daan De Meyer e53d4f343d iovec-util: Reduce transitive includes 2025-05-07 22:04:46 +09:00
Daan De Meyer 6553db6063 strv: Reduce transitive includes 2025-05-07 22:04:46 +09:00
Jelle van der Waa 1c04b172f1 treewide: correct argument comments for show_boot_entry 2025-05-06 16:26:47 +02:00
Daan De Meyer c94f6ab1bf string-table: Move more implementation logic into functions
Let's move some more implementation logic into functions. We keep
the logic that requires the macro in the macro and move the rest into
functions.

While we're at it, let's also make the parameter declarations of
all the string table macros less clausthrophobic.
2025-05-06 10:14:24 +02:00
Daan De Meyer 1cf40697e3 tree-wide: Sort includes
This was done by running a locally built clang-format with
https://github.com/llvm/llvm-project/pull/137617 and
https://github.com/llvm/llvm-project/pull/137840 applied on all .c
and .h files.
2025-04-30 09:30:51 +02:00
Daan De Meyer 93a1f7921a basic: Stop including log.h in macro.h
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
2025-04-18 14:19:15 +02:00
Zbigniew Jędrzejewski-Szmek 1ae9b0cfa8 basic/glyph-util: rename "special glyph" to just "glyph"
Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
2025-03-15 14:40:39 +01:00
Mike Yuan 992852e24c shared/bootspec: use FOREACH_ELEMENT where appropriate, avoid unneeded memzero() 2024-11-27 14:49:08 +01:00
Mike Yuan 7d93fa7099 shared/bootspec: move boot_entry_addons_done() up, drop separate prototype
Follow-up for e2501a851e
2024-11-27 14:49:04 +01:00
Adrian Vovk f2751d757f bootspec: Look at /loader/addons in XBOOTLDR
The bootspec util-lib's handling of global addons didn't previously
match the behavior of sd-stub, and this commit corrects that.

First, bootspec didn't load global addons from the XBOOTLDR dir, but the
stub does. So, bootspec now enumerates addons in XBOOTLDR, not just ESP

Second, the stub only loads resources (including addons) from the
partition that it was found on. Thus, we must keep track of which
partition the global addons come from, and which partition each boot
entry comes from. In other words: global addons found on the ESP will
NOT apply to UKIs found in XBOOTLDR, and bootspec now reflects that.
2024-11-26 22:25:29 -05:00
Adrian Vovk ef370a3c30 bootspec: Fixup loading of local addons for UKIs
Follow-up for 59b3df9
2024-11-26 16:33:11 -05:00
Adrian Vovk e2501a851e bootspec: Fixup memory leak
This would previously leak memory: the array was deleted but contents
inside of the array were not
2024-11-26 16:33:10 -05:00
Daan De Meyer d5c12da904 efivars: Remove STRINGIFY() helper macros
The names of these conflict with macros from efi.h that we'll move
to efi-fundamental.h in a later commit. Let's avoid the conflict by
getting rid of these helpers. Arguably this also improves readability
by clearly indicating we're passing arbitrary strings and not constants
to the macros when we invoke them.
2024-11-02 23:20:57 +01:00
Zbigniew Jędrzejewski-Szmek 23441a3d88 sd-json,tree-wide: add sd_json_format_enabled() and use it everwhere
We often used a pattern like if (!FLAGS_SET(flags, SD_JSON_FORMAT_OFF)),
which is rather verbose and also contains a double negative, which we try
to avoid. Add a little helper to avoid an explicit bit check.

This change clarifies an aditional thing: in some cases we treated
SD_JSON_FORMAT_OFF as a flag (flags & SD_JSON_FORMAT_OFF), while in other cases
we treated it as an independent enum value (flags == SD_JSON_FORMAT_OFF).
In the first form, flags like SD_JSON_FORMAT_SSE do _not_ turn the json
output on, while in the second form they do. Let's use the first form
everywhere.

No functional change intended.

Initially I wasn't sure if this helper should be made public or just internal,
but it seems such a common pattern that if we expose the flags, we might just
as well expose it too, to make life easier for any consumers.
2024-10-28 09:23:07 +01:00
Mike Yuan a2c8652a2a tree-wide: use strv_extend_strv_consume() where appropriate 2024-09-21 00:53:50 +02:00
Lennart Poettering 6a92a793ac bootspec: automatically filter non-native UKIs and add-ons when enumerating 2024-09-12 10:02:15 +02:00
Lennart Poettering 59b3df9bae bootspec: process multi-profile UKIs 2024-09-12 10:02:15 +02:00
Lennart Poettering f3c1d7fea1 pe-binary: split pe_read_section_data() into two
This renames pe_read_section_data() to pe_read_section_data_by_name()
and makes pe_read_section_data() a bit more low-level: it takes a header
table entry directly, instead of searching it first by name.
2024-09-12 10:02:15 +02:00
Lennart Poettering 7b7f4c2608 bootspec: correct log level for fatal errors 2024-07-12 06:30:22 +02:00
Lennart Poettering 35451a3204 bootspec: implement sorting by tries left/done, to match what sd-boot does 2024-07-12 06:30:22 +02:00
Lennart Poettering be5bee2a13 tree-wide: port over to new builder apis 2024-06-19 22:50:02 +02:00
Lennart Poettering 309a747fa6 libsystemd: turn json.[ch] into a public API
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).

I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).

This is mostly a giant search/replace patch.
2024-06-12 18:42:22 +02:00
Mike Yuan 97dfed142d shared/bootspec: use FOREACH_ARRAY more 2024-05-14 18:19:19 +08:00
Mike Yuan 4ea554e681 shared/bootspec: use isempty where appropriate 2024-05-14 18:19:19 +08:00
Mike Yuan 94e9ae6f53 shared/bootspec: use path_make_absolute where appropriate 2024-05-14 18:19:19 +08:00