You need the version number now
You are troubleshooting a dependency conflict, or a forum helper asks for your system details before you can post. You need the exact Fedora release number and the kernel version immediately. Guessing based on the wallpaper or the GNOME version is dangerous. Fedora updates GNOME frequently, but the release number changes every six months. A wrong version number leads to bad advice and wasted time.
What's actually happening
Fedora stores version information in multiple places for different purposes. The release file is a simple text string for humans. The os-release file is a key-value database for scripts. The RPM database tracks the actual package metadata. Systemd reads these files and exposes them via hostnamectl. Understanding which source to query depends on whether you are reading the output or parsing it in a script.
Think of /etc/os-release as the system's ID card. It has fields for name, version, and ID. Scripts read the fields. Humans read the summary. The package manager maintains these files. They update automatically when you upgrade the release. Do not edit them manually. The package manager will overwrite your changes on the next update.
The fix
Use the method that matches your goal. Quick visual checks use the release file. Scripts use the structured os-release file. Support requests need the kernel and release together. Package debugging requires the RPM database.
Here's how to get the human-readable release string for a quick check.
cat /etc/fedora-release
# Displays the human-readable release string, e.g., "Fedora release 40 (Forty)".
# This file is maintained by the fedora-release package and updates on major upgrades.
# Use this for immediate visual confirmation in a terminal session.
Here's how to extract the version ID for scripting or automation.
grep VERSION_ID /etc/os-release | cut -d'"' -f2
# Extracts the version ID from the structured os-release file.
# This format is POSIX-compliant and stable across RHEL, Fedora, and Debian.
# Scripts should prefer this over parsing fedora-release to avoid breaking on format changes.
Here's how to get a comprehensive overview including the kernel and architecture.
hostnamectl
# Queries systemd for system information including OS, kernel, and architecture.
# This aggregates data from os-release and uname into a single readable block.
# Useful when you need the kernel version alongside the Fedora release in one glance.
Here's how to verify the exact package version of the release metadata.
rpm -q fedora-release
# Queries the RPM database for the exact version of the release metadata package.
# This confirms the package version installed via dnf, including update numbers.
# Essential for verifying integrity or debugging package manager conflicts.
Verify it worked
Run the command and check the output matches your expectation. If you upgraded, the version should reflect the new release. If you are in a container, the version might differ from the host.
Here's how to chain the release and kernel for a support-ready snapshot.
cat /etc/fedora-release && uname -r
# Chains the release string with the kernel version for a complete snapshot.
# Verify the output shows the expected release number and a kernel version >= 6.x.
# This combination is the standard format for pasting into support requests.
Check the output. The release number should match the Fedora release you expect. The kernel version should be a recent 6.x release. If the numbers look wrong, check your container runtime or upgrade status.
Run hostnamectl first. It gives you the kernel and release in one view.
Common pitfalls and what the error looks like
Containers often share the host's release files or override them. A container built from fedora:40 reports Fedora 40 even if the host is Fedora 42. Check the runtime environment before trusting the file. If you see a version number that doesn't match your host, you are likely inside a container or a chroot.
During a dnf system-upgrade, the system reboots into the new version. The files update before the reboot completes. If you check version immediately after the upgrade transaction starts but before the reboot, you see the old version. Wait for the reboot.
Parsing /etc/os-release with grep can fail if the format changes. The os-release spec allows for complex quoting. Use source /etc/os-release in bash scripts to load variables safely.
Here's how to load the release variables safely in a script.
source /etc/os-release
echo "Version: $VERSION_ID"
# Loads the os-release file into shell variables.
# This is safer than grep because it handles quoting and escaping automatically.
# Access VERSION_ID directly in the script without parsing text output.
Immutable variants like Silverblue and Kinoite use rpm-ostree. The package database is merged from the base image and layers. rpm -q still works, but the output reflects the composite state. rpm-ostree status shows the base commit. This distinction matters when troubleshooting. An immutable system cannot be upgraded with dnf upgrade. It requires rpm-ostree upgrade. Checking the version helps you determine which upgrade path is valid.
Here's how to check the version on an immutable variant.
rpm-ostree status
# Shows the deployed ostree commit and the base image version.
# On immutable variants, the package database is read-only.
# This command confirms the exact commit hash and release version.
Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. 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. Checking your version tells you if you are on a supported release. If you are on N-2, you must upgrade before your repositories go offline.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. The release files are managed by the package manager. Do not edit /etc/fedora-release manually. The package manager will overwrite your changes on the next update. Trust the package manager. Manual file edits drift, snapshots stay.
Source the os-release file in scripts. Hardcoding grep patterns breaks when the format changes.
When to use this vs alternatives
Use cat /etc/fedora-release when you need a quick human-readable string for a support ticket. Use /etc/os-release when you are writing a script that must parse the version reliably. Use hostnamectl when you need the kernel version and architecture alongside the release number. Use rpm -q fedora-release when you are debugging package conflicts or verifying the metadata package integrity. Use source /etc/os-release when your script needs to access the version as a shell variable for conditional logic. Use rpm-ostree status when you are on Silverblue or Kinoite and need the base commit information.
Check the container runtime. A container lies about the host version.