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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to