[Bug 1969365] Re: focal: backport kexec fallback patch
Dan Watkins
1969365 at bugs.launchpad.net
Wed Jan 10 14:57:06 UTC 2024
In the VM created in my above comment, I enabled proposed, installed the
new systemd and rebooted. After that, I re-ran:
cd /boot
sudo kexec -l vmlinuz --initrd initrd.img --append 'BOOT_IMAGE=/boot/vmlinuz-5.4.0-167-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0'
sudo reboot
And observed the following in the console:
[ OK ] Reached target Final Step.
Starting Reboot via kexec...
[ 102.782246] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [960] did not accept message, killing the worker: Connection refused
[ 102.784224] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [963] did not accept message, killing the worker: Connection refused
[ 102.786398] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [966] did not accept message, killing the worker: Connection refused
[ 102.788390] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [968] did not accept message, killing the worker: Connection refused
[ 102.789954] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [962] did not accept message, killing the worker: Connection refused
[ 102.791562] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [961] did not accept message, killing the worker: Connection refused
[ 102.793198] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [964] did not accept message, killing the worker: Connection refused
[ 102.794669] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [967] did not accept message, killing the worker: Connection refused
[ 102.796841] systemd-udevd[369]: anon_vma(937:udisks2.service): Worker [965] did not accept message, killing the worker: Connection refused
[ 102.904092] kexec_core: Starting new kernel
[ 0.000000] Linux version 5.4.0-167-generic (buildd at lcy02-amd64-010) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)) #184-Ubuntu SMP Tue Oct 31 09:21:49 UTC 2023 (Ubuntu 5.4.0-167.184-generic 5.4.252)
So I can confirm that the new systemd addresses this bug.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1969365
Title:
focal: backport kexec fallback patch
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
It would be great if focal's systemd could have
https://github.com/systemd/systemd/commit/71180f8e57f8fbb55978b00a13990c79093ff7b3
backported to it.
[Impact]
We have observed that kexec'ing to another kernel will fail as the
drive containing the `kexec` binary has been unmounted by the time
systemd attempts to do so, indicated in the console:
Starting Reboot via kexec...
[ 163.960938] shutdown[1]: (sd-kexec) failed with exit status 1.
[ 163.963463] reboot: Restarting system
[Test Plan]
1) Launch a 20.04 instance
2) `apt-get install kexec-tools`
3) In `/boot`, filling in whatever <cmdline> needed in your environment:
kexec -l vmlinuz --initrd initrd.img --append '<cmdline>'
4) `reboot`
(I have reproduced this in a single-disk VM, so I assume it reproduces
~everywhere: if not, `apt-get remove kexec-tools` before the `reboot`
could be used to emulate the unmounting.)
[Where problems could occur]
Users could inadvertently be relying on the current behaviour: if they
have configured their systems to kexec, they currently will be
rebooting normally, and this patch would cause them to start actually
kexec'ing.
[Other info]
We're currently maintaining a systemd tree with only this patch added
to focal's tree: this patch has received a bunch of testing from us in
focal.
This patch landed in v246, so it's already present in supported
releases later than focal.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1969365/+subscriptions
More information about the foundations-bugs
mailing list