ARM64 Architecture Support#

ARM64/aarch64 support in Bluefin is limited to LTS variants only. All Fedora-based release streams (gts, stable, latest, beta) are AMD64-exclusive. The LTS-HWE (Long-Term Support with Hardware Enablement) stream is the only actively maintained ARM64 variant, built monthly on CentOS Stream 10 with the CoreOS kernel.

Architecture selection is determined at installation time through ISO variant choice. The same container image tags serve both AMD64 and ARM64 architectures, with the container runtime automatically pulling the correct build. Cross-architecture rebasing is not supported—switching from AMD64 to ARM64 (or vice versa) requires a fresh installation.

ARM64 users face several platform-specific limitations: no ZFS filesystem support, no NVIDIA GPU variants, no Broadcom WiFi driver compatibility, and restricted access to newer Fedora-based features. These constraints stem from Bluefin's architectural decision to concentrate ARM64 support in the stable, long-term maintenance stream rather than tracking the latest Fedora releases.

Architecture Support by Release Stream#

The standard LTS variant supports ARM64 but is currently disabled due to Anaconda installer compatibility issues. LTS-HWE is the recommended path for all new ARM64 installations.

LTS-HWE: Recommended ARM64 Variant#

Bluefin LTS-HWE is based on CentOS Stream 10 with the CoreOS kernel providing enhanced hardware support through akmods. This variant prioritizes stability and long-term support over cutting-edge features.

Key characteristics:

• Container image: ghcr.io/ublue-os/bluefin:lts-hwe
• Kernel: CoreOS kernel with hardware enablement modules
• Desktop: GNOME 49
• Filesystem: XFS (not BTRFS)
• Flavors: Main only—no NVIDIA variant available for ARM64
• Build schedule: Monthly on the 1st at 2am UTC

The "HWE" suffix indicates Hardware Enablement, distinguishing this stream from the standard LTS variant by using the CoreOS kernel with additional driver support rather than the stock CentOS kernel.

Download and Installation#

Downloading ARM64 ISOs#

ARM64 ISOs are distributed through the same channels as AMD64:

• Primary: https://download.projectbluefin.io/
• Documentation: https://docs.projectbluefin.io/downloads/
• BitTorrent: FOSS Torrents - Project Bluefin

There is no architecture-specific download selector—the architecture is encoded in the ISO filename (e.g., bluefin-lts-hwe-aarch64.iso).

Installation Requirements#

ARM64 installations require UEFI boot mode; BIOS mode is not supported. Key requirements:

• Boot mode: UEFI required, BIOS unsupported
• Secure Boot: Supported by default
• MOK enrollment: Password: universalblue after first boot
• Installation time: Approximately 20 minutes
• Filesystem: XFS default (not BTRFS)

Website Download Selector#

The ImageChooser.vue component implements download selection logic on the Bluefin website:

• Stable release lists supportedArch: ['x86'] only
• LTS release lists supportedArch: ['x86', 'arm']
• Selecting ARM architecture forces the stream to LTS
• HWE suffix is added for LTS non-NVIDIA builds
• Architecture suffix mapping: x86 → x86_64, arm → aarch64

Platform-Specific Limitations#

No ZFS Filesystem Support#

While ZFS akmods technically support both x86_64 and aarch64 architectures, ZFS is only available in the gts and stable streams, which are AMD64-exclusive. ARM64 systems cannot use ZFS because LTS variants do not include ZFS support.

No NVIDIA GPU Support#

NVIDIA variants (nvidia-open) are built for AMD64 only. ARM64 LTS-HWE provides only the "main" flavor without NVIDIA driver integration. ARM64 NVIDIA systems use the 'sbsa' architecture naming convention in the build scripts, but no public NVIDIA ARM64 variant exists.

Broadcom WiFi Driver Incompatibility#

The broadcom-wl akmod build script is x86_64-only and explicitly skips aarch64. Legacy Broadcom wireless adapters requiring the proprietary wl driver will not function on ARM64 systems.

Limited Variant Selection#

ARM64 users cannot access:

• Fedora-based streams (gts, stable, latest, beta)
• Developer Experience (DX) variants with pre-installed development tools
• Beta or testing streams for early access to features

Container Images and Rebasing#

Multi-Architecture Container Images#

Container images use identical tags for both AMD64 and ARM64 architectures. The container runtime (Podman) automatically pulls the appropriate architecture based on the host system. Multi-architecture manifests are created through podman manifest commands that combine separate platform builds into a unified reference.

Example image references:

# Same tag works on both AMD64 and ARM64
ghcr.io/ublue-os/bluefin:lts-hwe
ghcr.io/ublue-os/bluefin:lts
ghcr.io/ublue-os/bluefin-dx:lts-hwe # DX variant

Rebasing Between Streams#

You can switch between compatible streams on the same architecture using bootc switch:

# Switch to LTS-HWE (recommended for ARM64)
sudo bootc switch ghcr.io/ublue-os/bluefin:lts-hwe
sudo reboot

# Switch to standard LTS (not recommended - currently broken)
sudo bootc switch ghcr.io/ublue-os/bluefin:lts
sudo reboot

Cross-architecture rebasing is not supported. You cannot switch from AMD64 to ARM64 or vice versa using bootc switch. Changing architectures requires a fresh installation.

Technical Implementation#

ISO Build System#

The reusable-build-iso-anaconda.yml workflow defines multi-architecture build matrices that combine platforms (amd64, arm64) with flavors (main, gdx, nvidia-open):

LTS-HWE matrix:

• Platforms: amd64, arm64
• Flavors: main
• Total: 2 ISOs (amd64 × main, arm64 × main)

Stable matrix (for comparison):

• Platforms: amd64
• Flavors: main, nvidia-open
• Total: 2 ISOs (no ARM64)

The workflow uses conditional runner selection:

runs-on: ${{ matrix.platform == 'amd64' && 'ubuntu-24.04' || 'ubuntu-24.04-arm' }}

ARM64 builds install podman as a build dependency, and artifact filenames include the result of uname -m to distinguish architectures.

Platform-Specific Code Adaptations#

Build scripts include architecture-specific logic:

Firefox configuration: The Flatpak setup script skips Firefox configuration on aarch64:

ARCH=$(arch)
if [ "$ARCH" != "aarch64" ] ; then
    # Configure Firefox only on x86_64
fi

Architecture detection: The Justfile uses uname -m for runtime architecture detection when selecting appropriate akmods:

ARCH=$(uname -m)
if [[ "${hwe}" -eq "1" || "${gdx}" -eq "1" ]]; then
    AKMODS_BASE="coreos-stable-${coreos_stable_version}"
else
    AKMODS_BASE="centos-10"
fi

Usage Examples#

Verifying System Architecture#

# Check current architecture
uname -m
# Output: aarch64 (ARM64) or x86_64 (AMD64)

# Display current image information
rpm-ostree status

# Check container image reference
rpm-ostree status | grep "image:"

Switching to ARM64-Compatible Stream#

# Switch to LTS-HWE (recommended for ARM64)
sudo bootc switch ghcr.io/ublue-os/bluefin:lts-hwe
sudo reboot

# After reboot, verify the new image
rpm-ostree status

Manual ISO Download#

# Download LTS-HWE ARM64 ISO and checksum
curl -LO https://download.projectbluefin.io/bluefin-lts-hwe-aarch64.iso
curl -LO https://download.projectbluefin.io/bluefin-lts-hwe-aarch64.iso-CHECKSUM

# Verify the download
sha256sum -c bluefin-lts-hwe-aarch64.iso-CHECKSUM

Relevant Code Files#

Related Topics#

• LTS (Long-Term Support) Documentation — Comprehensive guide to Bluefin LTS variants, including LTS-HWE
• Image Rebasing — Using bootc switch to change between Bluefin streams
• ZFS Filesystem Support — ZFS availability in Bluefin (AMD64 only)
• WiFi Driver Compatibility — Including Broadcom driver limitations on ARM64
• Bluefin Image Naming Conventions — Understanding image tags and variant naming
• Bazzite GNOME — Alternative Universal Blue image with broader ARM64 hardware support