Control: tags -1 -moreinfo Control: forcemerge 1039248 -1 On Sat, 08 Jul 2023 15:37:25 +0100 Luca Boccassi <bl...@debian.org> wrote: > Control: tags -1 moreinfo > > On Sat, 08 Jul 2023 00:16:28 -0400 "Theodore Y. Ts'o" <ty...@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.) > 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.
Merging with #1039248 as I'm quite sure this is a problem with kexec- tool's old init script, as I had the same issue. Once the package provides a native and working unit file it should go away. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
