How to remove old Linux Kernels on Fedora (2026)

Every Fedora update leaves at least one old Linux kernel behind, and DNF keeps three installed by default unless you tell it otherwise. That is normally fine, since a spare kernel gives you a way back if a new one breaks Wi-Fi or graphics. But once storage runs low or the GRUB menu gets cluttered, cleaning up old kernels on Fedora becomes worth doing. This guide covers manual removal, automatic cleanup, and the DNF5 changes that broke the old one-line command.

Why do you need a Newer Kernel?

For most of the people? You don’t. New kernels usually add support for new hardware (such as Graphics card) or usually fix some vulnerabilities in the software. If you are not using the latest hardware, then you don’t have to worry about the update. But, sometimes the developers of hardware manufactures (such as AMD) fix drivers for older hardware which results in improved performance and breathes new life in your old PC however, those cases are rare. Vulnerabilities usually affect the servers which are running Linux, rather than the Desktop Operating systems. However, it is considered a good practice to fix those vulnerabilities nonetheless and update to the latest Kernel as the older ones reach their end of life.

Why should you keep older kernels installed?

I usually do very basic things on my PC, usually web browsing, offline Music and Movie playback and rarely playing some games on Steam. These tasks do not get affected much by the version of Kernel I am using (mind you, I have an AMD GPU), however, if you are using an NVIDIA GPU on your PC or Laptop the version of Kernel and driver do affect your PC performance. If you feel that using the new kernel results in glitches while using your PC, having an older kernel installed will always give you a backup plan to fall back on. Simply reboot your PC and use the older Kernel.

Checking how many Kernels are installed

In order to check how many Linux kernels are installed on our Fedora system, we can take advantage of the dnf list command along with grep by piping the two commands as shown below:

dnf list installed | grep kernel

As you can see, all the packages which has ‘Kernel’ in their names get listed automatically along with the repositories from where they are installed (I’m using Nobara Linux which is based on Fedora, on your PC, the repository column should mention Fedora)

Modern Fedora kernels aren’t a single package. They’re split across kernel-core, kernel-modules, kernel-modules-core and a few smaller ones, a modularization that lets DNF pull down a smaller RPM set on ordinary updates instead of one large kernel blob every time. Fedora also ships a new release roughly every six months and supports each one for about thirteen months, so kernel updates land often and old ones pile up faster than on slower-moving distros.

Check your running and default kernel before removing anything

Before removing anything, confirm which kernel is actually running and which one GRUB boots by default. These can differ if you’ve pinned an older version as the default with grubby.

uname -r
sudo grubby --default-kernel

uname -r shows the kernel currently loaded in memory. sudo grubby --default-kernel shows which one GRUB picks automatically once the boot timeout runs out, which matters if you’ve deliberately set an older kernel as the safe default after a bad update. DNF only protects the running kernel automatically, not whatever grubby has pinned as default, so check both before removing anything you might still need.

Method 1: removing one old kernel on Fedora

You can proceed with the uninstallation of a kernel by typing the following command:

sudo dnf remove kernel-core-FULL_VERSION.x86_64

Replace FULL_VERSION with the version string you want gone, for example kernel-core-6.13.5-200.fc41.x86_64. Leave at least one kernel-core package installed so your system can still boot, and don’t try to remove individual kernel modules on their own since that can break the kernel that’s left behind.

Fixing the “protected packages” error

DNF refuses to remove the kernel you’re currently running, and on some setups it also throws a “protected packages” error against kernel-core even when you targeted an older version. This usually traces back to kernel-headers packages tagging along. Instead of guessing the exact kernel-core string, build the removal list from rpm directly:

sudo dnf remove $(rpm -qa | grep ^kernel | grep 6.13.5 | grep -v headers)

Swap 6.13.5 for the version you’re removing. This grabs every package tied to that kernel version except headers, which sidesteps the protection check that trips people up on this exact error.

Cleaning up leftover kernel-devel and headers packages

Removing kernel-core doesn’t always clear out kernel-devel or kernel-headers for the same version, since DNF doesn’t treat them as hard dependents of kernel-core. If you’ve ever compiled DKMS modules for Nvidia drivers or VirtualBox, these can pile up unnoticed alongside the kernels they matched.

rpm -qa | grep -E 'kernel-(devel|headers)'
sudo dnf remove kernel-devel-OLD_VERSION.x86_64 kernel-headers-OLD_VERSION.x86_64

List the installed devel and header packages first and confirm which versions match kernels you’ve already removed. Keep the pair matching your current running kernel, since DKMS-built modules need matching headers to rebuild whenever a kernel update comes through.

Method 2: removing every old kernel automatically

Fedora used to ship a one-line command that cleared out every kernel except the newest ones in a single pass. It doesn’t work anymore. Fedora switched its default package manager to DNF5 starting with Fedora 41, and DNF5 dropped the --oldinstallonly flag without shipping a direct replacement, so running the classic command now just errors out with “argument is not in dnf remove.”

The current workaround uses repoquery instead:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1)

--installonly filters the query down to install-only packages, which is what kernels are flagged as. --latest-limit=-1 tells DNF to keep the single newest version installed and list every older one for removal. Bump that number to -2 or -3 if you want to keep more than one kernel around as a fallback.

Make sure you’re booted into the kernel you intend to keep before running this, since DNF5 protects only the currently running kernel from removal by default, not whichever one you’d prefer to keep.

Checking how much space old kernels are using

Each installed kernel with its modules typically takes 150 to 300MB across /boot and /lib/modules. On a small /boot partition of 500MB to 1GB, three or four accumulated kernels can fill it completely and block future updates outright.

du -sh /lib/modules/*
df -h /boot

Run these before and after a cleanup to see how much you actually recovered. A full /boot partition is one of the more common reasons a Fedora kernel update fails partway through, so checking free space occasionally is worth the few seconds it takes.

DNF4 vs DNF5: what changed for kernel cleanup

DNF5 is a full rewrite, built in C++ instead of DNF4’s Python, aimed mainly at faster startup and lower memory use on constrained systems. It became the default package manager starting with Fedora 41, which is also why command syntax that worked fine on Fedora 40 quietly breaks after an upgrade.

A couple of version notes worth keeping in mind:

• Fedora 41 was the first release to default to DNF5
• Fedora 43 and 44, the versions supported as of this writing, both still run on DNF5

Configuring the maximum installed kernels

You can edit the dnf.conf file located in the /etc/dnf directory and set how many kernels stay installed at a given time. The default is three, but you can reduce it to two (one is not a valid value, since DNF always needs a fallback to protect). Open the file with admin privileges using any text editor:

Find the installonly_limit line and change the number after the equals sign. Setting it to 2 keeps the current kernel plus one fallback. Save with Ctrl+O then Ctrl+X in nano, or Escape then :wq in Vim.

This setting only takes effect on future kernel installs. It won’t retroactively delete kernels already sitting on disk, so pair it with Method 2 if you need space back right away.

Fixing a kernel that won’t leave the GRUB menu

Sometimes dnf remove reports success, rpm -q kernel-core shows only one version left, and the old kernel still shows up in the GRUB menu anyway. This has tripped up enough Fedora users on the Fedora Discussion forums that it’s worth a dedicated fix.

Start by rebuilding the GRUB config:

sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Use /boot/grub2/grub.cfg instead of the EFI path if your system boots in legacy BIOS mode rather than UEFI. If the stale entry survives even this, check for a leftover boot loader entry file:

ls /boot/loader/entries/

Fedora uses grubby and BootLoaderSpec (BLS) entry files here instead of hand-editing grub.cfg directly, and an orphaned .conf file in that directory is usually what’s actually driving the phantom menu item. Removing the leftover entry for the version you already uninstalled, then rerunning grub2-mkconfig, clears it for good.

Should you use a cleanup script instead?

A handful of small community shell scripts, such as the MIT-licensed kernel_cleaner project on GitHub, wrap the dnf commands above into an interactive prompt. They’re fine for a quick one-off cleanup on a desktop you manage yourself, but they’re unofficial, unmaintained side projects rather than something Fedora ships or supports. Running the dnf and repoquery commands directly, or setting installonly_limit once, covers the same ground without adding a third-party script to your system.

Key takeaways

• Fedora keeps three kernels installed by default, configurable via installonly_limit
• DNF5 (Fedora 41+) removed the old –oldinstallonly shortcut with no direct replacement
• Use dnf repoquery –installonly –latest-limit=-N to find and remove old kernels
• Never remove the kernel you’re currently running, DNF blocks it by default
• A stuck GRUB entry usually means a leftover file in /boot/loader/entries
• Leave at least one kernel-core package installed at all times
• installonly_limit changes only apply to future kernel installs, not existing ones

Frequently asked questions

Why does dnf say a kernel package is protected when I try to remove it?

DNF protects your currently running kernel and sometimes flags kernel-headers as a dependency conflict. Boot into a different kernel, or filter headers out with grep -v headers.

Does removing old kernels free up much disk space?

Each kernel with its modules typically takes 150 to 300MB in /boot and /lib/modules. Removing two or three old ones can free half a gigabyte, which matters most on small /boot partitions.

What is the minimum number of kernels Fedora will let me keep?

DNF’s installonly_limit accepts 2 as the lowest usable value. Setting it to 1 is explicitly disallowed, since DNF always needs one fallback kernel to protect during upgrades.

Will –oldinstallonly ever come back in DNF5?

An open GitHub issue tracks it, but as of this writing it’s marked low priority. The repoquery-based workaround is the closest supported replacement in the meantime.

Does this process work on Fedora Silverblue or other Atomic Desktops?

No. Atomic variants use rpm-ostree instead of DNF, and old deployments get pruned automatically. None of the dnf remove or dnf.conf steps here apply on those systems.

Can I remove a kernel without rebooting into another one first?

No, DNF always protects the kernel you’re currently running. You have to reboot into a different installed kernel before that version can be removed.

Why do I still see a rescue kernel entry after removing the others?

Fedora keeps a separate rescue boot entry for emergency recovery no matter how many normal kernels remain installed. installonly_limit and the removal commands above don’t touch it.