On Tue, Oct 18, 2022 at 15:26:45 -0400, Robbie Harwood wrote: > Oskari Pirhonen <xxc3ncore...@gmail.com> writes: > > > On Tue, Oct 04, 2022 at 15:16:48 -0400, Robbie Harwood wrote: > >> From: Raymund Will <r...@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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel