Even with the latest branched compose we still have the bug in arm-image-installer. The proposal to treat this as a release blocker was rejected. However, it is a freeze exception, so a fix can still be added very late in the release process. The status of the bug (https://bugzilla.redhat.com/show_bug.cgi?id=2391231) is still “new”. It looks as if no one has taken care of it yet.
Another problem is that the image produced, is very likely not bootable at all, even if the bug in arm-image-installer gets fixed. In any case, neither the minimal image nor the workstation and XFCe images that do not use LVM and work for arm-image-installer, do boot with the current release 43 build. This has been verified for the Radxa Pi 4 and the Pine64 RockPro64 and presumably affects all RockChip models. However, these are precisely the models that are particularly suitable for Server. And so far, we have no evidence that any SBC other than the Raspberry Pi 4 can be installed.
The release is scheduled for October 28, and the freeze date is October 7. That leaves about four weeks to fix the problem. In about two weeks, we should decide how to proceed in a worst-case scenario. One possible alternative would be to simply do nothing and let things run their course, i.e., intentionally release a non-functional release. The alternative would be to drop the image and possibly publish a note on our documentation on the download page with information on how Fedora Server can still be used on an SBC (fallback to F41 and step-by-step DNF upgrade). Otherwise, this could be included in the release notes and common bugs.
This is now the second time that we are about to publish a non-functional server release. We should consider in the long term whether we want to put ourselves through this mess on a more or less regular basis. Unlike IoT and CoreOS, which have their own separate release process and can make their own decisions, we are integrated into the general Fedora process and are only a small part amongst a large number of different desktops. We can only gain reliability and predictability if the Server SBC release becomes a blocker criterion again. As Adam discovered, this was the case for up to a 2x release for the 32-bit Arm image and was not carried over to the transition to 64-bit.
I suggest we look into this option. If that's not acceptable, we should still publish the SBC image for current users with the next release (F44), but at the same time declare it deprecated and drop it completely with the release after that. Fedora could continue to produce the image and publish it on the alternative/experimental versions page, but no longer under Server Downloads.
We could continue to leave the section about SBCs in our documentation for users/interested parties and otherwise focus on SBCs that have SR-compatible firmware and can be installed with the standard aarch64 ISO. This works very well with the Radxa Rock 5, for example, where the manufacturer also supports the EDK2 firmware. A variety of other models from the newer board generation are also supported, but I have not yet been able to test them. In terms of performance, we would then be in a range where the boards can compete with Intel or AMD mini servers (e.g., based on N100) and have some advantages over them. So these are seriously useable devices.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
server@lists.fedoraproject.org
-
Peter Boy