Hi, On 16-Dec-25 2:13 PM, Neal Gompa wrote: > On Tue, Dec 16, 2025 at 5:54 AM Gerd Hoffmann <[email protected]> wrote: >> >> Hi, >> >>> The following are considered out of scope for this specific change, these >>> could be looked at for a future change proposal. For this specific change >>> the intent is to keep the changes minimal: >>> * Stubble is a fork of systemd-stub there is no reason why the same should >>> not be possible with systemd-stub. Testing has shown that ATM using >>> systemd-stub this way does not work, why this does not work has not been >>> investigated yet. For now we are going with Stubble. >> >> /me looks a bit surprised that you don't even investigate why >> systemd-stub does not work before going to package the stubble fork ... >> > > Well, does sd-stub have the DTB selection stuff for a series of > embedded DTBs?
systemd-stub does have the same auto DTB selection support which Stubble has. > I thought that's kind of the point of stubble. TBH I don't really understand what the point of Stubble is, I went with Stubble for now because it works, where as systemd-stub does not work. To answer's Gerd question: >> /me looks a bit surprised that you don't even investigate why >> systemd-stub does not work before going to package the stubble fork ... My primary reason for going with Stubble for now is simply how much time I've to spend on this. This is not my highest priority at Qualcomm so I'm mainly doing this as a side-project and in my own free time. Also we need a source of the json files which map DMI strings + panel EDID to which DTB to use. Stubble provides these json files and systemd-boot does not. So we need to package Stubble anyways even if just for the json files. I did just retry using systemd-stub and this time I got / noticed an error message which I did not get / notice last time. The error is about not being able to install an initrd loadfile2 EFI protocol handler, because GRUB has already done that (which is what we want). This is a bit weird, because I checked the systemd-stub code and it only tries to do this if there is an initrd section in the vmlinuz PE EFI binary. It might be that ukify adds an empty initrd section when not specifying one; or maybe the stub checking if the initrd section is there before installing the loadfile2 protocol handler is relatively new and not in the 258.2 build in Fedora. Eitherway this does look fixable and I would prefer to go with systemd-stub upstream instead of the Stubble fork. When I can make some time I'll try to see if I can fix things with systemd-stub and if that works I'll update the change proposal. >>> * The vmlinuz EFI with the Stubble stub and DTBs embedded should work fine >>> as the main vmlinuz image for all boards, but this may require changes to >>> U-Boot builds without an EFI payload and this will need testing on many >>> different boards. >> >> Also note that we already have a UKI build for VMs (kernel-uki-virt.rpm). >> How is this affected by the change? >> > > Probably not at all, since it would be a separate sub-build? Exactly what I was going to say, the new UKI-light for this will sit in a new kernel-dtbloader subpackage. I've been working on making the kernelspec file for this and I'm thankful for the existing uki-virt support, since I can just copy and paste most of it for the new kernel-dtbloader sub-package. These changes will not touch the existing uki-virt support in any way. 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
