You have an M-series Mac and a Fedora ISO that won't boot
You just unboxed a MacBook with an M2 or M3 chip. You downloaded the Fedora ISO, created a bootable USB stick, and tried to install. The Mac ignores the USB drive. You try to boot from the ISO in recovery mode and the system refuses to recognize it. You are staring at a locked boot screen and a download page that offers an aarch64 ISO with no instructions for bare-metal installation.
The hardware is capable. The kernel supports ARM64. The barrier is the firmware. Apple Silicon Macs use a proprietary boot chain that requires signed bootloaders and specific firmware handshakes. The Fedora Project does not ship a bare-metal installer for consumer Apple Silicon Macs. You cannot install Fedora directly to the drive and expect it to boot alongside macOS. The only supported path is to run Fedora inside a virtual machine.
Apple Silicon boot architecture blocks third-party installers
Apple Silicon Macs do not expose a standard UEFI interface to third-party operating systems. The boot process is tightly coupled with the secure enclave and requires vendor-signed binaries. Fedora ships unsigned bootloaders to maintain security transparency and flexibility. The mismatch prevents the Mac firmware from handing control to the Fedora installer.
The kernel team is working on ARM64 drivers and boot support, but the firmware wall remains. You can run Fedora in a virtual machine. The hypervisor translates the ARM instructions efficiently, and the guest OS sees standard virtio devices. This approach gives you a full Fedora environment without bricking your hardware or waiting for upstream firmware support.
Virtualization on Apple Silicon is fast. The host macOS runs the hypervisor framework, and the guest executes native ARM instructions. Performance is close to native for most workloads. GPU acceleration is not available inside the VM. The desktop will use software rendering. This is acceptable for development, servers, and light desktop use. It is not suitable for video editing or gaming.
Run Fedora in a virtual machine
You have two practical options. UTM provides a graphical interface and handles configuration details automatically. QEMU gives you full command-line control and is scriptable. Both use the same underlying virtualization technology. Both require the aarch64 ISO.
Option 1: UTM for graphical management
UTM is a free QEMU front-end for macOS. It simplifies VM creation, manages disk images, and provides a window for the guest display. Use UTM when you prefer a GUI and want to avoid memorizing command-line flags.
Install UTM via Homebrew. Homebrew handles the app installation and updates.
brew install --cask utm
# Homebrew installs the UTM app to /Applications. The --cask flag tells brew to handle GUI apps rather than CLI tools.
Download the Fedora ISO. You need the aarch64 build. The x86_64 ISO will not boot on Apple Silicon hardware.
curl -LO https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/aarch64/iso/Fedora-Server-dvd-aarch64-41-1.4.iso
# -L follows redirects. -O saves the file with its original name. The URL points to the aarch64 build. Verify the checksum if you are paranoid.
Open UTM and create a new virtual machine. Select "Virtualize" and choose "Linux". Do not select "Emulate". Emulation runs software translation and is painfully slow. Virtualization uses the hardware hypervisor and delivers near-native performance.
Assign resources. Allocate at least 2 CPU cores and 4 GB of RAM. A desktop environment needs more RAM to run smoothly. A headless server can run on 2 GB. Attach the aarch64 ISO as the boot drive. UTM will detect the ISO and configure the virtual CD-ROM.
Boot the VM. The Anaconda installer will start. Follow the prompts to partition the disk and set up users. The installer detects virtio disks and configures the storage correctly. After installation, remove the ISO from the VM drive list and reboot. Booting from the ISO again will restart the installer.
Remove the ISO after install. The VM will reinstall if the ISO remains attached as the primary boot device.
Option 2: QEMU for terminal control
QEMU is the command-line virtualization engine. It offers granular control over machine type, CPU features, and device configuration. Use QEMU when you need to script VM creation or integrate the environment into a CI pipeline.
Install QEMU via Homebrew. The package includes the qemu-system-aarch64 binary and disk image tools.
brew install qemu
# Installs qemu-system-aarch64 and qemu-img. The aarch64 binary is required for ARM guests. The package also includes OVMF firmware.
Create a virtual disk. The qcow2 format supports sparse allocation and snapshots. The file starts small and grows as you write data.
qemu-img create -f qcow2 fedora.qcow2 40G
# qcow2 format supports sparse allocation and snapshots. The file starts small and grows as you write data. Raw format wastes space.
Boot the installer. The command line specifies the machine type, CPU, memory, firmware, and drives.
qemu-system-aarch64 \
-machine virt,accel=hvf \
-cpu host \
-smp 4 -m 4096 \
-bios /opt/homebrew/share/qemu/edk2-aarch64-code.fd \
-drive file=fedora.qcow2,if=virtio \
-cdrom Fedora-Server-dvd-aarch64-41-1.4.iso \
-boot d \
-nographic
# virt machine type provides paravirtualized devices. hvf enables Apple's hardware acceleration.
# Passes host CPU features to the guest. Improves performance.
# 4 cores and 4GB RAM. Adjust based on your workload.
# Points to the OVMF firmware. ARM guests require UEFI firmware to boot.
# Attaches the qcow2 disk as a virtio block device. Virtio is faster than emulated IDE.
# Mounts the ISO for installation.
# Boots from the CD-ROM.
# Disables GUI. Useful for headless or SSH access.
The installer runs in text mode. Configure the system and complete the installation. After installation, drop the -cdrom and -boot d flags to boot from the virtual disk. Add -nographic to keep the terminal session or remove it to use a graphical console with -vga virtio.
Drop the cdrom flag. The VM won't boot from disk if the ISO is still attached as priority.
Verify the installation
Once the VM is running, confirm the architecture and release version. The output should show aarch64 and the Fedora release number.
uname -a
# Displays kernel version and architecture. Look for aarch64 in the output. x86_64 indicates a wrong ISO.
cat /etc/os-release
# Shows the OS name and version. Verify PRETTY_NAME matches Fedora.
Check the network configuration. Fedora uses NetworkManager by default. The virtio network interface should be up and have an IP address.
nmcli device status
# Lists network devices. The virtio interface should show 'connected'. Run nmcli dev show if you need details.
Run journalctl -xe if the system fails to boot or services are missing. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Common pitfalls and error patterns
GPU acceleration is not available inside a VM on Apple Silicon. The desktop will use software rendering. GNOME will be sluggish with default settings. Allocate at least 4 GB of RAM and consider a lighter desktop environment like XFCE or a headless setup.
If you download the x86_64 ISO by mistake, the VM will refuse to boot. The hypervisor expects ARM instructions. You will see a kernel panic or a silent hang. Always grab the aarch64 ISO.
UTM has a setting for "Emulation". That runs software translation and is painfully slow. Select "Virtualization" to use the hardware hypervisor. The performance difference is massive.
Networking works via virtio drivers. Fedora ships these drivers in the kernel. The interface name might be eth0 or enp0s1. NetworkManager handles the configuration automatically. If the network is down, check the interface state.
ip link show
# Lists interfaces. Look for state UP. Run ip link set eth0 up if the interface is down.
Edit network configuration in /etc/. Never edit files in /usr/lib/. Package updates will overwrite /usr/lib/ and destroy your changes. Fedora follows the convention where /etc/ holds user modifications and /usr/lib/ ships with packages.
Choose your tool based on your workflow
Use UTM when you want a graphical interface to manage disk images and snapshots without memorizing flags. Use QEMU from the command line when you need to script the VM creation or integrate it into a CI pipeline. Use the native macOS environment when you require GPU acceleration for video editing or gaming. Stay on the VM path if you need a stable Linux development environment that matches your production servers.
Once installed, treat the VM like any Fedora system. Run dnf upgrade --refresh weekly to keep packages current. dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Trust the package manager. Manual file edits drift, snapshots stay.