systemd version the issue has been seen with
261~rc1.999+58+ge098b5781
Used distribution
Fedora 44
Linux kernel version used
7.0.9-205.fc44.x86_64
CPU architectures issue was seen on
x86_64
Component
systemd-sysupdate
Expected behaviour you didn't see
With a newly installed component from somewhere like https://github.com/flatcar/sysext-bakery, you can install and update components as you would expect:
% /usr/lib/systemd/systemd-sysupdate --component=containerd list
suming same value as in source specification.
Discovering installed instances…
Discovering available instances…
⤵️ Acquiring manifest file http://localhost:555/SHA256SUMS…
Pulling 'http://localhost:555/SHA256SUMS'.
Downloading 40.4K for http://localhost:555/SHA256SUMS.
Acquired 40.4K for http://localhost:555/SHA256SUMS.
Download of http://localhost:555/SHA256SUMS complete.
Operation completed successfully.
Exiting.
Found best before marker, and it checks out, proceeding.
Determining installed update sets…
Determining available update sets…
VERSION INSTALLED AVAILABLE ASSESSMENT
● 2.3.0 ✓ ✓ current
2.2.3 ✓ available
2.2.2 ✓ available
2.2.1 ✓ available
2.2.0 ✓ available
2.1.4 ✓ available
2.1.3 ✓ available
2.1.2 ✓ available
2.1.1 ✓ available
2.1.0 ✓ available
2.0.5 ✓ available
2.0.4 ✓ available
2.0.0 ✓ available
1.7.29 ✓ available
You would thus expect that you could just do systemd-sysupdate reboot for components that require a reboot to be applied (and are not hot-reloadable with systemd-{sys,conf}ext refresh):
% /usr/lib/systemd/systemd-sysupdate --component=containerd update
# will do the install
% /usr/lib/systemd/systemd-sysupdate --component=containerd reboot
# will reboot if a new version was installed
Unexpected behaviour you saw
However, if you try to do systemd-sysupdate --component=containerd reboot (which might be necessary for some components), you get this confusing error:
% /usr/lib/systemd/systemd-sysupdate --component=containerd reboot
Discovering installed instances…
Determining installed update sets…
Newest installed version '2.3.0' is older than booted version '20260527200656'.
What has happened is that the running host version from /etc/os-release is being compared against the installed component version. This wrong for a few obvious reasons, but the main one is that the versions are (by design!) unrelated and so this can lead to completely arbitrary reboot rules (if the host OS happens to use a version string smaller than the versioning scheme used by a component, it will always reboot; otherwise it will never reboot).
This should really either error out or correctly compare the currently-running component version (which could be "none" and so the reboot should always apply). Of course, a lot of components don't require reboots to apply but that is a future feature discussion IMHO.
Steps to reproduce the problem
- Enable a new component.
- Do
systemd-sysupdate --component=foo update to install the component.
- Try to do
systemd-sysupdate --component=foo reboot.
Additional program output to the terminal or log subsystem illustrating the issue
systemd version the issue has been seen with
261~rc1.999+58+ge098b5781
Used distribution
Fedora 44
Linux kernel version used
7.0.9-205.fc44.x86_64
CPU architectures issue was seen on
x86_64
Component
systemd-sysupdate
Expected behaviour you didn't see
With a newly installed component from somewhere like https://github.com/flatcar/sysext-bakery, you can install and update components as you would expect:
You would thus expect that you could just do
systemd-sysupdate rebootfor components that require a reboot to be applied (and are not hot-reloadable withsystemd-{sys,conf}ext refresh):Unexpected behaviour you saw
However, if you try to do
systemd-sysupdate --component=containerd reboot(which might be necessary for some components), you get this confusing error:What has happened is that the running host version from
/etc/os-releaseis being compared against the installed component version. This wrong for a few obvious reasons, but the main one is that the versions are (by design!) unrelated and so this can lead to completely arbitrary reboot rules (if the host OS happens to use a version string smaller than the versioning scheme used by a component, it will always reboot; otherwise it will never reboot).This should really either error out or correctly compare the currently-running component version (which could be "none" and so the reboot should always apply). Of course, a lot of components don't require reboots to apply but that is a future feature discussion IMHO.
Steps to reproduce the problem
systemd-sysupdate --component=foo updateto install the component.systemd-sysupdate --component=foo reboot.Additional program output to the terminal or log subsystem illustrating the issue