Hi, Lennart, thank you for your input.
Note replying to multiple replies from Lennart in one go. On 17-Dec-25 09:28, Lennart Poettering wrote: >> Can the addons live outside of the ESP space? I'd rather have them in >> /boot than in the ESP. > > The addons are supposed to be placed next to the UKI. sd-stub looks > for them in a subdir named like the UKI, suffixed with > .extra.d/. Hence, wherever you put the UKI, you can also put the extensions. ... > Add-on images are mostly about footprint: if the data is large you > don't have to blow up the UKI for everyone, but you can have some > level of modularity in place: use one UKI but have support for some > subset of devices in an optional add-on not everyone has to install. > > Frankly, I am assuming DTBs are not huge at least initially, hence I'd > not bother with add-ons (because having them is one thing, you must > also update/install/lifecycle them properly) for now, but at least you > know that in future there's clean avenue on what to do once size > issues become a constraint you have to deal with. The plan here is to have grub load the UKI and have the UKI under /boot (which may not readable by the UEFI fw) this also includes not having an initrd in the UKI, but also have the initrd under /boot. Basically we want to keep the existing flow of GRUB providing the kernel commandline + initrd and grub loading vmlinuz. IOW we want to keep the changes minimal, as Fedora generally speaking is not ready yet to go full UKI. So the idea is to only add a stub + embedded DTBs for autoDTB loading to the vmlinuz PE EFI binary. IOW this is not a proper / full UKI. So another reason for not going the addon route (for now) is that the stub will not be able to load addons from /boot. > Hmm, if this is generic data we can certainly look into shipping that > in our tree. I think that having these in the systemd git repo would indeed be good to have. > 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. 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. 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? Regards, Hans *) I wanted to have a working prototpye before submitting the change proposal. -- _______________________________________________ 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
