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.
Follow-up for 55ea4ef096
We already had a similar check that was removed, see
8340b762e4 (*). 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.
This reverts commit 0e3cc902fa.
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.
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.
Fixes#28372
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.
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.
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.
