Hi, On 17-Dec-25 12:02, Lennart Poettering wrote: > On Mi, 17.12.25 10:24, Hans de Goede ([email protected]) wrote: > >>> I have no idea why canonical forked sd-stub, I guess Canonical just does >>> Canonical things... They haven#t submitted any PRs for that mapping >>> data though. >> >> ATM systemd-stub (258.2) does not work when loaded from GRUB >> with GRUB having loaded the initrd itself first. There is some >> error about not being able to install the initrd (the loadfile2 >> EFI protocol handler) because there already is one (the one >> installed by grub). >> >> Reading the git systemd-stub code we should only get that error >> if there actually is an initrd section in the UKI, which there >> should not be for how I'm invoking ukify. > > Well, sd-stub picks up additional resources from side-car dirs, such > as credentials, and turns them into initrds on-the-fly. So there's a > good chance there's an initrd, if you have sidecars.
Ah that is good to know when I start working on debugging this. >> I've gone with stubble for now for convenience reasons (*), but >> I agree that the whole existence of the Stubble fork is dubious >> and for long term maintenance I've more faith in systemd upstream. >> So I'll try to get things working with systemd-stub when I can >> make some time for this. Once I've that working I'll update >> the proposal accordingly. >> >> Lennart one question for you. The way this will be using >> systemd-stub without an initrd and with the not-quite-a-UKI >> being loaded by GRUB through GRUB's "linux" command (so not >> just chainloaded), is a mismatch for how systemd upstream >> envisions systemd-stub to be used. > > I have no idea what grub does "through the linux command", but if that > just jumps into the embedded kernel directly without going through > UEFI PE execution stub, then of course, systemd-stub is neutered and > cannot do anything. If however, it just jumps into the EFI entrypoint > in the UKI, then everything should be good (though I am not sure why > one would call an EFI PE chainloading command "linux", but hey, I am > just a simpleton). For upstream GRUB the linux command just does an EFI image-load + image start calls just like a chainload. The only difference is that the linux command installs the loadfile2 proto handler if an initrd was specified which is why this needs to go through the linux command. Fedora's GRUB has some patches trying to execute the EFI binary itself, these are hardcoded to the PE binary section layout of a plain vmlinuz.efi build and break with the stub. I'll take care of getting this fixed, preferably by just reverting to what upstream GRUB does. >> Would systemd upstream be willing to "support" this setup; or >> at least commit to not breaking this setup and willing to take >> patches to unbreak things if they do accidentally break? > > I have no idea what that means specifically. However: systemd-stub > certainly degrades gracefully if invoked in lesser-featured > contexts. For example, if you invoke it via UEFI HTTP boot (i.e. → > without any fs backing) we are fine with that, and know what to > do. And yes, if you run systemd-stub in some weird environment where > we cannot derive an fs protocol from the loaded image, then we handle > that gracefully, and skip over loading sidecars (i.e. addons, sysexts, > creds, confexts, …), because there's simply nothing we could load. Ok, so this reads to me that generally speaking using systemd-stub in the somewhat special setup we plan to use here should be fine and if we hit any issues that (clean/simple) patches to fix those should be accepted upstream since systemd-stub already tries to gracefully fallback in various cases. > (But of course, the fact you guys always want to keep grub in the mix, > even if it doesn't implement the relevant uefi protocols is really > sad. Ossifying around grub, uh...) FWIW I agree that GRUB, with its own FS drivers and everything makes little sense in an UEFI environment where we can just have the UEFI firmware do most things for us. PErsonally I would like to see Fedora move to a more KISS bootloader like e.g. systemd-boot but making big changes like this is outside my control and certainly out of scope for this change proposal. Regards, Hans -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
