You upgraded Fedora and the screen went black
You ran a system update. The terminal reported a new kernel was installed. You rebooted. The display stayed dark, or the system dropped you into an emergency shell. You need to boot the previous kernel, but you do not know the exact version string to select from the GRUB menu. Or perhaps your root partition is filling up, and you suspect old kernel files are hoarding space in /boot. You need a clear inventory of every kernel image on your disk, what is currently running, and what the bootloader will load next.
This situation happens. Fedora updates the kernel frequently. The package manager installs the new kernel alongside the old one. It updates the bootloader to prefer the new version. It does not remove the old version automatically. This safety net exists for a reason. If a new kernel breaks your hardware, your display driver, or your container runtime, you can roll back. Understanding the difference between the running kernel, the installed kernels, and the default boot entry prevents panic during a broken boot.
What is actually happening
Think of your system like a workshop. The kernel is the power tool. You have one tool plugged in and running right now. That is the running kernel. You have a toolbox on the shelf with other versions of the same tool. Those are the installed kernels. You also have a label on the shelf that says "Use this one next time." That is the GRUB default.
When you run dnf upgrade, Fedora downloads a new kernel package. It installs it alongside the old one. It updates the GRUB configuration to point to the new kernel. It does not remove the old kernel automatically. This behavior is controlled by the dnf configuration. The system retains two kernels by default. If you need to check what is in the toolbox, you query the package database. If you need to check what is plugged in, you ask the running system. If you need to check the label on the shelf, you read the bootloader environment.
Fedora splits the kernel into multiple packages. The kernel package is a meta-package that pulls in the core components. The kernel-core package contains the kernel image and modules. The kernel-modules package contains extra modules. The kernel-modules-extra package contains out-of-tree modules. When you list kernels, you will see all of these. The version string is the same across all packages for a given release. The package manager keeps them in sync.
Check the running kernel before you remove packages. You cannot uninstall the kernel you are currently using.
How to list installed kernels
Start with the package manager. dnf gives the cleanest view of what is managed. It shows the package name, version, release, and architecture. It filters the output to show only kernel-related packages. This command is the standard way to audit your system.
Here is how to list all installed kernel packages with their full metadata.
dnf list installed kernel*
# WHY: The asterisk expands to kernel, kernel-core, kernel-modules, and related packages.
# WHY: dnf list installed queries the local rpm database for packages currently on disk.
# WHY: This output shows version, release, and architecture, which helps identify partial installs.
The output lists every kernel package. You will see multiple versions. The highest version is usually the newest. The second highest is the fallback. If you see more than two versions, you likely have old kernels that were not cleaned up. Fedora's default configuration retains the last two kernels. You can change this limit, but keeping two is the safe baseline.
If you need a version-sorted list without the extra columns, use rpm. This is useful for scripting or when you need to verify the exact version string against release notes. The sort -V flag is essential. Standard alphabetical sorting breaks on kernel versions. Version 6.10 sorts before 6.9 alphabetically. Version-aware sorting fixes this.
Here is how to get a clean, version-sorted list of kernel packages.
rpm -qa kernel | sort -V
# WHY: rpm -qa kernel queries all installed packages matching the name kernel.
# WHY: sort -V performs version-aware sorting, so 6.10 comes after 6.9, not 6.1.
# WHY: This output is easy to parse in scripts or to compare against Fedora release notes.
This command prints one line per package. The lines are sorted from oldest to newest. The last line is the newest installed kernel. If you are writing a script to check for a specific kernel version, this output is easier to parse than the dnf table.
Verify the initramfs exists. A kernel without an initramfs will not boot.
Verify the running kernel
The list of installed kernels tells you what is on disk. It does not tell you what is currently executing. The system might be running an older kernel if you just installed an update but have not rebooted yet. Or you might have booted the fallback kernel manually after a crash. You need to know the exact version string of the kernel in memory.
Use uname to check the running kernel. This command queries the kernel itself. It returns the release string. This string matches the version part of the package name.
Here is how to check the currently running kernel version.
uname -r
# WHY: -r prints only the release string, stripping architecture and hostname.
# WHY: This output matches the version field in rpm and dnf package names.
# WHY: This confirms which kernel is actually executing, not just which one is installed.
Compare this output to the list from dnf. If uname shows an older version than the newest installed kernel, you are running the fallback. This is normal after an update if you have not rebooted. It is also normal if you manually selected the old kernel from the GRUB menu. If uname shows a version that is not in the dnf list, you have a serious problem. The running kernel was removed from the package database. Do not reboot. You will lose the ability to boot. Restore the kernel package immediately from a backup or live USB.
Run journalctl -k to review kernel messages. Look for errors related to modules or hardware.
Check the bootloader default
Knowing what is installed and what is running is not enough. You need to know what the system will load on the next reboot. GRUB manages the boot process. It stores the default entry in an environment file. This file survives reboots and configuration updates. Fedora uses grub2-editenv to read and write this file.
Here is how to check which kernel GRUB will boot next.
grub2-editenv list
# WHY: grub2-editenv list reads the GRUB environment block from disk.
# WHY: saved_entry holds the GRUB menu index or title for the next boot.
# WHY: This output confirms the bootloader state, independent of the running kernel.
The output shows saved_entry. The value is usually a string like Advanced options for Fedora>Fedora, with Linux 6.10.12-200.fc40.x86_64. This string points to a specific menu entry in the GRUB configuration. If the value is empty or missing, GRUB will use the default timeout and boot the first entry in the menu. This is usually the newest kernel.
If you need to change the default kernel, do not edit the GRUB configuration file manually. Use grub2-set-default. This command updates the environment file safely. Editing the configuration file directly is fragile. The file is regenerated by grub2-mkconfig during updates. Manual edits get overwritten. The environment file persists.
Keep two kernels installed. One for now, one for when the update breaks.
Common pitfalls and errors
Listing kernels is straightforward. Interpreting the results and managing the boot process introduces complexity. Several common issues trip up users.
The first issue is confusing the kernel package with kernel-core. The kernel package is a meta-package. It does not contain the kernel image. It pulls in kernel-core, kernel-modules, and kernel-modules-extra. When you list packages, you see all of them. They all share the same version string. You do not need to install them separately. The meta-package handles dependencies.
The second issue is disk space in /boot. The /boot directory contains the kernel images, initramfs files, and GRUB configuration. Old kernels take up space. If you install many kernels without cleaning up, /boot fills up. When /boot is full, dnf cannot install new kernels. The update fails. You see an error like No space left on device. You need to remove old kernels. Use dnf autoremove to clean up packages that were dependencies of removed packages. This often removes old kernels. You can also use dnf remove kernel-<version> to target specific kernels. Always keep at least two versions.
The third issue is the GRUB menu not showing up. Fedora sets a short timeout for the GRUB menu. If you do not press a key quickly, the system boots the default entry. You cannot select the old kernel. To fix this, hold the Shift key during boot. This forces the GRUB menu to appear. You can then select the older kernel. If you need to change the timeout permanently, edit the GRUB configuration. Use grub2-mkconfig to regenerate the configuration after changes.
The fourth issue is missing initramfs. The initramfs is a temporary root file system used during boot. It loads drivers needed to mount the real root file system. If the initramfs is missing or corrupted, the kernel cannot boot. You see a panic message. The initramfs is generated by dracut. When you install a kernel, dracut runs automatically. If it fails, the kernel is installed but not bootable. Check the logs for dracut errors. Run dracut -f to force regeneration.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use which command
You have multiple tools to inspect kernels. Each tool serves a specific purpose. Choose the right one for your task.
Use dnf list installed kernel* when you need a full inventory of managed packages including headers and modules.
Use rpm -qa kernel | sort -V when you are writing a script that requires version-sorted strings without metadata columns.
Use uname -r when you need to verify the exact kernel version currently executing in memory.
Use grub2-editenv list when you need to confirm which kernel the bootloader will select on the next reboot.
Use ls /boot/vmlinuz-* when you need to verify the physical files exist on disk and check their sizes.
Use dracut --list-kernels when you need to check which initramfs images are present and valid.
Reboot before you debug. Half the time the symptom is gone.