Bug#1040622: systemd-sysv: reboot doesn't honor the grub-reboot settings; reboot -f does

[Luca Boccassi]

Control: tags -1 moreinfo

On Sat, 08 Jul 2023 00:16:28 -0400 "Theodore Y. Ts'o" <tytso at mit.edu>
wrote:
> Package: systemd-sysv
> Version: 252.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> I was updating the gce-xfstests[1] test appliance to Debian Bookworm
from
> Debian Bullseye.
> 
> [1] https://thunk.org/gce-xfstests
> 
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> 
> Unfortunately kexec has not been reliable ever since sometime after
the
> 5.4 kernel, at least on Google Compute Engine VM's.  (About 30-40% of
> the time, the VM hangs after the kexec; about 10% of the time, the
> machine is up, but it is very slow and limping, and /proc/interrupts
> shows that some interrupt channel is going wild.  This is no doubt
the
> kernel bug interacting with some virtual hardware in the GCE VM, but
> I've never been able to debug it.)
> 
> Because of issues with kexec, the primary way that I reboot into the
> kernel that I want to test is to install the kernel as a dpkg
package,
> and then examine /boot/grub/grub.cfg to find out where it was
inserted
> into the grub's menu listing, and then run a command like "grub-
reboot
> 1>4", where the number is found by examing the grub.cfg file.  An
> example of this works can be found here[2].
> 
> [2]
https://github.com/tytso/xfstests-bld/blob/9bae3253d57456987d995cf85379e9165e054381/test-appliance/files/usr/local/lib/gce-load-kernel#L169
> 
> This works *just* *fine* when using Debian Bullseye (which is using
> systemd 247.3-7+deb11u2).
> 
>    * What was the outcome of this action?
> 
> Unfortunately, this no longer works in Debian Bookworm (with systemd
> 252.6-1).  In Debian Bookworm, the grub-reboot(8) setting is ignored
> after triggering a reboot via /sbin/reboot.
> 
> Connecting to the serial console, it appears that "reboot" is going
> through some code path that does NOT involve triggering a BIOS
message
> and going through grub, where (assuming the GRUB_TIMEOUT is set to
some
> non-zero value like 15) the grub menu would be displayed, and after
15
> seconds, it would boot the kernel specified by grub-reboot, and then
> clear the next_entry entry in /boot/grub/grubenv.
> 
> Instead, systemd appears to boot the default kernel, ignoring
> /boot/grub/grubenv, so I don't enter the kernel which I had just
> installed, and had selected via the grub-reboot(8) command.  Looking
at
> /boot/grub/grubenv, it still has the "next_entry=1>4" set by
> grub-reboot(8), so it appears that /boot/grub/grubenv is being
> completely ignored by reboot.

Check whether you have kexec-tools installed. It has some crufty old
and broken sysv-init script that it enables by default and messes with
the reboot and silently makes it a kexec. I had the same issue and
disabling and masking kexec.service (which is autogenerated from the
crusty init script) fixed the problem for me.

Nothing to do with systemd, which cannot 'bypass grub', once the system
is rebooted, it's rebooted, control is given back to the kernel to do
what it's configured to do.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230708/33cb17bf/attachment.sig>