You changed /etc/hostname and nothing happened
You just provisioned a Fedora virtual machine or a new server. You SSH in and the prompt shows localhost.localdomain. That name tells you nothing about the machine's role. You need it to be fileserver-01 or k8s-node-3. You edit /etc/hostname with a text editor, reboot, and the name is back to default. Or worse, you set the name, but your monitoring tools still report the old one because the transient hostname didn't update.
The hostname is not just a string in a file. It is a state managed by systemd, influenced by the network at boot, and displayed differently depending on who is asking. Editing the file manually bypasses the init system. The system reads the file, sets the static hostname, but the transient hostname remains controlled by DHCP or cloud metadata. Services that query the kernel for the current name see the transient value, not the file value.
Run hostnamectl to update the state atomically. This command talks to systemd-hostnamed over D-Bus. It updates the file, sets the kernel hostname, and synchronizes the transient name in one step.
What the three hostnames mean
Fedora tracks three hostnames simultaneously. They serve different purposes and can differ from each other.
The static hostname lives in /etc/hostname. It persists across reboots. This is the name you set once and expect to stay. Network services and configuration management tools rely on this value.
The transient hostname exists only in memory. systemd sets it at boot. It often matches the static hostname, but it can change. If you are on a network with DHCP, the DHCP server might push a hostname. If you are in a cloud VM, the metadata service might assign a name. The transient hostname reflects what the network thinks the machine is called right now.
The pretty hostname is for display only. It can contain spaces, unicode, and special characters. It shows up in the login screen, the desktop environment, and hostnamectl output. It never appears in network packets. Scripts and services ignore it.
Think of the static hostname as the name engraved on the device chassis. The transient hostname is the name the network switch sees when the cable plugs in. The pretty hostname is the label on the sticky note you put on the monitor.
Set the hostname correctly
Use hostnamectl set-hostname to change the static hostname. This is the standard method on Fedora. It updates /etc/hostname and notifies systemd-hostnamed. The change takes effect immediately. No reboot is required.
Here's how to set the static hostname for a web server.
# Set the static hostname. Updates /etc/hostname and notifies systemd-hostnamed via D-Bus.
# The change applies to the kernel immediately.
sudo hostnamectl set-hostname fedora-web-01
If you are setting up a desktop and want a friendly name for the login screen, set the pretty hostname separately. The static hostname remains machine-readable.
# Set the pretty hostname for display in the desktop environment.
# This does not affect network services or scripts.
sudo hostnamectl set-hostname --pretty "Fedora Workstation 01"
Run hostnamectl status immediately. The change is live without a reboot.
Verify the change
Check all three hostnames and the boot ID with hostnamectl status. This command queries systemd-hostnamed and returns the current state.
Here's how to verify the hostname configuration and ensure the transient name matches the static name.
# Display static, transient, and pretty hostnames along with the boot ID.
# The boot ID changes on every reboot, which helps correlate logs.
hostnamectl status
Look for the Static hostname line. It should match what you set. Look for the Transient hostname line. It should match the static hostname unless DHCP or a cloud provider is overriding it. If the transient hostname differs, local services might resolve to the wrong name until the next reboot or network restart.
If you see Transient hostname: (none), the transient hostname has not been set by any service. This is normal for a fresh install with no network configuration yet. The kernel will fall back to the static hostname.
Run hostnamectl status first. Read the transient line before assuming the change failed.
Fix /etc/hosts mismatches
Changing the hostname does not automatically update /etc/hosts. If /etc/hosts still maps 127.0.0.1 to the old hostname, local services will fail to resolve the new name. This breaks tools like PostgreSQL, Docker, or any application that binds to the hostname.
Here's how to update the loopback entries in /etc/hosts to match the new static hostname.
# /etc/hosts
# Map the new hostname to loopback addresses for local resolution.
# Keep the existing localhost entries. Add the new hostname on separate lines.
127.0.0.1 localhost localhost.localdomain
::1 localhost localhost.localdomain
127.0.0.1 fedora-web-01
::1 fedora-web-01
Edit /etc/hosts if local services fail to resolve the name. The package manager does not touch this file during hostname changes.
Handle cloud and DHCP overrides
In virtual machines and cloud instances, the hostname might revert after a reboot. The cloud provider or DHCP server pushes a hostname via the network. systemd-networkd receives this and updates the transient hostname. If the transient hostname differs from the static hostname, the system reports the transient name to the network.
You can lock the transient hostname to match the static hostname. This prevents DHCP from changing the name at runtime.
Here's how to force the transient hostname to match the static hostname immediately.
# Set the transient hostname explicitly.
# This overrides DHCP or mDNS changes for the current session.
sudo hostnamectl set-hostname --transient fedora-web-01
To make this permanent, you can configure systemd-networkd to ignore DHCP hostname offers. Edit the network configuration file in /etc/systemd/network/ and set UseHostname=false in the [DHCPv4] section. This stops the daemon from accepting hostname changes from the network.
Check the transient hostname if the name reverts after a network restart. The static file is correct, but the runtime state is being overwritten.
SSH key cache issues
When you change the hostname, the SSH host key fingerprint might change if the keys were generated based on the hostname. Remote machines that have connected to this host before will cache the old fingerprint. The next SSH connection will fail with a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! error.
You must remove the old key from the client's known hosts file. This is a client-side fix, not a server-side fix.
Here's how to remove the old host key from a client machine.
# Remove the old key for the old hostname from the client's known_hosts file.
# Replace old-hostname with the previous name of the server.
ssh-keygen -R old-hostname
Remove old SSH host keys. The fingerprint changes when the identity changes.
Decision matrix
Use hostnamectl set-hostname when you need a persistent name that survives reboots and updates systemd state.
Use hostnamectl set-hostname --pretty when you want a human-readable label with spaces for the desktop environment.
Use hostnamectl set-hostname --transient when you need to fix a mismatch caused by DHCP or cloud metadata without changing the disk.
Edit /etc/hostname manually only when you are writing a script that runs before systemd starts, which is rare on modern Fedora.
Trust the package manager. Manual file edits drift, snapshots stay.