Ask
25

The boot partition filled up and updates now fail — what is safe to delete?

Package updates on a small server started failing with no space left on the boot partition. It is a separate, fairly small partition, and it has filled with what look like several kernel versions.

I am reluctant to delete anything there by hand, since it is the partition the machine starts from and I would rather not learn what happens if I remove the wrong file.

What is safe to remove, and how do I stop it happening again?

4 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @sysadmin_sinem · 6d ago

    Your caution is right, and the safe route is to let the package manager remove old kernels rather than deleting files.

    First, find out which kernel you are actually running:

    uname -r
    

    Never remove that one, and keep at least one other as a fallback. Everything older than those two is a candidate.

    Then use the package manager's own cleanup, which knows what belongs to what and updates the bootloader afterwards. On Debian-family systems that is the autoremove operation, which is aware of which kernels are still needed; on others there is an equivalent that keeps a configured number of versions.

    The reason to avoid deleting by hand is not that the files are magic — it is that the bootloader configuration still references them afterwards. A machine that boots into a rescue prompt because the entry points at a kernel you deleted is a much worse afternoon than a full partition.

    30
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @serial_soner · 5d ago

    One thing worth checking while you are there: whether the partition is actually full of kernels, or of something else.

    Sort the directory by size before assuming. I have found a crash dump, a stray backup somebody wrote to the wrong path, and once an entire copy of a home directory. Deleting old kernels in that situation frees very little and you conclude the cleanup did not work.

    13
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @containers_koray · 3d ago

    To stop it recurring, which is the more useful half:

    Cap how many kernels are kept. Most distributions have a setting for this and the default is often more generous than a small boot partition can hold. Two or three is plenty.

    Make unattended upgrades clean up after themselves. If automatic updates are enabled and cleanup is not, the partition fills on a schedule. This is the usual cause of it happening at all.

    Monitor it. A small boot partition is the classic disk that nobody watches because it never changes — until it does. Any alert on percentage used catches it weeks before it breaks anything.

    And if this machine is one you build repeatedly, consider a larger boot partition next time. The sizes that were generous a few years ago are tight now, because boot images have grown.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @sysadmin_sinem · 3d ago

    The chicken-and-egg case, which is why this is annoying: sometimes the partition is so full that the package manager cannot complete the removal, because it wants to regenerate a boot image and has nowhere to put it.

    The way out is to make a little room by hand first, carefully:

    • The initial ramdisk images are the largest files there. Removing one belonging to an old kernel — not the running one, not the newest — usually frees enough to let the proper cleanup run.
    • Then immediately run the package manager's cleanup, and let it fix the bootloader configuration.

    After that, check the bootloader menu is sane before rebooting, and reboot at a time you can get to a console if it goes wrong. On a remote machine with no console access, that is the moment to be genuinely careful.

    26
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report