It's possible to delete just about any file manually, including kernels and initial RAM disks (initrds); however, when the file was installed by a package (as these were), deleting them manually leaves the package system in an inconsistent state. Thus, deleting the files manually is not recommended. I have three suggestions for how to proceed.
My first choice is this:
uname -r to discover what kernel you're currently running. For instance, one of my systems returns
ls /boot/vml* to see all your installed kernels.
- Select a kernel from those listed that is not the one you're currently using, and that's not the oldest one (which is probably the "base" of the kernel series). The kernel that comes just "before" the one you're running is a good candidate. That might be
vmlinuz-4.8.0-46-generic, for example.
dpkg -S /boot/vmlinuz-4.8.0-46-generic, changing the kernel version as necessary. (Note that's an uppercase
-S in the command.) This should reveal the package name associated with that kernel. In this example, it's
linux-image-4.8.0-46-generic. Note that you should not pass a kernel with a name that ends in
dpkg -S; these kernels are installed in a different way that won't work with this command.
sudo dpkg -P linux-image-4.8.0-46-generic (changing the kernel version number, of course). This tells the system to delete the package. This may is likely to result in a complaint about broken dependencies. In this case, you should add the package(s) it claims as being dependent on the one you said to remove. In my case, I had to make the command
sudo dpkg -P linux-image-4.8.0-46-generic linux-signed-image-4.8.0-46-generic linux-image-extra-4.8.0-46-generic (deleting three packages rather than one).
- With any luck, the preceding command will work and clear up enough space for
sudo apt-get autoremove to work.
If this doesn't work, then I recommend manually deleting the
.efi.signed version of a kernel you're not using, if it's present. These files are not installed directly; they're created by merging the standard kernel image with a small signature file installed from another package. Thus, deleting them won't upset the package system in the same way that manually deleting a non-signed kernel file will. Note, however, that if Secure Boot is active on your computer, or even if it's not but GRUB is configured to boot through the
.efi.signed version of the kernel, deleting this file will make it impossible to boot that kernel. Thus, it's important that you not delete the
.efi.signed version of a kernel you're currently using.
Another approach is to temporarily move your
/boot directory off of its separate partition and onto the regular root (
/) filesystem. Note that although I've done similar things for other reasons, I've not tried this exact procedure for your exact reason; but it should work. Note also that this is rather risky; a mistake at the wrong point could render your system unbootable! If you're willing to take the chance, the procedure is:
sudo mkdir /boot2 to create the
/boot2 directory that will temporarily house your kernels.
sudo umount /boot/efi. This command will fail on BIOS-based computers, but is necessary if your computer boots via EFI.
sudo cp -a /boot/* /boot2/ to copy everything from
sudo umount /boot to unmount the
sudo rm -rf /boot. This deletes the old
/boot mount point and any files that may have wound up accidentally placed "under" it.
sudo mv /boot2 /boot. This renames your copy to the original location, as far as Linux is concerned.
- Proceed with your
sudo apt-get autoremove operation. This should succeed.
sudo mv /boot /boot2 to move the updated copy of your kernels out of the way.
sudo mkdir /boot to create a fresh mount point for your
sudo mount /boot to restore the original
/boot partition. Note that it will still be too full.
sudo rm -rf /boot/* to delete the contents of the original
sudo cp -a /boot2/* /boot/ to copy your modified
/boot directory to the
- Reboot to be sure everything works.
sudo rm -rf /boot2 to delete the temporary files.
A mistake (either by me or by you) could create serious problems, including a complete inability to boot the system. Thus, this approach is something of a last-resort one.
It's imperative that you do a periodic
sudo apt-get autoremove to keep the
/boot partition from overfilling. Personally, I do this almost every time I upgrade my packages, and especially if I notice a new kernel was installed. Note that there are a couple of official bugs related to this issue:
The first of those bugs can be fixed for existing systems, but for various reasons even the official released fix isn't 100% effective. The second bug is about a choice made at system installation time, so existing systems continue to suffer from a too-small
/boot partition moving forward. The only way to fix that issue is to resize your partitions to increase the size of
/boot. Personally, I consider 500 MiB a minimum reasonable size for
/boot these days.