Hello everyone. Back in December 2025, I wrote about getting Fedora Minimal Rawhide running on BeagleY-AI. That post was mostly about getting it to boot at all, and the process involved arm-image-installer, manually copying U-Boot binaries into the boot partition, and chrooting into the SD card to regenerate the initramfs. Not exactly something I would recommend to someone who just unboxed a board.

Today, I am happy to share that Fedora is now available for BeagleY-AI directly in bb-imager. In this post, I will go over how to use it, how it works under the hood, and where things stand on the list of problems from the last post.

If you are curious about why I am doing this in the first place, the Motivation section of the previous post still applies. The short version: Fedora’s upstream-first approach makes it a great way to see the real upstream status of BeagleBoard SBCs, without the pile of downstream patches in our Debian images.

Flashing Fedora with bb-imager

Download and install bb-imager v1.0.17 or newer.
Select BeagleY-AI as the board.
Pick one of the Fedora images from the OS list. At the moment, only Fedora Minimal images are
listed. Other variants will be added in the future.
Select your SD card and flash.

NOTE: Flashing Fedora images is noticeably slower than flashing our Debian images. Fedora does not ship bmap files for its images, so bb-imager has to write the whole image instead of skipping empty blocks.

NOTE: bb-imager does not resize the root filesystem for Fedora images. Out of the box, the root partition will only be as big as the image itself, regardless of the size of your SD card. See Expand the Root Filesystem below.

Boot Fedora

Insert the SD card into the BeagleY-AI, connect to the UART console, and power it on. Like last time, you should be greeted by the systemd first-boot setup wizard over serial, and then a login prompt. Unlike last time, there is no need to regenerate the initramfs first. I have tested Fedora 44 Minimal flashed this way, and it boots without any issues. Ethernet works out of the box.

$ uname -a
Linux fedora 6.19.10-300.fc44.aarch64 #1 SMP PREEMPT_DYNAMIC Wed Mar 25 17:45:07 UTC 2026 aarch64 GNU/Linux

That is a stock Fedora 44 kernel, with no downstream patches.

Expand the Root Filesystem

Since bb-imager does not resize Fedora images, the root partition needs to be grown by hand after
the first boot. The following script figures out the root partition and its disk, grows the partition to fill the SD card, and then grows the filesystem:

ROOTPART=$(findmnt -no SOURCE /)
ROOTPART=${ROOTPART%%[*}                        # strip btrfs [/subvol] suffix
DISK=/dev/$(lsblk -no PKNAME "$ROOTPART")
PARTNUM=$(cat "/sys/class/block/${ROOTPART#/dev/}/partition")

echo "growing $DISK partition $PARTNUM"

echo ",+" | sudo sfdisk -N "$PARTNUM" --force "$DISK"
sudo partx -u "$DISK"
sudo systemctl start systemd-growfs-root.service

A few notes on what is going on here:

findmnt gives the device mounted at /. On btrfs, this includes a [/subvol] suffix, which gets stripped.
lsblk -no PKNAME gives the parent disk, and the partition number comes from sysfs, so there is nothing to fill in by hand.
,+ tells sfdisk to keep the partition’s start and extend it to the end of the disk. --force is needed since the partition is mounted. sfdisk also moves the backup GPT header to the end of the card, since it is still at the end of the original image.
partx -u tells the kernel about the new partition size, so no reboot is needed.
Finally, systemd-growfs-root.service grows the mounted root filesystem to fill the partition. It works for ext4, btrfs and XFS alike.

How It Works

The interesting part is that bb-imager is not hosting modified Fedora images. It flashes the upstream Fedora image as-is, and then puts the BeagleY-AI bootloader on top. This required changes in a few places.

Fedora OS list generation

bb-imager’s OS list is generated by bb-os-list-generator, which now knows how to discover Fedora images. A
couple of fun things came up here that needed follow-up fixes:

Fedora mirrors can be unreliable and occasionally fail for no apparent reason. Instead of failing the whole generation, images whose metadata can’t be fetched are simply skipped. Maybe there is a better way to handle this, but not quite sure.

Bootfs support in bb-imager

The main reason my previous post needed manual steps is that Fedora’s aarch64 images don’t contain the TI K3 bootloader binaries that BeagleY-AI needs (tiboot3.bin, tispl.bin and u-boot.img). So bb-imager gained the concept of a board-level bootfs:

Boards in the config can now declare a bootfs field, and there is a new SdCardNoBootloader flasher type for images that don’t carry their own bootloader (#769).
While flashing such an image, bb-imager downloads the board’s bootfs and writes it to the boot partition (#768, #769).

This is also useful beyond Fedora. The same mechanism can be used to recover or update the bootloader on an existing SD card, which was one of the use cases in the original feature request.

It also opens up possiblity for other distributions such as alpine, which provide raw disk images.

U-Boot releases publish their own OS list

The bootfs itself comes from the u-boot-beagley-ai repository:

The release workflow now packs tiboot3.bin, tispl.bin and u-boot.img into a single bootfs.tar.xz (#1).
It also generates an os_list.json for each tagged release, describing the BeagleY-AI board along with the URL, SHA256 and size of that tarball (#2).

Finally, bb-imager’s config was updated to pull in the os_list.json from the latest u-boot-beagley-ai release as a remote config. The nice part of this setup is that U-Boot updates for BeagleY-AI don’t need a new bb-imager release. Tag a new U-Boot release, and bb-imager picks up the new bootfs.

Revisiting the Old Future Plans

The last post ended with a list of missing pieces. Here is where they stand:

U-Boot in Fedora’s uboot-images-armv8: Still pending. The AM67A binary blobs needed to build U-Boot for BeagleY-AI are not in upstream linux-firmware yet, so Fedora still can’t build it as part of uboot-images-armv8. bb-imager shipping the bootloader is a practical workaround, not a replacement for this.
Initramfs missing irq-ti-sci-intr: Fixed. The kernel-ark MR that builds TI_SCI_INTR_IRQCHIP into the Fedora kernel was merged, so stock Fedora images can now read the SD card during early boot. The manual dracut step from the last post is no longer needed.
Native support in arm-image-installer: arm-image-installer can be used, but with bb-imager in place, it is not really needed anymore.
Wi-Fi: Not tested yet. Ethernet works, which is enough to get going for now.

Future Plans

More Fedora variants in bb-imager, beyond Minimal. XFCE would be particularly useful since Debian images also ship XFCE.
Automatic root filesystem resizing for Fedora images in bb-imager.
Faster flashing. Either getting bmap files for Fedora images, or finding a smarter way to skip empty blocks.
Continue pushing the missing bits (firmware blobs, U-Boot) into upstream Fedora, so that eventually bb-imager doesn’t need to supply its own bootloader at all.
Test Wi-Fi, then move on to display and other peripherals.
Expand to other boards such as BeaglePlay. I did actually try on PocketBeagle 2, but maybe due to only having 512 MB RAM, it just would not proceed after grub.

Ending Thoughts

That is all for this post. It is really nice to go from “here are 10 commands and a chroot” to “pick it in the imager”. If you have a BeagleY-AI lying around and are wishing to get into linux development, Fedora can be a good image to find things to work on.

Fedora on BeagleY-AI: Now in bb-imager