You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
Per the UKI spec (emphasis mine):
Optionally, one or more compiled Device Trees, for systems which need it, each in its separate .dtb section. If multiple .dtb sections exist then one of them is selected according to an implementation-specific algorithm.
However, ukify currently only supports inserting one DTB into the UKI.
(also, kernel-install has the same issue, let me know if I should open a separate issue for that)
Describe the solution you'd like
In the case of a family of devices that can share a kernel + initramfs, but differ only in the devicetree they require to boot, it would be nice if ukify could support adding multiple devicetrees to the UKI. The obvious approach I can think of from the top of my head is to support multiple Devicetree= settings in the [UKI] section, with each subsequent declaration being additive to the previous.
I understand that this is something that bootloader itself needs to support, and probably few do right now (though I'm working on a very niche one right now that would support this). But really, as ARM UEFI booting becomes more popular, I think folks will run into this situation more.
Describe alternatives you've considered
I don't think there's any alternatives besides not using ukify to generate the UKI, or not using UKIs at all.
The systemd version you checked that didn't have the feature you are asking for
255
The text was updated successfully, but these errors were encountered:
I have been experimenting on Fedora/RISCV side with Kiwi to generate Generic Cloud UEFI UKI images. I am able to direct boot from from EDK2 shell in QEMU without issues.
Fedora generates UKIs with dracut, which at first glance does not seem to support passing DTB(s) at all. Ukify tools seems to support passing DTB (only one).
I wonder if this could work on RISCV SBCs (EDK2 and U-Boot, both provide UEFI interface). UKIs would need to have multiple DTBs and something to select one automatically.
Actually we might need a way to handle different bootargs too. I wonder if this could be taken from bootargs in DTB.
Actually we might need a way to handle different bootargs too.
I haven't really encountered any situations where different bootargs per DTB are necessary. And I kinda hope such a thing is not necessary 😅 In that case, I think one could actually stuff the authoritative cmdline into /chosen for that particular devicetree anyway.
I think multiple DTBs stuffed in a UKI is a somewhat niche feature, the only times you would need it is if you're a poweruser neckbeard and want to prepare an SD-card/USB that can boot on 2 or more different ARM devices, or you're a dsitro-developer and want to prepare a live ISO with a kernel that can boot on multiple device families.
Fedora generates UKIs with dracut, which at first glance does not seem to support passing DTB(s) at all. Ukify tools seems to support passing DTB (only one).
Yes, I ran into the same issue with Arch - mkinitcpio just pretends DTBs don't exist (but that's forgivable since Arch is, at this moment, still officially x86 only)
Component
other
Is your feature request related to a problem? Please describe
Per the UKI spec (emphasis mine):
However,
ukify
currently only supports inserting one DTB into the UKI.(also,
kernel-install
has the same issue, let me know if I should open a separate issue for that)Describe the solution you'd like
In the case of a family of devices that can share a kernel + initramfs, but differ only in the devicetree they require to boot, it would be nice if ukify could support adding multiple devicetrees to the UKI. The obvious approach I can think of from the top of my head is to support multiple
Devicetree=
settings in the[UKI]
section, with each subsequent declaration being additive to the previous.I understand that this is something that bootloader itself needs to support, and probably few do right now (though I'm working on a very niche one right now that would support this). But really, as ARM UEFI booting becomes more popular, I think folks will run into this situation more.
Describe alternatives you've considered
I don't think there's any alternatives besides not using ukify to generate the UKI, or not using UKIs at all.
The systemd version you checked that didn't have the feature you are asking for
255
The text was updated successfully, but these errors were encountered: