Control: tags -1 moreinfo On Sat, 08 Jul 2023 00:16:28 -0400 "Theodore Y. Ts'o" <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
