You hit a full /boot partition during an upgrade
You run dnf upgrade --refresh and the transaction halts before it even downloads the first package. The terminal prints a clear refusal: Error: Transaction test error: package kernel-6.8.11-200.fc40.x86_64 requires /boot space, but only 12MB available. You check df -h and see /boot sitting at 99 percent. You remember installing Fedora six months ago and running every release update since. The system kept every kernel version just in case. Now the disk is full and the upgrade path is blocked.
Reboot before you debug. Half the time the symptom is gone.
How Fedora tracks kernel versions
Fedora treats the kernel as an install-only package. The package manager maintains a configuration variable called installonlypkgs. By default, this list contains kernel, kernel-core, kernel-modules, kernel-modules-extra, and kernel-modules-extra. The installonly_limit is set to three. This means dnf will keep three versions of each kernel package on disk. One is the currently running kernel. One is the candidate for the next boot. One is a fallback in case the new version fails to load.
Every time you apply a release update, a new kernel package lands in /boot and /lib/modules. The package manager also triggers dracut to generate a new initramfs image. The initramfs contains the drivers needed to mount your root filesystem and apply LUKS decryption keys. If the initramfs does not match the kernel, the system cannot boot. That is why dnf refuses to drop kernels automatically. It protects you from orphaned initramfs files and broken module dependencies.
The /boot partition is often small. Many default installations allocate 512 megabytes or 1 gigabyte. When three kernels plus their initramfs images and Intel/AMD microcode files fill that space, dnf stops. It does not guess which version to delete. It waits for explicit instruction.
Run journalctl -xe after a failed boot. Read the actual error before guessing.
The standard cleanup command
The package manager provides a built-in flag that calculates which kernel packages exceed the configured limit and removes them in a single transaction. You do not need to parse rpm output or manually match version strings.
Here is how to safely drop all kernel packages that exceed the default retention limit.
# List the current kernel packages to see what is on disk
rpm -qa | grep kernel
# Identify the currently running kernel to ensure you never delete it
uname -r
# Remove all kernel packages older than the limit while keeping the running and next-boot versions
sudo dnf remove --oldinstallonly
# Confirm the transaction by pressing y when prompted
# WHY: --oldinstallonly tells dnf to compare installed versions against installonly_limit
# WHY: dnf automatically removes matching initramfs and microcode packages
# WHY: the transaction aborts if it would touch the currently running kernel
The command compares every installed kernel package against the installonly_limit. It marks the oldest versions for removal. It also removes the corresponding initramfs-<version>.img files from /boot. The package manager handles dependency resolution. You do not need to run dracut manually. The remaining kernels already have valid initramfs images.
If you run this command on a system that has not been upgraded in months, you might see a long list of packages marked for removal. That is normal. The package manager only deletes what is mathematically older than the limit.
Snapshot the system before the upgrade. Future-you will thank you.
Verify the removal
You need to confirm that the oldest kernels are gone, the running kernel is untouched, and /boot has reclaimed space.
Here is how to check the partition usage and verify the remaining kernel packages.
# Check available space on the boot partition
df -h /boot
# List the remaining kernel packages to confirm the count matches the limit
rpm -qa | grep kernel
# Verify the running kernel matches one of the installed packages
uname -r
The df -h /boot output should show a noticeable drop in usage. The rpm -qa list should contain exactly three kernel versions. The uname -r output must match one of those versions. If the running kernel does not appear in the list, the package manager refused to remove it. That is the expected safety behavior.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and error patterns
The most frequent mistake is trying to remove the currently running kernel. The package manager will block the transaction and print Error: Cannot remove running kernel. This is intentional. Removing the active kernel leaves the system without module support for the next boot. If you see this error, run uname -r and verify that the version you are targeting is different.
Another common pattern appears when you manually delete files from /boot instead of using dnf. The package database still thinks the kernel is installed. The next dnf upgrade will try to reinstall it, or worse, it will generate a new initramfs for a kernel that no longer has its core files. Never touch /boot with rm. Let the package manager handle file lifecycle.
You may also encounter a transaction test error when dnf cannot write the new kernel package to disk. The error reads Error: Transaction test error: package kernel-6.x.y requires /boot space. This happens when the partition is completely full. You must free space first. Run the --oldinstallonly command. If the partition is still full, check for leftover initramfs files or old grub.cfg backups. Remove them with sudo dnf remove.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use sudo dnf remove --oldinstallonly when you want the package manager to handle the math and keep the safe default count. Use sudo dnf remove kernel-6.x.y.fc40.x86_64 when you need to drop a specific broken build while keeping the rest. Use sudo dnf config-manager --setopt=installonly_limit=2 when you are running a minimal server and only need the current and next kernel. Stick to the default limit when you dual boot or frequently test hardware drivers that require older kernel modules.
Trust the package manager. Manual file edits drift, snapshots stay.