The scenario
You just provisioned a bare-metal box or spun up a VM for a new project. The machine boots to a blinking cursor or a cloud-init prompt, and you need a clean Fedora Server base. You download the ISO, flash it to a USB drive, and boot. The Anaconda installer appears. You click through the screens, but halfway through you realize you have no idea what Btrfs subvolumes actually do to your disk layout, or why the installer insists on a root password when you plan to use sudo for everything. You finish the install, reboot, and immediately wonder if you missed a critical step that will bite you later.
What Anaconda is actually doing
Anaconda is not a simple script that copies files to a partition. It is a full installation environment that runs in a live session before your target system exists. When you boot the ISO, the kernel mounts a squashfs filesystem into memory. The installer then scans your hardware, detects disks, sets up the network, and prepares a target root filesystem. It writes the bootloader, configures storage, and drops the base packages onto the disk. Only after it finishes does it reboot into your new system.
Understanding this flow matters because mistakes during the install phase cannot be undone with a simple systemctl restart. A botched partition scheme or a misconfigured bootloader leaves you staring at a rescue shell. Treat the installer screens as configuration steps, not just prompts to click through.
Preparing the installation media
Start with the official Fedora Server ISO. The file is roughly 800 megabytes and contains everything needed for a headless or minimal desktop setup. Flash it to a USB drive using a reliable tool. dd works, but cp or a GUI tool like BalenaEtcher reduces the chance of a corrupted write. Verify the checksum before you boot. A bad write causes silent failures during package extraction.
# Mount the ISO and USB to verify integrity before booting
sha256sum /path/to/Fedora-Server-dvd-x86_64-42-1.6.iso
sha256sum /dev/sdX
# WHY: Matching hashes guarantee the installer won't fail mid-extraction due to bit rot or a bad flash
Boot the target machine from the USB. The GRUB menu on the ISO gives you three choices. The default entry boots the installer. The Troubleshooting menu contains a basic graphics mode and a rescue environment. The Test this media option verifies the ISO checksum against the USB drive before launching Anaconda. Use the test option if your USB drive is older than six months or if you suspect a flaky connection.
Verify the media before you trust the installer. Corrupted blocks cause package extraction failures that look like network timeouts.
Running the installer
Anaconda launches with a graphical interface. The first screen asks for language, keyboard layout, and time zone. These settings write to /etc/locale.conf and /etc/localtime on the target disk. Pick your actual defaults now. Changing them later requires editing config files and restarting services.
The Installation Destination screen is where most mistakes happen. Anaconda defaults to automatic partitioning with Btrfs. It creates a single volume with subvolumes for /, /home, and /var. This layout works for 90 percent of workloads. If you need separate partitions for compliance or backup tools that expect traditional ext4, switch to Custom partitioning. Draw your layout explicitly. Leave at least 10 gigabytes free on the root volume for package cache and log rotation.
# WHY: Btrfs subvolumes allow instant snapshots and easy rollbacks
# WHY: Automatic layout creates @, @home, and @var under /btrfs
# WHY: Custom layout gives you full control but requires manual mount point assignment
Network configuration happens next. Anaconda detects your interface and enables DHCP by default. For a server, you usually want a static IP. Click the interface name, toggle Automatically connect, and switch to manual configuration. Enter the IP address, netmask, gateway, and DNS servers. Save the settings. The installer writes a NetworkManager keyfile to /etc/NetworkManager/system-connections/ on the target disk. This file survives reboots and survives dnf upgrades.
Always test the connection before proceeding. A misconfigured gateway leaves you locked out of SSH after the first reboot.
Configuring the system during install
Set the root password. Fedora Server does not create a root account by default on Workstation, but Server enables it for administrative access. You can leave it blank to disable direct root login, but setting a strong password gives you a fallback if sudo configuration breaks. Create a standard user account and check the Make this user administrator box. This adds the user to the wheel group and configures /etc/sudoers.d/ to allow passwordless sudo for that group.
Software selection defaults to Server with GUI. If you are building a headless box, switch to Minimal Install. It drops X11, Wayland, and desktop packages. It leaves you with a clean systemd target and a terminal. You can always add a desktop later with dnf groupinstall "Server with GUI". Starting minimal keeps the attack surface small and reduces boot time.
Click Begin Installation. The progress bar shows package download and installation. Do not interrupt this phase. Anaconda runs a transactional install using rpm-ostree principles under the hood for consistency. If the network drops during package fetch, the installer pauses and retries. If it fails three times, it aborts. Check your DNS settings and cable connections before restarting.
Never skip the user creation step. A system without a sudo-capable account forces you to log in as root, which breaks audit trails and complicates SSH key management.
Verifying the fresh install
The installer finishes and prompts for a reboot. Remove the USB drive before the system powers off. The first boot loads your new kernel and drops you into a login prompt. Log in with your standard user account. Run a quick health check.
# Verify the system target and network state
systemctl get-default
nmcli device status
# WHY: Confirms you booted into multi-user.target and the interface has an IP
Check the storage layout. Btrfs shows subvolumes differently than ext4. Run btrfs subvolume list / to see the structure. Verify that /home and /var are mounted as separate subvolumes. This isolation prevents a runaway application from filling the root filesystem and crashing the system.
# Inspect the actual disk layout and mount points
df -hT
btrfs subvolume list /
# WHY: df shows filesystem types and usage, btrfs confirms subvolume isolation
Run a full system update. Fresh installs ship with packages from the release day. Security patches and bug fixes accumulate quickly. Use the refresh flag to bypass the local metadata cache. Fedora's release cadence is six months, and the N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle.
sudo dnf upgrade --refresh -y
# WHY: --refresh forces dnf to fetch fresh repo metadata instead of using stale cache
# WHY: -y automatically confirms the transaction so you can walk away
Reboot after the update. Kernel updates require a fresh boot to load the new modules and initramfs. Half the time, post-install weirdness disappears after a single reboot.
Run journalctl -xe after every major change. 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 recovery
The installer will refuse to proceed if it detects conflicting storage configurations. You might see Error: Transaction test error: package dracut conflicts with dracut-s390x. The conflict is intentional. The installer detected a mismatch between your architecture and the selected bootloader. Reboot and choose the correct ISO variant.
If you see [FAILED] Failed to start NetworkManager.service during the first boot, your network configuration probably references a missing interface name. NetworkManager uses predictable interface names like enp3s0. If you cloned a VM or moved hardware, the name changes. Check ip link and update the connection profile in /etc/NetworkManager/system-connections/. Never edit files in /usr/lib/NetworkManager/. Those ship with the package and get overwritten on upgrade. Always edit /etc/.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A fresh Fedora Server install runs in enforcing mode by default. If a custom service fails to start, check the audit log. Most denials resolve by setting the correct file context with restorecon -Rv /path/to/dir.
Firewall rules require a reload to take effect. Run firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge.
Trust the package manager. Manual file edits drift, snapshots stay.
Choosing your server variant
Use Minimal Install when you are building a container host, a database server, or any workload that does not need a graphical interface. Use Server with GUI when you need administrative tools like GNOME Disks, NetworkManager GUI, or remote desktop access. Use the BaseOS variant when you are packaging your own applications and want the smallest possible footprint. Stay on the default Server layout if you only deviate from the defaults occasionally.