How To Change Hostname on Fedora 44

Change Hostname on Fedora 44

You just finished installing Fedora 44, you open a terminal, and the prompt reads [user@localhost ~]$. That localhost is not just cosmetic. It is your system’s identity on the network, in your log files, in SSH sessions, and in every monitoring alert that fires at 2 AM. Learning how to change hostname on Fedora 44 correctly — not just cosmetically, but at the system level — is one of the first things a competent sysadmin does after a fresh install.

This guide walks you through four proven methods to configure the hostname on Fedora 44: using hostnamectl (the recommended path), editing /etc/hostname directly, using nmcli, and using the GNOME Settings GUI for desktop users. For every step, you will learn not just what command to run, but why it works the way it does.

Fedora 44 was released in April 2026 and ships with GNOME 50, updated systemd tooling, and Btrfs subvolumes replacing the /boot partition in Cloud images. The hostname management stack has not fundamentally changed from previous Fedora releases, but knowing the current system context helps you make better decisions about which method to use.

What Is a Hostname and Why Does It Matter

Before running a single command, take 90 seconds to understand what you are actually changing. A hostname is a human-readable label assigned to a machine so that people and services can refer to it by name instead of by IP address. On a Fedora 44 system, the hostname shows up in your shell prompt, your SSH banner, your systemd journal entries, and your network broadcast packets.

A machine still sitting on localhost.localdomain creates real operational problems. When you have five servers and all five write logs to a centralized collector with the hostname localhost, you can no longer tell which machine generated a particular error. Tools like Cockpit, FreeIPA, and Grafana Loki all depend on a unique, meaningful hostname to make sense of the data they receive.

Fedora 44 uses systemd-hostnamed as the authoritative daemon for managing hostname state. This daemon handles three distinct hostname types, and understanding the difference between them will save you hours of troubleshooting.

The Three Hostname Types in Fedora 44

Type Storage Location Persistent? Example
Static /etc/hostname Yes fedora44-webserver
Transient Kernel memory (from DHCP) No dhcp-hostname-123
Pretty Stored by systemd-hostnamed Yes Emily's Dev Laptop

The static hostname is what you almost always want to set. It is written to /etc/hostname, read by the kernel at boot, and used by all system services. The transient hostname is assigned dynamically by a DHCP server. If your static hostname disappears after a reboot, DHCP overriding it is the most common culprit. The pretty hostname is a free-text label that can contain spaces and special characters. It shows up in GNOME Settings and Cockpit but has no effect on system services.

Prerequisites: What You Need Before You Start

Getting this right the first time requires a few things in place:

  • Fedora 44 installed (Workstation, Server, or Minimal edition)
  • A terminal with sudo privileges or direct root access
  • Basic familiarity with the command line
  • Knowledge of what your new hostname will be (choose carefully, see naming rules below)

Hostname naming rules (per RFC 952 and RFC 1123):

  • Use only lowercase letters a-z, digits 0-9, and hyphens -
  • Do not start or end the hostname with a hyphen
  • Keep the total FQDN under 253 characters; each individual label under 63
  • Avoid underscores — they are technically invalid per the RFC and can break DNS resolution and SSL certificate issuance
  • If your machine participates in a Samba or Windows network, keep the name under 15 characters for NetBIOS compatibility

A good naming convention for servers follows the pattern role-location-number. Examples: db-primary-01, app-worker-03, proxy-nyc-02. This makes log lines immediately useful during incident response.

Step 1: Check Your Current Hostname on Fedora 44

Before changing anything, record your baseline. Open a terminal and run:

hostnamectl

Expected output:

 Static hostname: localhost.localdomain
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 3a8d640d88474b6999511de4410f92f2
         Boot ID: 9cf3e1b27abc4c3b9e8d1f0a3b72c1d4
Operating System: Fedora Linux 44 (Workstation Edition)
          Kernel: Linux 6.14.0-200.fc44.x86_64
    Architecture: x86-64

This single command shows all three hostname types (static, transient, pretty) plus your OS version and kernel. If you see a value under Transient hostname that differs from Static hostname, that means your DHCP server is pushing its own hostname value. You need to address that separately, which is covered in the troubleshooting section below.

Also run:

hostname -f

This returns the Fully Qualified Domain Name (FQDN). If it returns localhost.localdomain, your /etc/hosts file is not properly configured yet. You will fix that in Step 4.

Why run these checks first? Because changing a hostname on a machine already enrolled in FreeIPA, Active Directory, or a Kerberos realm without first auditing its current state will break authentication services. Audit before you act.

Step 2: Change Hostname on Fedora 44 Using hostnamectl (Recommended Method)

hostnamectl is the right tool for this job on any systemd-based Linux distribution. It talks directly to systemd-hostnamed over the D-Bus system bus, updates /etc/hostname, and notifies all running daemons about the name change — all in one atomic operation.

Set the New Static Hostname

sudo hostnamectl set-hostname fedora44-server

Replace fedora44-server with your chosen hostname. The command completes silently if successful.

Why use hostnamectl instead of editing files directly? When you edit /etc/hostname by hand, only the file changes. Running services — your shell, SSH daemon, journald — continue operating with the old hostname in memory until they restart or the system reboots. hostnamectl fixes this by signaling systemd-hostnamed, which propagates the new name to the running kernel namespace immediately. No reboot required.

Optionally Set a Pretty Hostname

If you use Cockpit or GNOME as a management interface, set a pretty hostname too:

sudo hostnamectl set-hostname "Fedora 44 Production Server" --pretty

Verify the Change Immediately

hostnamectl
hostname
cat /etc/hostname

All three should now reflect your new hostname. If hostname returns the old value, your shell session may be reading a cached value. Close the terminal, open a new one, and check again.

Step 3: Sync Your /etc/hosts File

This step is one that most beginner tutorials skip, and it causes the most post-change problems. After setting a new hostname, open /etc/hosts and update it to match.

sudo nano /etc/hosts

A correctly configured /etc/hosts for a machine without a static IP looks like this:

127.0.0.1   localhost
127.0.1.1   fedora44-server.localdomain   fedora44-server
::1         localhost ip6-localhost ip6-loopback

For a machine with a real static IP address, the entry looks like this instead:

192.168.1.50   fedora44-server.yourdomain.com   fedora44-server

Why does the FQDN come before the short name on the same line? The system resolver reads the file from left to right. Placing the FQDN first ensures that any application calling gethostbyname() — including Java applications, PostgreSQL, and Kerberos clients — resolves the full domain name correctly before falling back to the short name.

Why use 127.0.1.1 and not 127.0.0.1? The address 127.0.0.1 should map only to localhost. Using 127.0.1.1 for your hostname avoids aliasing the two together, which prevents subtle networking bugs in applications that distinguish between the two loopback addresses.

After saving the file, verify it works:

hostname -f

If this now returns your FQDN (e.g., fedora44-server.localdomain), the sync is correct.

Step 4: Change Hostname Using /etc/hostname (Manual / Automation Method)

For Ansible playbooks, cloud-init configurations, or bootc container images where hostnamectl may not be available, editing /etc/hostname directly is the correct approach.

sudo nano /etc/hostname

Delete the existing content entirely and write only the new hostname on a single line:

fedora44-server

Save and close the file. Then restart systemd-hostnamed to apply the change without rebooting:

sudo systemctl restart systemd-hostnamed

Why restart the daemon instead of rebooting? On a production server, a reboot means downtime. Restarting systemd-hostnamed forces it to re-read /etc/hostname and broadcast the updated hostname to dependent services right away. Follow this with the /etc/hosts update from Step 3.

One critical detail: The file must contain exactly one line with no trailing spaces. The kernel reads this file raw. A trailing space or blank line becomes part of the hostname string, which causes log mismatches and can break SSL certificate Common Name validation.

Step 5: Change Hostname Using nmcli (NetworkManager Method)

On Fedora 44 Workstation and laptop setups, NetworkManager handles both network configuration and hostname management. If you only use hostnamectl on these systems, NetworkManager may silently override your new hostname the next time a DHCP lease renews.

The fix is to also set the hostname through nmcli:

sudo nmcli general hostname fedora44-workstation

Then restart NetworkManager to apply it:

sudo systemctl restart NetworkManager

Verify with:

hostnamectl

Why go through nmcli on workstation setups? NetworkManager has its own hostname-mode setting that controls whether it defers hostname management to systemd-hostnamed or takes it over itself. When hostname-mode is set to dhcp (the default in some configurations), every DHCP lease renewal can overwrite your static hostname. Setting the hostname via nmcli keeps both systems in sync and prevents that overwrite.

Step 6: Change Hostname via GNOME Settings (GUI Method for Workstation Users)

If you run Fedora 44 Workstation with GNOME 50 and prefer not to touch a terminal, the graphical route works too.

  1. Open Settings from the Activities menu (Super key, then type “Settings”)
  2. Navigate to System, then click About
  3. Click on the Device Name field at the top
  4. Type your new hostname and press Enter

GNOME calls the same systemd-hostnamed D-Bus API under the hood. It is not less official than the terminal method. What GNOME does is auto-derive the static hostname from whatever pretty name you type — spaces get replaced with hyphens and special characters get stripped.

Why is this method limited to desktop use? The GNOME Settings panel does not update /etc/hosts. On a standalone workstation that does not run local network services, this is fine. On any machine running a web server, database, mail server, or participating in a domain, skip the GUI and use hostnamectl plus a manual /etc/hosts update.

Step 7: Verify the Hostname Persists After Reboot

A change that reverts on reboot is worse than no change at all, because you think the problem is solved when it is not. Always verify persistence.

sudo reboot

After the system comes back up:

hostnamectl
hostname
hostname -f
hostname -s
cat /etc/hostname

All five outputs should reflect your new hostname. If the hostname reverted, jump to the troubleshooting section below.

Troubleshooting: Common Hostname Change Problems on Fedora 44

Problem 1: Hostname Reverts to Old Name After Reboot

Cause: NetworkManager’s DHCP client is overwriting your static hostname on lease renewal.

Fix: Edit NetworkManager’s main configuration file:

sudo nano /etc/NetworkManager/NetworkManager.conf

Add or modify the [main] section:

[main]
hostname-mode=none

Then restart NetworkManager:

sudo systemctl restart NetworkManager

Why hostname-mode=none? This tells NetworkManager to stop managing hostname state entirely and defer all hostname responsibility to systemd-hostnamed. Without this setting, every DHCP renewal can undo your work.

Problem 2: hostname -f Returns localhost.localdomain

Cause: Your new hostname is not in /etc/hosts.

Fix: Add the correct entry as shown in Step 3. The system resolver checks /etc/hosts first (as defined in /etc/nsswitch.conf) before querying DNS. If your hostname has no entry there, the resolver falls back to localhost.localdomain.

Problem 3: sudo Warns “Unable to Resolve Host”

After changing the hostname, you run a sudo command and see:

sudo: unable to resolve host fedora44-server: Name or service not known

Cause: The hostname your shell session knows (the new one) has no matching entry in /etc/hosts.

Fix: Update /etc/hosts with the new hostname, then open a fresh terminal session. The warning is harmless to your system but alarming in production logs, so fix it promptly.

Problem 4: Pretty Hostname Shows Up Instead of Static Hostname in SSH Prompt

Cause: Your shell PS1 prompt is configured to read the pretty hostname variable rather than the static one.

Fix: Check your shell prompt configuration in ~/.bashrc or ~/.bash_profile. Replace any $HOSTNAME calls that read pretty hostname metadata with a direct $(hostname -s) call, which always reads the kernel’s current static value.

Problem 5: FreeIPA or Kerberos Authentication Breaks After Hostname Change

Cause: Your Fedora 44 machine was enrolled in a FreeIPA domain. The domain still holds the old hostname’s Kerberos service principal.

Fix: This requires re-enrollment:

sudo ipa-client-install --uninstall
sudo ipa-client-install --hostname=new-hostname.yourdomain.com

Why is re-enrollment necessary? FreeIPA ties SSL certificates, Kerberos service principals, and DNS entries to the specific hostname registered during enrollment. Changing the hostname without re-enrolling leaves orphaned records in the directory and breaks all Kerberos-based authentication. This is a common mistake that catches people off guard.

VPS Manage Service Offer
If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!
r00t is a Linux Systems Administrator and open-source advocate with over ten years of hands-on experience in server infrastructure, system hardening, and performance tuning. Having worked across distributions such as Debian, Arch, RHEL, and Ubuntu, he brings real-world depth to every article published on this blog. r00t writes to bridge the gap between complex sysadmin concepts and practical, everyday application — whether you are configuring your first server or optimizing a production environment. Based in New York, US, he is a firm believer that knowledge, like open-source software, is best when shared freely.

Related Posts