Re: [PATCH v4 1/1] Add support for grub-emu to kexec Linux menu entries

[Oskari Pirhonen]

On Tue, Oct 18, 2022 at 15:26:45 -0400, Robbie Harwood wrote:
> Oskari Pirhonen <xxc3ncoredxx@gmail.com> writes:
> 
> > On Tue, Oct 04, 2022 at 15:16:48 -0400, Robbie Harwood wrote:
> >> From: Raymund Will <rw@suse.com>
> >> 
> >> The GRUB emulator is used as a debugging utility but it could also be
> >> used as a user-space bootloader if there is support to boot an operating
> >> system.
> >> 
> >> The Linux kernel is already able to (re)boot another kernel via the
> >> kexec boot mechanism.  So the grub-emu tool could rely on this feature
> >> and have linux and initrd commands that are used to pass a kernel,
> >> initramfs image and command line parameters to kexec for booting a
> >> selected menu entry.
> >> 
> >> By default the systemctl kexec option is used so systemd can shutdown
> >> all of the running services before doing a reboot using kexec.  But if
> >> this is not present, it can fall back to executing the kexec user-space
> >> tool directly.  The ability to force a kexec-reboot when systemctl kexec
> >> fails must only be used in controlled environments to avoid possible
> >> filesystem corruption and data loss.
> >> 
> >
> > Can the existence of systemd/systemctl be checked at configure-time?
> 
> No - think about how binary distros work.  Only on locally built
> environments like gentoo is configure time guaranteed to look like
> runtime.  Consider Debian, for instance, which can run with multiple
> init systems (including openrc, if memory serves): for them, a
> configure-time check could make things worse.
> 

My idea was something along the lines of --with-kexec=foo in order to
allow for automatic detection as well as manually specifying the method
used. I believe that should cover building for binary distros as well as
locally.

> > I run OpenRC where systemctl is unavailable, so it looks like it would
> > always hit the error case unless I pass the arg twice. It could also
> > cause confusion to users if they notice it fails to call systemctl
> > when on non-systemd systems.
> 
> I don't think this has the impact you're suggesting.  This is new code -
> you can't kexec from grub2-emu today.  It's also working as documented
> ("use kexec to boot Linux kernels via systemctl (pass twice to enable
> dangerous fallback to non-systemctl).").  I don't think a user reading
> that documentation would expect a system without systemctl functionality
> to support this feature.  (Whether users expect their system to have
> systemctl functionality is better asked of initsystem developers than of
> me.)
> 

These are valid points for the current (and possibly final) state of
this patch.

> I want to be clear here that I support people working on other init
> systems, but if there's not an equivalent for this functionality,
> there's very little I can do here.
> 

The most that I would be requesting be added is basic scaffolding to
make future additions easier. But if no one comes forward before the
patch is accepted as ready, saying there's an equally easy method to
`systemctl kexec` for some other init system, then it wouldn't make
sense to add it until said method can be added too.

> > The simplest/safest solution would be to just disable this if the
> > configure check fails until `systemctl kexec`-equivalent code paths are
> > added.
> 
> Careful with langauge, please.  There is nothing unsafe about attempting
> to exec systemctl when it doesn't exist.  And I don't think adding
> configuration checks makes code simpler.
> 

I meant "safe" in the sense that it's a controlled kexec reboot, not
that running a non-existent systemctl is unsafe. Apologies if that was
unclear.

> > I've CC-ed the Gentoo Base System project [1] in case some of them can
> > provide additional input, such as how to get the safe path working
> > with other init systems.
> 
> Okay.  Any input here is fine, but I think it will be easier for
> everyone if it's in the form of separate, follow-up patches.  (I'm happy
> to review them once posted, if that's helpful; just CC me.)
> 

You are probably right on that, which is why I wanted to get the idea
out there at least.

I will do some more digging myself too.

- Oskari

signature.asc
Description: PGP signature