Hi Tobias, On 7-Jan-26 2:20 PM, Tobias Heider via devel wrote: > as someone who worked on stubble I think I might be able to help clear > a few things up.
Thank you for reaching out and hopefully we can work together on this in the future and avoid doing duplicate work. > 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. I understand. I've managed to make things work with systemd-stub, this requires 2 changes: 1. Do not add an .osrelease section to the generated UKI, so that systemd-stub will not try to append a dynamic initrd with os-release info to its list of initrds leaving the list empty, at which point it will not try to install its own loadfile2 EFI proto handler. 2. A small bugfix to systemd-stub to fix it crashing when the initrd list is empty: https://github.com/systemd/systemd/pull/40329 As it seems we've both found out, 1. is also desirable to stop ssytemd-boot and kernel-install from treating the DTB-auto-loading stub, but not really an UKI kernel image as a full blown UKI. I was just about to start working on modifying ukify to allow creating UKIs without an .osrel section when I noticed: https://github.com/systemd/systemd/commit/75890d949f92c412c0936b8536b2e0dc8f7dfb40 so it looks like your colleague Nick Rosbrook has already taken care of this, thank you! > 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. If you could do that, that would be great. If we can get the json files included in systemd, then you could consider switching to systemd-stub (1) for the Ubuntu images too and at that point there will be no more need to maintain the stubble-fork, so that means less work for everyone. 1) Assuming https://github.com/systemd/systemd/pull/40329 will get merged >> 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. This is indeed the same as the Fedora situation. > 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. Ack and thank you for your work on this. When I started looking at doing something similar for Fedora, having your writeup at: https://discourse.ubuntu.com/t/spec-stubble-a-secure-boot-friendly-device-tree-loading-efi-stub/66278 explain what Ubuntu is doing; and perhaps even more importantly why; was very helpful. 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
