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. > 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). > 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. (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...) Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
