Step by step, with screenshots: install Fedora Server with an automatic kickstart, from download to an SSH session.

Native arm64, and only arm64 on ARM

Fedora on an Apple silicon Mac runs natively on arm64, like Ubuntu and Debian. Fedora Linux 44 ships for x86_64 and aarch64. 32-bit ARM was dropped some releases ago, so on ARM there's one build to choose.

Three ways in

  • Cloud image. Fedora 44 Cloud Base, downloaded from fedoraproject.org and checked against Fedora's published checksum. cloud-init creates your account and adds this Mac's SSH key on first boot, and it's ready in about a minute. The quickest way to a headless Fedora.
  • Automatic install. Choose Installer image, pick Fedora Server or Everything, and leave Automatic installation on. Velo Workspaces writes a kickstart file to a small disk labelled OEMDRV, which Anaconda picks up by itself. There's no confirmation step at all: the install runs start to finish and the workspace restarts into Fedora.
  • Workstation, by hand. Fedora Workstation's live image doesn't support kickstart, so it installs interactively in the workspace's display. Pick it when you want the GNOME desktop.

Fedora's aarch64 ISOs are built to boot from a CD, and Apple's Virtualization framework has no CD drive, only USB-style disks. Velo Workspaces gives its own copy of the ISO a partition table the firmware can boot from, and leaves the original file in your library untouched. Why Fedora's ARM ISO wouldn't boot tells how that came to light, with a script that does the same to any ISO.

The default that surprises people: SELinux, enforcing

Fedora ships SELinux in enforcing mode with the targeted policy. It isn't just installed, it's on. A service that binds a nonstandard port, reads from an unexpected directory, or gets restarted by a script in a way its policy doesn't expect can fail with what looks like a permissions error while the file permissions are fine. Ubuntu and a minimal Debian don't put you in that position by default.

The answer isn't to turn SELinux off. It's to check it first. When a service misbehaves for no visible reason, look for an AVC denial with journalctl, or run sealert against the audit log, before anything else.

Networking: NetworkManager

A Fedora installed by Anaconda uses NetworkManager, which you configure with nmcli and /etc/NetworkManager/, not Debian's /etc/network/interfaces or Ubuntu Server's Netplan. (The Cloud Base image is set up by cloud-init instead.) NetworkManager doesn't have the Netplan MAC-address problem that trips up cloned Ubuntu Server workspaces, but it is a different place to look when you need to change something.

Rosetta works differently here

Ubuntu and Debian register Rosetta through update-binfmts, a tool that manages the kernel's binfmt_misc entries for you. Fedora doesn't ship it. It uses systemd-binfmt, which reads the same kernel registration from a config file you write. The end result is the same, with x86-64 binaries handed to Rosetta, but the steps differ, so the support FAQ lists Fedora's separately: mount the rosetta share, write /etc/binfmt.d/rosetta.conf, and restart systemd-binfmt.

When Fedora makes sense

Fedora tracks upstream closely. New kernels and packages land here well before Ubuntu or Debian. The cost is a support window of about a year per release, which matters little for a disposable workspace you rebuild from a base image and a lot for a server you patch in place for years. Pick Fedora to test against current upstream versions, Debian when you want the base image to be the boring part, Ubuntu when your tools or CI assume it, and Rocky Linux when production runs RHEL.

Related reading: Ubuntu and Debian on Apple Silicon, the first two in this series; Rocky Linux on Apple Silicon, Fedora's RHEL-compatible downstream relative; the disposable VM workflow for QA and DevOps; and why VMs on Apple Silicon perform the way they do. Or download Velo Workspaces and try it yourself.