When the shipped kernel falls short
You just connected a new NVMe drive or a fresh GPU, and Fedora refuses to recognize it. The device manager shows nothing, and dmesg returns silence. You read a hardware forum claiming the driver landed in the latest mainline kernel, but your current release ships with a frozen version. You need the newer kernel without waiting for the next Fedora point release.
How Fedora packages the kernel
Fedora treats the kernel differently than user-space software. When a release ships, the kernel version is locked to a specific upstream commit. Security patches and critical stability fixes get backported, but new hardware support and feature branches stay out. This keeps the system predictable. The kernel repository bridges that gap by holding newer upstream kernels that have passed basic regression testing for your current release. Rawhide operates on a different timeline. It is the active development branch for the next Fedora version. Enabling it pulls packages that may change API contracts, drop older hardware support, or break dependency chains. Understanding the boundary between a stable mainline update and a Rawhide development cycle prevents broken boots.
Think of the stable kernel like a published book. The text is fixed, and only typos get corrected in later printings. The mainline repo is like a revised edition that adds new chapters while keeping the same binding. Rawhide is the author's working manuscript. It changes daily, and pages might get ripped out before the final print.
Run dnf upgrade --refresh before pulling kernel updates. The refresh flag forces the package manager to check for new repository metadata instead of using cached lists. Stale metadata causes phantom dependency errors.
Pulling the mainline update
Fedora packages the kernel as a meta-package that pulls in the core binary, architecture-specific modules, and firmware. You do not need to compile anything. The package manager handles initramfs generation automatically during the transaction. Here is how to pull the latest mainline kernel for your current release.
sudo dnf install kernel
# The meta-package resolves to the newest kernel-core, kernel-modules, and kernel-modules-extra available in your enabled repos.
sudo reboot
# A full reboot is required because the running kernel cannot replace itself while active.
The transaction will download the new packages, build a fresh initramfs image, and update the boot loader configuration. The old kernel remains on disk as a fallback. If you need the absolute latest development kernel from Rawhide, you must explicitly enable that repository first. Rawhide packages are not signed with the stable release keys, so the package manager will warn you about GPG verification.
sudo dnf config-manager --set-enabled rawhide
# Enables the development repository. This changes your system's package priority and may pull in newer user-space libraries.
sudo dnf install kernel
# Pulls the latest kernel from Rawhide. This may override your current stable kernel version.
sudo reboot
# Boots into the new development kernel. Verify hardware support before continuing daily work.
Keep a terminal session open on the old kernel before rebooting. If the new kernel fails to load, you can drop to a TTY and revert the repository configuration without hunting for a live USB.
Verify the new kernel is active
A successful installation does not guarantee a successful boot. The boot loader might still point to the old entry, or the initramfs might fail to mount your root filesystem. Check the running kernel version immediately after login.
uname -r
# Prints the exact version string of the currently running kernel. Compare this to the package version you just installed.
If the output matches the new version, the boot process completed correctly. You can also inspect the available kernels and the default boot entry.
dnf list kernel
# Shows installed and available kernel packages. Look for the 'installed' tag next to the new version.
grubby --default-kernel
# Prints the path to the kernel that GRUB will select by default. Fedora usually points this to the newest installed kernel.
Check the kernel ring buffer for driver initialization messages. The journalctl command filters cleanly for kernel output.
journalctl -k --no-pager | tail -20
# The -k flag restricts output to kernel messages. The --no-pager flag dumps directly to stdout for easy scanning.
Look for your new hardware being probed and bound to a driver. If the device still shows no activity, the kernel version is correct but the specific driver module may need to be loaded manually or may require a newer firmware package.
Run journalctl -xe if the system hangs during boot. The x flag adds explanatory context to error lines, and the e flag jumps to the end of the log. Read the actual error before guessing.
Common pitfalls and recovery
Mixing repository streams breaks dependency resolution. If you enable Rawhide and then run a full system upgrade, dnf will try to replace stable user-space packages with development versions. This triggers transaction conflicts.
Error: Transaction test error: package kernel-core-6.9.0-0.rc1.100.fc42.x86_64 conflicts with kernel-core provided by kernel-core-6.8.5-200.fc40.x86_64
The conflict is intentional. Fedora prevents two different kernel major versions from coexisting in the same boot environment. The package manager refuses to proceed to avoid leaving the system in an unbootable state. Do not force the transaction with --skip-broken. That flag masks missing dependencies and leaves the initramfs incomplete.
If you accidentally pull a Rawhide kernel and the system fails to boot, drop to the GRUB menu. Highlight your previous stable kernel entry and press e to edit. Remove any initrd= lines that point to the broken version, then press Ctrl+X to boot. Once inside the old kernel, disable the development repository and reinstall the stable kernel.
sudo dnf config-manager --set-disabled rawhide
# Cuts off the development stream. This prevents accidental package drift during future upgrades.
sudo dnf distro-sync
# Aligns all installed packages back to the versions available in your stable repositories.
sudo dnf install kernel
# Restores the stable kernel package. The package manager will regenerate the correct initramfs.
sudo reboot
# Returns to a known-good state. Verify the boot menu reflects the stable version.
Another common issue involves third-party kernel modules like NVIDIA drivers or VirtualBox. These modules compile against the exact kernel version they were built for. When you install a newer kernel, the old module binaries become incompatible. The system will fall back to a generic driver, or the hardware will fail to initialize. Rebuild the external modules after the kernel update.
sudo dnf install akmod-nvidia
# The akmod package automatically recompiles the NVIDIA driver against the new kernel during boot.
sudo reboot
# Triggers the automatic module build. Check dmesg for successful module loading.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Kernel module parameters belong in /etc/modprobe.d/, not in the package directories.
Trust the package manager. Manual file edits drift, snapshots stay.
Choose the right kernel source
Use the stable release kernel when you need a predictable system for daily work, server services, or hardware that is already supported. Use the mainline kernel repository when you need newer hardware support or bug fixes that have not been backported to your current release. Use Rawhide when you are testing development features, contributing to Fedora, or preparing for the next major release cycle. Build a custom kernel from source when you need to strip out unused drivers, enable experimental patches, or match a specific embedded hardware configuration. Stay on the upstream Workstation defaults if you only deviate from the standard package set occasionally.
Snapshot the system before the upgrade. Future-you will thank you.