You want the kernel patch, not the rest of the update
You see a critical CVE in the Linux kernel. You want the patch immediately. You also have a service running on this Fedora box that relies on a specific version of glibc or a proprietary driver that breaks if systemd changes. You want to swap the kernel and touch nothing else. You run dnf install kernel-6.9.0 and get a wall of dependency errors. Or worse, you force the install, and the system fails to boot because the initramfs is mismatched.
The short answer is that you cannot upgrade the kernel in isolation on a supported Fedora system. The kernel is not a standalone binary. It is a tightly coupled set of packages that must match exactly. Attempting to install a newer kernel version independently will trigger dependency resolution that pulls in the rest of the system, or it will fail with transaction errors. Forcing the install breaks the boot process.
Use the standard system update command to upgrade the kernel safely. Fedora keeps multiple kernels installed by default, so you can always roll back if the new kernel causes issues.
What's actually happening
Fedora packages the kernel as a family of RPM packages. The kernel package is a meta-package that depends on several sub-packages. These sub-packages must all share the exact same version string. If you install a new kernel version, dnf must also install the matching modules, core files, and development headers.
The dependency chain looks like this:
kerneldepends onkernel-core,kernel-modules,kernel-modules-extra, andkernel-uki.kernel-corecontains thevmlinuzimage and theinitramfs.kernel-modulescontains loadable kernel modules.dracutbuilds theinitramfs.dracutdepends onsystemd,glibc, and other userland tools.
If you try to install a new kernel version, dnf checks the dependencies. The new kernel-modules requires kernel-core of the same version. The new kernel-core requires a new initramfs. Building a new initramfs requires dracut. If the current dracut is too old to support the new kernel features, dnf must also upgrade dracut. Upgrading dracut often requires upgrading systemd or glibc. The transaction expands until the entire system is updated.
This coupling is intentional. Fedora tests the kernel against the userland in the release. The kernel modules are compiled against specific versions of userland libraries. Mismatched versions can cause module loading failures, kernel panics, or silent data corruption. The package manager enforces consistency to prevent these states.
Convention aside: Config files in /etc/ are user-modified and persist across updates. Files in /usr/lib/modules/ ship with the kernel package and are replaced during upgrade. Edit /etc/modprobe.d/ for module parameters. Never edit files in /usr/lib/.
The fix
Run the standard upgrade command. This updates the kernel and all other packages to the latest versions in the repository. The update is atomic. If the transaction fails, the system rolls back to the previous state. Fedora keeps the previous kernel installed, so you can boot the old kernel if the new one fails.
Here's how to run the upgrade and refresh the metadata to ensure you get the latest kernel.
sudo dnf upgrade --refresh
# --refresh forces dnf to download fresh repository metadata
# this ensures you see the latest kernel even if the cache is recent
# dnf resolves dependencies automatically and pulls matching kernel packages
# the transaction is atomic, so partial updates cannot corrupt the system
After the update completes, reboot your system to load the new kernel. Fedora's boot loader, GRUB, automatically detects the new kernel and adds it to the boot menu. The boot menu defaults to the newest kernel.
Convention aside: dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases like 40 to 42. They are different commands. Don't conflate them.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Check the running kernel version and compare it to the installed packages. The uname command shows the kernel the system is currently using. The dnf list command shows all installed kernel packages. Fedora usually keeps two or three kernels installed.
Here's how to check the running kernel and the installed versions.
uname -r
# prints the running kernel version string
# compare this against the output of dnf list installed kernel
# if the version matches the newest installed kernel, the upgrade worked
dnf list installed kernel
# lists all installed kernel packages
# look for the kernel, kernel-core, and kernel-modules packages
# verify they all share the same version number
If the running kernel is still the old version, check the GRUB boot menu. You might have booted the old kernel by accident. Reboot and select the new kernel from the menu.
Check the kernel logs for errors after the boot. The journalctl command shows the boot log. The -k flag filters for kernel messages. The -b flag shows the current boot.
journalctl -k -b
# -k filters for kernel messages
# -b shows the current boot session
# look for errors related to module loading or hardware initialization
# journalctl -xe adds explanatory text for failed units
Run journalctl first. Read the actual error before guessing.
Common pitfalls and errors
Attempting to isolate the kernel update triggers specific errors. Recognizing these errors saves time.
The dnf install kernel-6.9.0 command will refuse to proceed and print a dependency error. The error shows that the kernel modules require a matching kernel core.
Error: Transaction test error:
package kernel-modules-6.9.0-100.fc40.x86_64 requires kernel-core(x86-64) = 6.9.0-100.fc40, but none of the providers can be installed
The conflict is intentional. The package manager prevents you from installing mismatched packages. Do not force the install. Forcing the install with --skip-broken or --best --allowerasing can remove critical packages or leave the system in an unbootable state.
If you see [FAILED] Failed to start dracut.service during boot, your initramfs generation failed. This usually happens when dracut is out of sync with the kernel. The system cannot mount the root filesystem. You must boot the old kernel and run dnf upgrade to fix the mismatch.
If you see Dependency failed for /sys/module/... in the logs, a kernel module failed to load. This can happen if the module version does not match the kernel version. Check that all kernel packages share the same version string.
SELinux denials can appear after a kernel update if the security policy is outdated. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Updating the system usually includes the latest SELinux policy.
Trust the package manager. Manual file edits drift, snapshots stay.
Recovery procedure
If you forced a kernel install and the system fails to boot, you can recover by booting the old kernel and syncing the packages. This procedure requires order. A misstep can make recovery harder.
- Reboot the system and hold the
Shiftkey or pressEscrepeatedly during boot to access the GRUB menu. - Select "Advanced options for Fedora" from the GRUB menu.
- Choose the older kernel version from the list.
- Boot the system with the old kernel.
- Run
sudo dnf distro-syncto align all packages to the repository versions.
sudo dnf distro-sync
# distro-sync updates packages to the repository versions
# it downgrades packages that were manually upgraded
# it fixes dependency mismatches caused by forced installs
# this restores the system to a consistent state
After dnf distro-sync completes, run sudo dnf upgrade --refresh to apply the correct kernel update. Reboot the system.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use dnf upgrade --refresh when you want a stable, tested system with the latest kernel and security patches. Use dnf install kernel when you need to keep an older kernel available alongside a new one without removing the old kernel package. Use dnf system-upgrade when you are moving between major Fedora releases like 40 to 42. Use the Koji build system when you need a kernel patch that has not yet landed in the stable repository. Stay on the current kernel when your hardware or proprietary driver requires a specific version and the upgrade breaks functionality.