(resending because I had to subscribe to get through) Hi,
as someone who worked on stubble I think I might be able to help clear a few things up. On Wed, Jan 7, 2026 at 1:05 PM Hans de Goede <[email protected]> wrote: > > Hi, > > On 17-Dec-25 12:02, Lennart Poettering wrote: > > On Mi, 17.12.25 10:24, Hans de Goede (hans(a)hansg.org) 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). That is an issue we also hit when we first experimented with UKI and systemd-stub. There was a PR that would make it use the grub loaded initrd if which was rejected https://github.com/systemd/systemd/pull/35978 because it doesn't align with the idea of UKI. Since our own goal for now was really only solving the dtb loading problem rather than adopting UKI as a whole we decided to take the bits from systemd stub that solve our problem and drop all the features we don't need to reduce complexity and attack surface. We did upstream all the bug fixes and functional changes in the shared code so there should not be anything missing in systemd-stub feature wise. I am happy to create a PR with the json files if upstream thinks that is a good idea. For now we have contributed the hwids to https://github.com/TravMurav/dtbloader/ which currently has the most comprehensive database of hwids I am aware of. > >> > >> 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. > fwiw there was a bug in systemd-stub which broke the grub linux command, see https://github.com/systemd/systemd/issues/38567 I fixed it in stubble and systemd-boot so I am pretty certain that it works now. > >> 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. That is similar to our situation in Ubuntu. Grub is currently the default and migrating boot loaders would mean significantly more work and is not something we could realistically have achieved ahead of the next LTS. With stubble we have a combined kernel image that looks like just another kernel binary to grub and the rest of the system except it also loads device trees when needed. It is purely a build time change in the kernel packaging and didn't require any changes to grub or the boot configs. I am in not ruling out that it is only an intermediate step until we tackle the bigger issues in the boot area but for us it works well for what it was designed to do. Please feel free to reach out if you have any more questions! Regards, Tobias -- _______________________________________________ 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
