The longer message which looks hacky says: "../src/boot/pe.c:339@pc_locate_sections: HWID matching failed, not DT blob will be selected: not found" This is _NOT_ a failure on most platform, ACPI particularly and should not be visible at all, and suggests that were the HWID actually found that it would load a DT when one should not be loaded. I will look at the code in a bit but am opening this now because at a minimum the code needs to detect that its on an ACPI platform and simply do nothing. Further, this suggests that the code around picking the latest/proper DT representation may not be able to distinguish say updated firmware tables vs whatever fedora is shipping too. Reproducible: Always Steps to Reproduce: 1. Grab F44 beta 2. Boot, and notice giant red error message Expected Results: There aren't any critical sounding messages on platforms where the firmware follows systemready guidelines. Additional Information: Marking as high, until I determine that this won't load DT tables when it shouldn't' be.
Thank you for reporting this. Note the kernel-uki-dtbloader vmlinuz PE binary now used on Live images (and on live images only) does not use the stubble EFI-stub, but rather the regular systemd-stub from systemd-boot-unsigned, changing component from systemd. About your worry of this loading a DTB on systems where it should not. This uses Microsoft CHID matching: https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/using-chids so unless for some reason some ARM systemready system has identical vendor + model / sku DMI strings as a non systemready system which actually needs a DTB this should never happen. TL;DR: I do not think this is something to worry about. > the latest/proper DT representation may not be able to distinguish say updated firmware tables vs whatever fedora is shipping too. The DTB's which are auto-loaded are part of the vmlinuz file and are build directly from the kernel dts sources when building that vmlinuz file, so they are always 1:1 version matched with the kernel. > at a minimum the code needs to detect that its on an ACPI platform and simply do nothing. This is unfortunately not possible, since one Windows on ARM laptops there are ACPI tables, but not ARM systemready ACPI tables. The whole goal of: https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems is to make these EFI + ACPI devices work out of the box by automatically selecting the right DTB to load in the EFI stub. This does leave the question of the ugly red error/warning. Since we do not expect there to always be a match, like e.g. on ARM systemready systems it looks like we will need to disable that message. Either with a downstream patch, or maybe have some way to add a setting to not show that warning to the generated vmlinuz image.
Here is a systemd[-boot] PR which should fix the big red error message: https://github.com/systemd/systemd/pull/40957 Rawhide PR adding this as a downstream patch for now: https://src.fedoraproject.org/rpms/systemd/pull-request/236 F44 PR adding this as a downstream patch for now: https://src.fedoraproject.org/rpms/systemd/pull-request/237
FEDORA-2026-61b3e313aa (systemd-260~rc3-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-61b3e313aa
FEDORA-2026-61b3e313aa (systemd-260~rc3-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.