Libre Computer boards support Fedora RAW images. For Fedora 38 and below, the older kernel is not compatible with Amlogic GXL family Ethernet device-tree changes so a few modifications are necessary.
For BIOS/SystemReady boards, Fedora should be supported out of the box. Just burn the extracted Raw image and flash it directly to a storage device.
For Le Potato, Tritium, and Renegade, Fedora requires a bootloader to be implanted into the image before it will boot.
Fedora Minimal Fedora Minimal
Other variants may work with the same instructions but they have not been tested.
Fedora 39 Modifications for Le Potato / Renegade / Tritium
Bootloader via libretech-flash-tool
Fedora 39 Modifications for other boards
None Necessary
Fedora 38 Modifications for AML-S905X-CC Le Potato / ROC-RK3328-CC Renegade / ALL-H3-CC Tritium H5
Bootloader via libretech-flash-tool
Fedora 38 for AML-S805X-AC La Frite / AML-S905X-CC Le Potato / AML-S905X-CC-V2 Sweet Potato / AML-S905D-PC Tarteflette
Due to older kernel version, the builtin device tree is not compatible with Linux < 6.4 Ethernet MDIO driver. We recommend using Fedora 39 for these boards.
I have tried it, but the only result I got was a corrupt primary GPT table. After restoring the previous GPT table it still doesn’t boot. Does restoring the GPT table also restore the previous bootloader?
You need to use MBR for Le Potato. The bootloader conflicts with the GPT tables.
The other option is to split the bootloader and the image. You can use SD card or eMMC for the bootloader and any other device for the image (USB/SD/eMMC).
Thanks, that was the crucial piece of information. The CoreOS images use GPT. I ended up using Fedora IoT (those images use MBR), and it worked like a charm. Here are the steps I took to install it on Le Potato, in case it can help someone else:
Not sure about this vs regular dd. We always shy away from magic userspace tools.
We hope to have our own infrastructure for Fedora up in the next quarter so we can deploy our kernel as it has many changes from vanilla upstream for patches that cannot go directly upstream.
There isn’t that much magic in the arm-image-installer-script. It uses dd to write to the SD card, and I found it easy enough to understand to trust it. Though I understand why you prefer standard tooling.
I found it very practical to not have to resize the filesystem, or add my public ssh-key to the authorized_keys of root manually. It would be great if that could also be part of the future infrastructure.