I don't have enough understanding of where the problem lies, or how common these Radxa boards are, to give a meaningful vote at this time.

FinalBlocker 0

I am also experiencing this error with Pine 64 RockPro64. Unfortunately, my two other test boards, which I usually use for testing, are broken and cannot be easily replaced at the moment.

One Part of the error lies in the arm-image-installer program, which fails during an installation step with LVM that is necessary for Server. The consequence is that tFedora Server can in the Beta version not be installed on any SBC model at all.

ServerWG does not want to distribute an installation medium that simply fails in every use case. In that case, we would drop the SBC server variant completely.

The second part of this error is that even the minimal version, which does not use LVM, does not boot on either the Radxa Rock Pi 4 or the Pine64 RockPro64. Here, the cause may be specific to RockChip models. The Raspberry Pi 4 obviously boots minimal.

But the latter model is completely unsuitable for any serious use as a Fedora Server. The Radxa and Pine64 models, as well as a number of other RockChip-based models, have features that make them suitable for meaningful and serious use with Fedora Server (including fast network connectivity, fast NVMe storage, and a reasonably stackable device layout). If Fedora Server cannot boot on these boards, that would also be a reason to drop the SBC Fedora Server image completely. We are currently not aware of any other board that is suitable for Fedora Server and that we have been able to test for correct functionality.

If anything, we would then only support SBC boards for which an EDK2 BIOS is available and which can be installed using the aarch64 ISO DVD (including Radxa Pi5 Model b). This still needs to be discussed with ARM SIG.

@pboy is there a bug report for the general LVM issue? is it nominated as a Final blocker?

yes, it is the bug you proposed as final blocker

https://bugzilla.redhat.com/show_bug.cgi?id=2391231

Discussed at the 2025-09-15 (blocker / freeze exception) review meeting:

This is being rejected as it is specific to the Server aarch64 disk image, and that image is not release-blocking, as per https://docs.fedoraproject.org/en-US/releases/f43/blocking/. It is being accepted as a FE as it is evidently a significant bug that cannot be fully resolved with a post-release update.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-15/f43-blocker-review.2025-09-15-16.00.txt

AGREED RejectedFinalBlocker
AGREED AcceptedFinalFreezeException

The following votes have been closed:

• Accepted FinalFreezeException (+0, 0, -0)

The following votes have been closed:

• Rejected FinalBlocker (+0, 1, -0)
  • 0 by nielsenb

I don't have enough understanding of where the problem lies, or how common these Radxa boards are, to give a meaningful vote at this time.

They are extremely common, and this affects all deployments of Server, not just specific boards.

FinalFE +1

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