Without further justification, I'm:

FinalBlocker -1

The "no broken packages" criterion says "There must be no errors in any package on the release-blocking images which cause the package to fail to install." AFAICS, this bug does not break that criterion. The grub2 package installs just fine. It has a bug in a specific scenario which does not seem to come close to violating any of the Fedora release criteria.

It will break upgrades for any Fedora ARM system that uses DeviceTree. If DeviceTree blob files need to be updated or are updated as part of a kernel update, they will not be copied in place and thus the new environment won't boot properly.

Ah, that makes it more significant. Do any of our supported platforms (still) use devicetree? I thought we were trying to shift things to UEFI?

note, though, the update is not stable and does not fix any currently-accepted blocker or FE, so it's not in line to be in the release at present anyway.

This will break the boot on most (all?) aarch64 hardware that do not have a firmware provided dtb.

FinalBlocker +1

Critteria:
"Release-blocking ARM disk images must boot to the initial-setup utility."

FinalBlocker +1

Ah, that makes it more significant. Do any of our supported platforms (still) use devicetree? I thought we were trying to shift things to UEFI?

Even if we use UEFI-ish environments to boot Linux, we still use DeviceTrees for everything. That's true in Fedora Asahi, Fedora ARM for Raspberry Pi, and pretty much everything else people commonly use Fedora ARM for.

The only exceptions to this in common use that I'm aware of is if Fedora ARM is used on a Raspberry Pi with the RPi UEFI software and Fedora Cloud for ARM. Both of those cases are "true" UEFI environments that do not rely on DeviceTree and use ACPI instead.

sigh, this got erroneously proposed again because of the dupe. it does not need to be a blocker. the bug is not in stable and will not be in stable.

Release F39 is no longer tracked by BlockerBugs, closing this ticket.