Over time, any Linux server accumulates traces of past updates. Each new kernel version is installed separately, and previous versions usually remain on the system. Over time, the /boot partition gradually fills up, which can cause the next update to fail, and after a reboot, the server may not start at all.
The solution seems simple: all you need to do is delete old kernel versions in a timely manner to free up disk space. But this is an extremely critical task that must be approached with the utmost care, because if you accidentally delete the current or only working version of the kernel, instead of gaining a few hundred megabytes of free space, you may end up with a server that you’ll have to restore using a Live ISO, Rescue Mode, or a virtual machine console.
In this article, let’s explore together why Linux stores multiple kernel versions in the first place, in which cases it’s actually worth deleting them, and how to perform the cleanup so that the server continues to operate normally after the next reboot.
Why Old Kernels Accumulate and When It’s Time to Remove Them
When updating Linux, a new kernel version is installed as a separate package. The previous version is not replaced but remains on the system unchanged. This is done in case problems arise after the update with drivers, the RAID controller, the hypervisor, or other critical hardware. In such cases, you can always boot from the previous kernel via the GRUB menu and restore server operation as quickly as possible.
This is precisely why Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS, and many other distributions do not automatically remove old versions.
As we’ve already seen, their number grows over time, and at some point on a server that has been regularly updated for several years in a row, it’s easy to find a dozen or even more installed kernels. For users of VPS servers, the situation often becomes critical, since the /boot partition there often has a capacity of only 512 MB or 1 GB, so free space runs out much faster.
It’s also worth remembering another feature of servers - they can run without rebooting for months, or even years. During this time, the system may install several new kernels, even though it continues to use a version that was loaded long ago.
Of course, it’s not worth deleting old kernels just for the sake of tidiness; as long as there’s enough space and updates proceed without errors, they serve as a safety net.
However, the main reason for cleaning up is usually a nearly full /boot partition. You can check its status with the command:
df -h /boot
For example:
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 974M 905M 19M 98% /boot
If this partition is more than 80-90% full, it’s best to clean it up in advance; otherwise, the next kernel update may fail.
There are other signs that it’s time to remove accumulated kernels:
- too many old versions are installed;
- updates via APT or DNF fail;
- the GRUB menu has become noticeably longer;
- backups take up more space;
- when installing updates, the system reports insufficient free space.
In general, you should approach this issue sensibly and remove kernels only when they start to interfere with the system’s operation, not simply because there are too many of them. That said, it’s best to keep a few previous versions, as they may come in handy if something goes wrong after the next update, as we mentioned above.
How to Check What Can Be Deleted
Before deleting anything, make sure that the space in the /boot partition is actually occupied by old kernels and not by any other files.
First, check how much free space is left on this partition:
df -h /boot
Then view the contents of the directory:
ls -lh /boot
or estimate the size of each file:
du -sh /boot/*
If the problem is specifically due to old kernels, you’ll see several similar sets of files, for example:
vmlinuz-6.8.0-64-generic initrd.img-6.8.0-64-generic System.map-6.8.0-64-generic config-6.8.0-64-generic
Each installed kernel version stores its own set of these files, and just a few old versions can easily take up hundreds of megabytes. If, however, the partition is nearly full but there are only a few old kernels, you should look elsewhere for the cause - for example, check the logs, memory dumps, or additional boot files. Once we have determined that the problem is indeed caused by the old kernels, we can proceed to the most important and critical step.
IMPORTANT! Before deleting anything, be sure to find out which kernel the system is currently using. Under no circumstances should you delete that one.
You can find out the current kernel version with a single command:
uname -r
For example:
6.8.0-64-generic
After that, you should check the list of all installed kernels.
In Ubuntu and Debian:
dpkg --list | grep linux-image
Example output:
ii linux-image-6.8.0-62-generic ii linux-image-6.8.0-63-generic ii linux-image-6.8.0-64-generic
In AlmaLinux, Rocky Linux, CentOS, and other RPM distributions, a different command is used:
rpm -qa | grep kernel
For example:
kernel-5.14.0-503.el9.x86_64 kernel-5.14.0-570.el9.x86_64 kernel-5.14.0-620.el9.x86_64
That’s it - now the picture is completely clear.
We can see which kernel is currently loaded, which versions remain from previous updates, and which ones can already be considered for removal. However, remember that you shouldn’t keep only the current, working kernel - it’s always better to keep at least the previous kernel, which can serve as a backup in case the current kernel crashes or you update to a new one.
How to Properly Remove Old Kernels
The most common mistake is deleting kernel files manually. Sometimes you may even come across recommendations to delete all files and directories from the /boot partition, or to delete individual kernel files. Do not do this!!!
The files in the /boot directory are linked to the distribution’s package system, and if you delete them using the standard rm command, the package manager will continue to consider the kernel installed. This can result in a corrupted package database, errors during subsequent updates, or problems with GRUB configuration generation.
Therefore, kernels should only be removed via the package manager. It not only removes the files but also correctly updates information about packages, dependencies, and the boot loader.
Ubuntu and Debian
On Debian-based systems, kernels are installed via the APT package manager. Therefore, if you need to remove a specific version, use the command:
sudo apt remove linux-image-6.8.0-62-generic
However, this command is rarely used, and it’s usually sufficient to run:
sudo apt autoremove
In this case, APT will automatically find old kernel versions that are no longer in use and offer to remove them.
If you need to remove any remaining configuration files along with the packages, run:
sudo apt autoremove --purge
This method is considered the safest, since APT takes dependencies into account and will prevent you from accidentally removing the kernel that the system is currently running on.
AlmaLinux, Rocky Linux, CentOS, and other RHEL-based distributions
In this family of distributions, kernels are also installed as separate packages, but using the DNF package manager. If necessary, you can remove a specific version with the command:
sudo dnf remove kernel-5.14.0-503.el9.x86_64
However, administrator intervention is usually not required at all, since DNF can automatically limit the number of installed kernels. This is controlled by the installonly_limitparameter, whose value can be checked as follows:
grep installonly_limit /etc/dnf/dnf.conf
The output looks like this:
installonly_limit=3
This means the system retains the three most recent kernel versions. After installing a new update, the oldest version is automatically removed. For most servers, this buffer is sufficient, as it allows for a rollback in case of problems, and the /boot partition does not fill up unnecessarily.
What to do if the /boot partition is already full
Sometimes the problem is discovered too late; for example, during the next update, the system reports that there is no free space left.
For example, APT might display the following error in such a case:
No space left on device
or:
cannot write compressed block
In this situation, you shouldn’t try to quickly free up space by manually deleting files from the /boot directory - this can only make the problem worse.
It’s better to proceed step by step:
- Determine which kernel is currently in use with the `uname -r` command;
- View the list of installed kernels;
- Remove one or two of the oldest versions using the package manager;
- Run the system update again.
This procedure allows you to free up space without the risk of corrupting the package repository or disrupting the bootloader’s operation.
What to Do with Kernel Modules and DKMS
Along with the kernel, the system also stores its modules. They are located in the directory:
/lib/modules/
If the kernel is removed via APT, DNF, or another package manager, the corresponding directory in /lib/modules is usually removed automatically, and there is no need to clean it up manually.
If any directories remain after removing the kernel, first make sure that the kernel package itself has actually been removed. Only then does it make sense to investigate why the package manager did not perform the cleanup.
Servers using DKMS modules require special attention. These modules are automatically recompiled whenever a new kernel is installed. This applies, for example, to ZFS, proprietary NVIDIA drivers, VirtualBox, certain file systems, and some network drivers.
After an update, it is advisable to verify that the recompilation completed without errors:
dkms status
If a module did not build for the new kernel, drivers, hardware, or the file system may stop working after a reboot. For this reason, on servers with DKMS, you should first ensure that the new kernel version works correctly before proceeding to remove the previous ones.
Don’t forget about GRUB
After removing old packages, the boot loader is usually updated automatically, but for various reasons, this sometimes does not happen. For example, if the system was restored after a crash, the removal was performed in a non-standard way, or errors occurred during the update. In such cases, it’s best to rebuild the GRUB configuration manually.
In Ubuntu and Debian, use the following command:
sudo update-grub
In AlmaLinux, Rocky Linux, CentOS, and other distributions in the RHEL family, use the following command:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
After that, on the next reboot, open the GRUB menu and verify that only the current kernel versions remain in the list.
Why You Shouldn’t Delete Old Kernels Immediately After an Update
It’s best not to rush to clean up immediately after installing a new kernel, since a successful boot doesn’t necessarily mean the system is fully functional. The new kernel may contain changes that affect device drivers, the network stack, virtualization, or file systems. Some issues only become apparent after several hours or even days of normal operation.
You should be especially cautious on servers where downtime is unacceptable, such as:
- database servers;
- mail servers;
- Kubernetes clusters;
- VMware or KVM virtualization nodes;
- production web servers;
- data storage servers.
Consider a scenario where, after updating Ubuntu on a server with a hardware RAID controller, a new HWE kernel is installed. The system reboots successfully, but the controller driver turns out to be incompatible with the new version.
If the previous kernel remains on the system, simply selecting it from the GRUB menu will make the server available again, and the driver can be updated later. However, if the old version was removed beforehand, recovery will require Rescue Mode, a Live ISO, or a connection via the provider’s remote console.
For this reason, experienced administrators usually keep at least one previous working kernel. Once the new version has run error-free for a few days, the old packages can be removed without undue risk. We’re mentioning this for the third time for a reason - it’s really important!
Practical Recommendations for Safe Cleanup
If you have a single home server, it’s perfectly fine to remove old kernels manually. But in a large infrastructure, this approach quickly becomes unworkable. When there are dozens or hundreds of servers, cleanup is usually automated using unattended-upgrades in Ubuntu and Debian, dnf-automatic in RHEL-based systems, Ansible, or other configuration management systems such as Puppet and Salt. It’s helpful to automate not only the installation of updates but also the monitoring of free space in the /boot partition. This allows you to detect a problem before the next update fails.
Regardless of whether the cleanup is performed manually or automatically, it’s worth performing a few simple checks before deleting anything:
- identify the active kernel using the command
uname -r; - make sure the new kernel has been running without errors for some time;
- check how much free space remains in the
/bootpartition; - keep at least one previous working version of the kernel;
- remove packages only via APT, DNF, or another package manager;
- ensure that an emergency console is available (HTML5 Console, VNC, IPMI, or Rescue Mode);
- verify that a current backup is available;
- update the GRUB configuration if necessary;
- perform a test reboot and verify that the system booted with the correct kernel.
You shouldn’t remove all old versions at once. It’s much safer to clean up gradually, while retaining the ability to quickly roll back to a previous working kernel. Furthermore, in all standard scenarios, it’s better to use the package manager’s capabilities. It properly removes the kernel, updates the package repository, cleans up related files, and reduces the risk of encountering problems after the next reboot.
FAQ or Frequently Asked Questions
How many old kernels should you keep?
For most servers, it’s sufficient to keep one previous working version. Many distributions automatically keep the three most recent kernels, and this is usually quite sufficient.
Can I remove a kernel without rebooting?
Yes. Removal does not affect the kernel that is already loaded. The changes will take effect only after the next reboot.
Do I need to manually delete files from /boot?
No. All operations should be performed exclusively through the package manager.
What should I do if the server stops booting after removing the kernel?
Use the provider’s emergency console (VNC, HTML5 Console, IPMI, or Rescue Mode), boot from an available kernel version, or restore the system using a Live ISO.
Do I need to clean up /lib/modulesseparately?
No. When a package is removed correctly, the corresponding modules are removed automatically.
How often should I perform a cleanup?
There is no specific schedule. It is usually sufficient to check the system’s status after major kernel updates or when the /boot partitionis approaching 80-90% capacity.
Conclusion
Removing old kernels is a routine procedure in the maintenance of any Linux server. And if you follow simple rules - don’t touch the active kernel and always keep one previous kernel as a backup - problems rarely arise.
It’s best to use the built-in package manager for cleanup. APT and DNF correctly remove the kernel, update package information, and keep the bootloader up to date. Manual removal of files from /boot, however, offers no such guarantees and can lead to problems as early as the next update or reboot.
If the server receives updates regularly, check the status of the /boot partition from time to time and make sure it doesn’t become full. For VPS and dedicated servers, this is just as much a part of regular maintenance as checking backups, monitoring disks, or reviewing system logs. A few minutes of preventive maintenance usually costs much less than restoring the server after a failed boot.
