kexec ignores me!

[Goverp]

Reading the wiki and the kernel docs, I think I'd like to use "kexec" to speed rebooting my system when I'm playing with my initramfs "init" script.
So I installed kexec-tools and edited /etc/kexec.conf (the ellipses are not in the file, I just removed some booring lines!):

[pingtoo]

Don't you need to use

[Goverp]

Not according to the comments in the forums. "reboot -k" says you can't do it in this runlevel, for all runlevels other than 6, which you normally reach via the shutdown command (or one of the many aliases involved here). You can do "reboot -kf", but that chops the system off at the knees, leaving open files and all sorts of nastiness.

<edit>I know the wiki says that, but it doesn't work, and there's a discussion in this forum article.

What's supposed to happen is that, with the kexec-tools package installed and a kexec-enabled kernel, under OpenRc, you start the "kexec" service and then do a normal shutdown. That service runs during shutdown, and a hook in OpenRc (and possibly in sysv-init stuff, I'm trying unsuccessfully to wade my way through the twisty-turney maze of code here) is supposed to to the actual kexec thing once the system is nicely in bed and asleep - i.e. run level 6.

One possibility that's occurred to me is that it might be my use of 'rc_parallel="YES" in /etc/rc.conf - maybe the hook can't tell if kexec is required. I need to make a fairly trivial test...
_________________
Greybeard

[pingtoo]

So, what about your /etc/inittab?

Does level 6 reboot have the -k option?

[Goverp]

Yup, same list.
_________________
Greybeard

[pingtoo]

Could it be that kernel failed load into memory before reboot?

Is your vmlinuz.new on a partition that got unmounted by the time the kexec try to load into memory?

[Goverp]

OK, after some tests, I find rather usefully that issuing:

[pingtoo]

I think

[Hu]

At the risk of diverting the thread, I want to note that for some initramfs testing, a throw-away qemu virtual machine with no attached network and no usable installed system can be a decent alternative. It can bring up the kernel and initramfs, run through the initramfs logic, and if you provide a dummy disk with appropriate partitions/LVM/LUKS (depending on what the initramfs wants), work through to where the initramfs tries to transfer control to the installed system. (It will likely fail at that point, but if you can reach the end of the initramfs, that may suffice to prove this is one you want to use for the real system.) This approach has the advantage of being very quick to iterate since it does not halt the original working system, so you can correct problems and rebuild readily. It has the disadvantage that you need to build some extra infrastructure to satisfy the initramfs's expectations about the environment.

[Goverp]

Been reading the kexec kernel archives. There seems to be a regression in 6.7.6 on some AMD machines that introduces the observed behaviour. I'll pursue this avenue if poss.
_________________
Greybeard

[pingtoo]

[pingtoo]

[Goverp]

I'd have to install the various software layers for a VM. Early printk is probably the wrong end, I think the "kexec -c" call is failing (there's no output in syslog), and that's at the end of the reboot process, not the start of the next kernel.

The trouble is I've already spent a couple of days, say 8 hours, on this, to shave perhaps 20 seconds off my reboot time, so it already takes 1,440 reboots to recover the outlay. If I continue to work on this, it's for fame and glory, not profit!

<edit>Typo: I meant "kexec -e", not "kexec -c" above.
_________________
Greybeard

[Zucca]

I guess I could test if this works with openrc-init -based system.
_________________
..: Zucca :..

[Goverp]

[pingtoo]

Goverp,

Have you try to boot directly from /boot/vmlinuz.new? (I mean without kexec)? I don't recall if we eliminate that it just a bad kernel build case.

Do your system boot with UEFI?

It just occur to me that if your /boot/vmlinuz.new is a efi stub kernel, if that is true that may be the reason we are not able to kexec boot. I don't have evident yet (still research code) but I believe kexec does not support PE32 header, so it will not understand how to boot into a efi stub kernel.

[Goverp]

[Goverp]

OK, tried the same kernel without EFIstub, still no joy. Again, kexec -l claims to load it OK, but kexec -e reboots to BIOS. I also tried with an older kernel, 6.6.8 or thereabouts (I'm on a different machine just now), though that one didn't have kexec support. It's not clear to me if kexec support is needed in the rebooting kernel or the rebooted kernel or both ...
Anyway. more debugging required.
_________________
Greybeard

[pingtoo]

[pingtoo]

After further study kernel code, Now I must correct my early statement about kexec not support EFI binary.

Actually kexec Do support EFI.

The only thing I have not yet to find out is how it work. All I can tell is it recognize a EFI binary in a bzImage format, I have just not yet find out how it find the kernel entry point in the bzImage, or if it is calling EFI service to perform reboot.

My apology for any confusion I made.

Goverp, I am sorry my suggestion lead to your extra work and time.

Govero, if you still willing to work with me, please continue do I suggest in my post for debugging. And I am OK and understand you feel last confident in me if you prefer not to.

[Goverp]

Pingtoo,
No problem, I'm grateful for any help! I'll get the answers for you later - it's a good day for gardening today, so I'll be out in the sun for now.
_________________
Greybeard

[Goverp]

OK, here's my config, as a pastebin,
and here's the output from

[Goverp]

I tried a minor experiment, running "kexec -de" in single-user mode ("openrc single"). That causes a reboot rather than issuing a warning message saying "don't do that in this run mode", but (a) it was still to BIOS and GRUB, and (b) still nothing in syslog, though of course that's one of the services that wouldn't be running, even though my rootfs would still have been writeable.
_________________
Greybeard

[pingtoo]

[Goverp]