You rebooted after an update and the hardware acts strange
You just ran dnf upgrade --refresh and rebooted. The desktop loads, but your external GPU isn't detected, your custom firewall rules dropped, or the Wi-Fi adapter shows a firmware mismatch. The first question is always the same: which kernel is actually running right now. Fedora ships multiple kernel versions by default. The one in memory might not match the newest package on disk. Checking the version takes two seconds, but doing it wrong leads to chasing ghosts. Run the right command first. Save yourself an hour of misdiagnosis.
What the kernel version string actually means
The Linux kernel is the bridge between your hardware and everything else. Fedora treats it like a safety net. When you update, the system installs the new kernel alongside the old one. The bootloader presents a menu, and the system picks the default. If the new kernel breaks a driver, you fall back to the previous one. This means installed and running are two different states. Think of it like a theater stage. The script on the desk is the installed package. The actors performing on stage right now are the running kernel. You need to know which script is actually being performed before you change the set.
The version string follows a strict pattern. The first segment is the upstream Linux version. The second segment is the Fedora build iteration. The third segment marks the release tree. The final segment confirms the CPU architecture. Fedora splits the kernel into multiple packages: kernel, kernel-core, kernel-modules, and kernel-modules-extra. The kernel package is just a meta-package that pulls the others together. When you query the database, you are looking at the meta-package version. The actual code lives in the core and modules packages. This design keeps the package manager clean and makes dependency resolution faster.
Reboot before you debug. Half the time the symptom is gone.
Check the running kernel
Start with the process that is currently executing. The uname command queries the kernel directly. It does not read package databases or configuration files. It asks the running system for its own identity. This is the only source of truth for what is active in memory.
uname -r
# Queries the live kernel for its release string
# Returns exactly what is loaded in memory right now
# Ignores what is installed on disk or what GRUB will boot next
The output looks like 6.8.11-300.fc40.x86_64. The 6.8.11 part tracks the upstream stable branch. The 300 is Fedora's internal build counter. The fc40 tag tells you which release tree compiled it. The x86_64 suffix confirms it matches your CPU. If you need the full compiler flags and build timestamp, the proc filesystem exposes it directly. This is useful when debugging compiler-specific bugs or verifying module signing status.
cat /proc/version
# Reads the kernel's internal build metadata
# Shows the GCC version and exact compilation date
# Useful when debugging compiler-specific bugs or module signing
The proc filesystem is a virtual interface. It does not contain real files on disk. The kernel generates the content on the fly when you read it. This means the output always matches the currently running kernel, even if the package database is out of sync. Trust the live system over the package list when they disagree.
Check what is installed on disk
Knowing what is running only tells you half the story. You need to know what is available for the next boot. The RPM database tracks every kernel package that dnf has placed on your system. Fedora's default configuration keeps the current kernel plus the two previous versions. This gives you a three-boot safety window. The package manager automatically removes older kernels when the count exceeds three, unless you change the installonly_limit setting in /etc/dnf/dnf.conf.
rpm -q kernel
# Queries the RPM database for all installed kernel packages
# Lists every version currently staged for boot
# Does not indicate which one is active in memory
You will see a list of three or four lines. The newest one is usually the default. If you recently updated but haven't rebooted, the running kernel will be older than the top line in this output. If you are troubleshooting a driver that stopped working after an update, this list tells you exactly which fallback versions are available. The output format includes the epoch, version, release, and architecture. Match these fields against your hardware requirements before proceeding.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The same rule applies to bootloader metadata. Let grubby manage /boot/loader/entries/. Manual edits drift, snapshots stay.
Verify the match between memory and storage
Sometimes the running kernel and the installed default drift apart. This happens when an update fails midway, or when a manual rollback leaves the bootloader pointing at an older entry. You can compare them in a single step. This verification catches orphaned kernels before they cause confusion during a major release upgrade.
echo "Running: $(uname -r)"
# Captures the live kernel version for direct comparison
# Sets up the baseline for the next command
# Prevents copy-paste errors when cross-referencing output
dnf list installed kernel | grep "$(uname -r | cut -d'-' -f1-3)"
# Filters the package list to match the running version
# Confirms whether the active kernel is still tracked by dnf
# Reveals orphaned kernels if the grep returns nothing
If the grep returns a line, your system is consistent. If it returns nothing, you are running a kernel that dnf no longer manages. That usually means a manual installation or a failed transaction left a dangling package. Clean it up before your next major release upgrade. Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. Orphaned kernels waste disk space and complicate repository metadata during the transition.
Run journalctl first. Read the actual error before guessing.
Common pitfalls and error patterns
The most common mistake is assuming the newest installed kernel is the one currently running. It is not. The bootloader decides at startup. If you just updated and haven't rebooted, uname -r will show the old version. Reboot before you debug. Half the time the symptom is gone.
Another trap is editing GRUB files directly. The file /boot/grub2/grub.cfg is generated automatically. Manual edits vanish on the next kernel update. Use grubby to change the default boot entry. It modifies the bootloader metadata safely and survives package upgrades. If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Kernel version mismatches rarely cause that specific failure. Check the interface naming scheme instead.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The kernel version check commands do not trigger SELinux alerts. They read local system state. If you see permission denied errors, your user account lacks sudo privileges or the terminal session is restricted. Run the commands as your normal user first. Escalate only when modifying boot defaults.
Custom kernel variants like kernel-rt or kernel-debug follow the same rules. The package name changes, but the verification steps remain identical. Query the specific package name instead of the generic kernel. The uname output will still show the base version string. The variant suffix appears in the package metadata, not the running release string. If you are compiling out-of-tree modules, match the exact kernel-devel package to the running uname -r output. Mismatched headers cause make to fail with No such file or directory errors during compilation.
Snapshot the system before the upgrade. Future-you will thank you.
Choose the right command for your goal
Use uname -r when you need to know exactly what is executing in memory right now. Use rpm -q kernel when you want to see every kernel version staged for boot. Use dnf list installed kernel when you are planning an update or checking repository alignment. Use grubby --default-kernel when you need to change which version boots next. Use journalctl -k when you are debugging a kernel panic or driver failure. Trust the package manager. Manual file edits drift, snapshots stay.