Luca Boccassi [Tue, 10 Oct 2023 17:50:36 +0000 (18:50 +0100)]
core: fix checking for extension-releases for ExtensionImages/Directories
The parsing is done after the image has been opened, not before, as it
cannot be done on an block device. Also fix returning on any error for
ExtensionDirectories, not just ENOENT.
hibernate-resume: remove kernel/image version comparison when resuming
We already had a similar check that was removed, see 8340b762e4f597e98a72de1385e74b9be04e521d (*). The kernel supports loading of a
resume image from a different kernel version. This makes sense, because the
goal of "resume" is to replace the running system by a saved memory image, so
it doesn't really matter that the short-lived kernel is different.
By removing the check, we make the process more reliable: for example, the user
may select a different kernel from a list, or not have the previously running
kernel in /boot at all, etc. Requiring the exact same kernel version makes the
process more fragile for no benefit.
Similar reasoning holds for the image version: the image may be updated, and
for example an older kernel+initrd might be used, with an embedded VERSION_ID
that is not the latest. This is fine, and the check is not useful.
I left the check for ID/IMAGE_ID: we probably don't want to use the resume
image if the hibernation was done from a different installation.
(Note: why not check VERSION_ID/IMAGE_VERSION? Because of the following
scenario: a user has an installation of Fedora 35, and they upgrade to Fedora
36, which means that the os-release file on disk gets replaced and now
specifies VERSION_ID=36. But the running kernel is not replaced, and its
package is not removed because the running kernel version is never removed, so
we still have a boot entry that in initrd-release says VERSION_ID=35. Without
rebooting, the user does hibernation. When resuming, we want to resume, no
matter if one of the new entries with VERSION_ID=36 or one of the old entries
with VERSION_ID=35 is picked in the boot loader menu.
If the installation is image-based, i.e. it has IMAGE_ID+IMAGE_VERSION, the
situation is similar: after an upgrade, we may still have an boot entry from
before the upgrade. Using an older kernel+initrd to boot and switch-root into a
newer installation is supported and is rather common.
In fact, it is a rather common situation that the version reported by the boot
entry (or stored internally in the initrd-release in the initrd) does not match
the actual system on disk. Generally, this metadata is saved when the boot menu
entry is written and does not reflect subsequent upgrades. Various
distributions generally keep at least 3 kernels after a upgrade, and during an
upgrade only install one new, which means that after a major upgrade, generally
there will be at least two kernels which have mismatched version information.)
OTOH, I think it is useful to *write* all the details to the EFI var. As
discussed in https://github.com/systemd/systemd/issues/29037, we may want to
show this information in the boot loader. It is also useful for debugging.
(*) Also again discussed and verified in
https://github.com/systemd/systemd/pull/27330#discussion_r1234332080.
", ignored" is dropped, since this failure is likely to cause the following
check to fail. Better not to say anything then to say the misleading thing.
Fixes #10288.
I have confirmed that this does now fix cross-compilation.
It appears that changes upstream in Meson, probably mesonbuild/meson#5263, have made the original MR, #10289, work now.
This needs to be tested to ensure that it doesn't break Travis CI like when it was reverted in #10361.
Some of the entries are really configured, but we also have a bunch
of automatic entries. Calling them "config entries" is misleading, let's
use the more natural "boot entry".
While at it, rename:
config_load_entries() → config_load_type1_entries()
config_entry_add_unified() → config_load_type2_entries()
config_title_generate() → generate_boot_entry_titles()
config_entry_add_<type>() → config_add_entry_<type>()
efi/boot: make timeout changes relative to current value
When the user pressed + or -, we would set the efivar override, starting
from the default of 0. Instead, set an override that starts at the current
value. This means that when user has e.g. a configured override of 5 s, and
they press +, they get an override of 6 s. I think this is leads to a much
smoother experience for a user, who does not necessarilly need to know that
we have three levels of overrides, they just want to easily configure the
timeout with keys. If they press +, the timeout should increase, and not
jump to some low value.
Also, once an override has been set via the boot menu, i.e. the efivar is set,
do not allow unsetting the efivar from the boot menu. This way we also avoid
an unexpected "jump" to whatever the other sources of configuration specify.
The user can configure any value with the keys that they want, so we don't
need to allow unsetting.
sd-boot: when rebooting or powering off, save config state
The menu_run() function allows the user to set/unset default entry, or to
increase/decrease menu timeout. After a keypress, status like
"Menu timeout set to 5 s"
is printed, but there actually isn't any immediate effect. The value is only
written right right before booting a menu entry to avoid unnecessary wear&tear
on the nvram storage. This delayed write is supposed to be invisible to the
user.
Nevertheless, operations like reboot into firmware, reboot, or shutdown were
done immediately. We need to exit the loop first, save the state, and only do
the op afterwards.
Daan De Meyer [Mon, 9 Oct 2023 14:06:50 +0000 (16:06 +0200)]
sd-device: Support matching all properties
Let's support enumerating over devices that match all of the given
properties instead of any of the given properties by adding a new
function sd_device_enumerator_add_match_property_required() which
specifies properties that should all be matched instead of just one.
varlink: didn't generate a varlink error reply if a failed method call handler already did
It might happen that a method call handler already generated an error
reply and then still propagated the error back to the varlink logic.
Let's not try to generate a 2nd reply from that error code then, but
simply proceed without. This simplifies handling of errors in method
call handlers, because they can uniformly return errno-style error
codes, and only if they want return a full Varlink errror.
varlink: automatically send ExpectedMore error message back when we were called without more=true set, but need it
Various Varlink calls only make sense if they are called with more=true
(i.e. in a mode where multiple replies are expected to be sent). If a
method call assumes it is called with more (manifested in the fact it
calls varlink_notify(), the call to reply to such messages) let's return
a recognizable error code for the violated expectation.
This adds a new error for this, org.varlink.service.ExpectedMore. Note
we are squatting the official org.varlink.service namespace, but for
such a basic thing it makes sense to add it there.
kernel-install/60-ukify: also support the convention with 'devicetree' file
Requested in https://github.com/systemd/systemd/pull/28582#issuecomment-1673300596.
The is the last requested changed, so fixes #28771.
90-loaderentry.install is modified to also check $KERNEL_INSTALL_CONF_ROOT
when looking for the devicetree file. For normal use this is probably not
needed, but it's nice to be consistent and it also makes it much easier to
write the tests.
In tests, also do 'ukify inspect' now that we have it.
man/kernel-install: fix formatting and document /etc/kernel/devicetree
Each filename should be a separate <term>, so that they separated in the
formatted text. Also, we list files in documentation in priority order, but
here they were in reverse order. Also, rework the description of
$KERNEL_INSTALL_CONF_ROOT to say that it makes kernel-install not look at the
other files. This requires some more words, so make this a separate paragraph
and refer from individual items to it. Also, drop some sentences with "Read by
...", they were already outdated.
Partial fix for #28771.
Co-authored-by: Emil Renner Berthing <systemd@esmil.dk>
kernel-install/90-loaderentry: do not read dtbs from /boot
/boot is not trusted, so we shouldn't use load files from there. Also, space in
/boot is limited, so it doesn't make sense to install the files under one
location there and then copy them to a different location. We should only copy
the files from /usr somewhere and then install it in the appropriate place under
/boot.
Also use "/usr/lib" instead of the "/lib" prefix. We don't support unmerged-user
anymore.
Addresses some of the feedback in
https://github.com/systemd/systemd/pull/28582#discussion_r1285820556.
PhylLu [Wed, 11 Oct 2023 01:41:29 +0000 (09:41 +0800)]
timedate: Extend timeout for setting NTP
One of the steps in setting up NTP is to enable/disable the
'systemd-timesyncd.service' and then perform a daemon reload.
we use an extra-long timeout for reload in timedated as same as used in
systemd daemon reload to avoiding certain situation have longer reload
times (which exceed the 25 second default timeout used for
dbus-communication), potentially leading to setting NTP failure.
limits-util: suppress noisy debug message when reading tasks in top-level cgroup
We have the "tasks.max" cgroup attribute only if we run in a cgroup
namespace, but not on the host. Hence let's handle ENODATA silently
simply to reduce the debug noise generated.
Before this commit, we hardcode "prefix" to the widest field
possible in the table. However, there's no guarantee that the
field would actually be used/added, so it could potentially
result in misalignment. Therefore, let's set the minimum width
of the cell to the hardcoded width too.
Dan Streetman [Tue, 10 Oct 2023 20:55:39 +0000 (16:55 -0400)]
tpm2: don't use GetCapability() to check transient handles
The kernel tpm "resource manager" interface doesn't report that any transient
handles exist, even if they do, so don't bother asking if the handle is
transient.
Dan Streetman [Mon, 9 Oct 2023 16:27:10 +0000 (12:27 -0400)]
tpm2: do not call Esys_TR_Close()
Unfortunately, the tpm2-tss library doesn't reference count handles, and a call
to Esys_TR_Close() will remove the handle that could be in use by other
code. So stop calling Esys_TR_Close(), and leave the handle around until we
cleanup the entire ESYS_CONTEXT.
Dan Streetman [Fri, 6 Oct 2023 15:14:25 +0000 (11:14 -0400)]
test: add tests for systemd-cryptenroll --tpm2-seal-key-handle
In TEST-70-TPM2, test systemd-cryptenroll --tpm2-seal-key-handle using the
default (0) as well as the SRK handle (0x81000001), and test using a non-SRK
handle index after creating and persisting a primary key.
In test/test-tpm2, test tpm2_seal() and tpm2_unseal() using default (0), the SRK
handle, and a transient handle.
Luca Boccassi [Mon, 9 Oct 2023 14:56:37 +0000 (15:56 +0100)]
dissect: avoid clobbering device-mapper error when activating verity
The device-mapper driver can return a wild variety of errors when trying
to activate the same dm-verity volume concurrently, as it might happen
with an image. There is a fallback logic in place, but the original
return code was clobbered when userspace signature check was added.
Add it back.
Mike Yuan [Sat, 7 Oct 2023 12:08:21 +0000 (20:08 +0800)]
core/execute: always set $USER and introduce SetLoginEnvironment=
Before this commit, $USER, $HOME, $LOGNAME and $SHELL are only
set when User= is set for the unit. For system service, this
results in different behaviors depending on whether User=root is set.
$USER always makes sense on its own, so let's set it unconditionally.
Ideally $HOME should be set too, but it causes trouble when e.g. getty
passes '-p' to login(1), which then doesn't override $HOME. $LOGNAME and
$SHELL are more like "login environments", and are generally not
suitable for system services. Therefore, a new option SetLoginEnvironment=
is also added to control the latter three variables.
man: support multiple versions of the documentation on the website
This changes the doc-sync meson target from a simple rsync command to a
script that:
* puts the documentation in a subdirectory according to the version
* injects a bit of javascript to add a drop-down to switch between versions
* updates an index.json file with the newly uploaded version
* keeps the latest/ directory up to date with the latest version
* supports a --no-latest switch to be used when uploading older versions
Piotr Drąg [Sat, 7 Oct 2023 14:54:04 +0000 (16:54 +0200)]
po: add a false positive to POTFILES.skip
Scripts used to detect files that should be in POTFILES.in, like
intltool-update -m used on https://l10n.gnome.org/module/systemd/,
falsely detect this file as containing translations. Avoid this
behavior by putting the file in POTFILES.skip.
Let's move it out of cgroup.[ch]. The function primarily compares the
priority values for units, hence let's move the core of it into a new
function unit_compare_priority() in unit.[ch], and then make
compare_job_priority() a local wrapper for it in manager.[ch]
projects / thirdparty / systemd.git / log
