Safely Cleaning the Boot Partition on elementary OS

Elementary OS is celebrated for its calm, macOS-inspired interface and a desktop philosophy that prizes focus over clutter. Underneath that polished surface sits a foundation built on Ubuntu LTS, and like every Debian-derived distribution, it accumulates kernel packages, initramfs images and bootloader entries over time. When the small EFI or /boot partition runs out of room, the system refuses to install further updates, sometimes mid-way through an upgrade, leaving you with a partially updated machine.

Many Australians who switched to elementary OS did so after tiring of the bloat shipped with Windows and the constant telemetry prompts of macOS Sonoma. They tend to run on hardware bought locally from JB Hi-Fi or ordered online from Mwave, often refurbished ThinkPads or older MacBooks handed down from family members. These machines frequently came with small SSDs where the manufacturer left a separate EFI System Partition sized for Windows rather than Linux, which is why cleaning up the boot partition becomes urgent sooner than expected.

The process is not difficult, but it requires patience and a calm head. Removing the wrong package or wiping an entry that GRUB still expects can leave you staring at a recovery prompt at 11 pm in Adelaide. This walk-through will take you through inspecting the current state of the partition, identifying kernels you can safely delete, and using tools that elementary OS already ships with rather than chasing exotic scripts from a stranger's blog.

Most of the commands used here come straight from the apt and dpkg families, the same tools the elementary AppCenter relies on under the hood. As you work through the steps, keep a recovery USB handy and remember that the community at elementarynow.com has covered similar scenarios in its tutorials and forum threads, which can be a helpful reference if your setup diverges from the examples below.

Why the Boot Partition Fills Up

The boot partition on an elementary OS install holds the Linux kernel images, the matching initramfs files, and a copy of the GRUB bootloader. Each time a new kernel lands through the regular update channel, the old one is normally kept alongside it for at least one extra cycle, giving you a fallback if a regression appears. After two or three LTS point releases, a typical install in Brisbane or Perth can carry four or five kernels without the user ever noticing.

Beyond kernels, the partition stores System.map files, configuration fragments used by GRUB, and occasionally files left behind by abandoned third-party drivers. Nvidia owners in Melbourne who installed the proprietary driver from the GUI Additional Drivers panel sometimes find an extra set of kernel modules sitting in /boot after switching back to the open-source nouveau driver, which adds to the clutter without warning.

Ubuntu-based distributions used to handle most of this automatically with a script called apt-autoremove, but that only removes kernels marked as no longer required. It does not purge the matching initramfs files or the GRUB menu entries. Over the years, those leftovers accumulate until the partition, often only 512 MB on a refurbished laptop, is more than ninety percent full.

When the partition runs out of space, the package manager simply stops accepting new installs. Elementary OS users on the Pantheon desktop see a notification bubble from the AppCenter saying that an update failed, often with a cryptic dpkg error about there being no room left on the device. Recognising that message as a boot partition issue rather than a software bug is the first step toward a clean fix.

Check Your Current Usage First

Before deleting anything, take a snapshot of the current state. Open the Terminal application from the Applications menu or by pressing Super and typing Terminal, then run df -h to see how full each mounted filesystem is. Pay particular attention to the line that mounts /boot or /boot/efi, and note whether it sits on its own partition or is part of the root volume.

A second useful command is du -sh /boot, which totals the contents of that directory regardless of mount points. If the number reported is approaching the size of the partition shown by df, you have already confirmed the diagnosis. Australian users on slower NBN connections in regional Tasmania sometimes skip these checks and head straight for a kernel removal tutorial, only to discover later that the real culprit was an overflowing Timeshift snapshot directory on the root partition instead.

For a more detailed breakdown, ls -lh /boot lists every file with its size in human-readable form. Look for vmlinuz files, initrd.img or initramfs files, and any files ending in .old that hint at previous kernels. Make a quick note of the current kernel you are running with uname -r, because that version must stay untouched throughout the cleanup.

Identifying Old Kernels and Stale Entries

Once you know how much space you are dealing with, list every kernel package installed on the system. The command dpkg --list | grep linux-image shows installed kernel images, while dpkg --list | grep linux-headers shows the matching header packages used for compiling out-of-tree modules such as DKMS-driven wireless drivers.

You will normally see a chain of versions such as 6.5.0-44-generic and 6.5.0-45-generic. The current one is highlighted by uname -r and should remain installed. Each older version typically has two related packages: the image itself and the headers, plus matching modules-extra and tools packages. Removing all four together is essential, because a lone header package without its image leaves orphaned dependencies that confuse future updates.

GRUB keeps its menu configuration in /boot/grub/grub.cfg, which is regenerated from scripts in /etc/grub.d and the file /etc/default/grub. Listing /boot shows which kernels it is currently aware of. Entries that no longer have a matching vmlinuz file are stale and will vanish automatically once you run update-grub after the cleanup.

Using apt and dpkg to Remove Old Kernels

The cleanest way to remove older kernels is through apt itself. A command such as sudo apt purge linux-image-6.5.0-44-generic linux-headers-6.5.0-44-generic targets every related package in one line. Substitute the version numbers with whatever your earlier listing revealed.

If you are confident about removing every kernel except the current one and the previous one as a safety net, a loop can handle the job. Piping dpkg --list through awk and xargs produces a one-liner that purges every package except the running kernel, but it is worth running the awk filter first without piping to xargs so you can see what it intends to remove. Beginners often copy such commands from a forum and end up deleting the kernel they are booted into, which forces a reboot into a broken state.

After the purge, run sudo apt autoremove to catch dependencies left behind by the deleted kernels. Then verify the result with df -h again. On a typical refurbished ThinkPad X230 sold through Sydney's second-hand markets, freeing up around 350 MB is common after removing two older kernels, which is usually enough to breathe comfortably until the next round of updates.

Cleaning Up /boot and Updating GRUB

With the old kernels gone, the initramfs files for those versions are also removed automatically. Leftover files occasionally linger, particularly if a previous cleanup was interrupted by a power outage, which happens more often than locals in the Hunter Valley expect during summer storms. Manually inspect /boot for any files dated months ago that do not match an installed kernel and delete them with sudo rm, taking care to spell each filename exactly.

The next step is to regenerate the GRUB menu so it no longer references the deleted kernels. The command sudo update-grub reads /etc/default/grub and every script in /etc/grub.d, then rewrites /boot/grub/grub.cfg. Elementary OS, being a faithful Ubuntu derivative, ships this command in the grub-common package and it should already be present. Rebooting afterwards confirms that the menu lists only the surviving kernels.

UEFI machines often have an additional file called /boot/efi/EFI/elementary/grubx64.efi which is the binary GRUB itself. It does not shrink during cleanup, so do not expect any noticeable difference in its size. The release-upgrade prompt during an elementary OS version bump will, however, check that the EFI partition still has room for the new shim binary before continuing.

Recovering from Mistakes and Restoring Snapshots

Even with careful preparation, a misplaced purge can leave a system that fails to boot. The standard recovery path is to boot from an elementary OS installation USB, mount the affected root partition, chroot into it, and reinstall the missing kernel package. Readers who picked up a copy of the ISO from a Linux meetup in Brisbane or downloaded it ahead of a planned trip to a regional town will already have the right tool at hand.

Timeshift is the snapshot tool most elementary OS users rely on, and a healthy schedule of daily and weekly snapshots turns a catastrophic cleanup into a ten-minute restore. Confirm that Timeshift is configured to keep snapshots on a separate drive or partition before you start fiddling with /boot, because a snapshot stored on the same partition you are shrinking will be useless when the partition fills up.

Another safety net is the rescue mode baked into GRUB itself. Holding Shift during boot on a BIOS machine or pressing Esc on a UEFI machine reveals the GRUB menu, and from there you can select an older kernel that you deliberately kept. Selecting that entry lets you boot a working environment, undo the bad purge, and reinstall the missing kernel through apt or by downloading the .deb file directly.

Automating the Cleanup Going Forward

Once the partition is back at a healthy size, a small amount of configuration keeps it that way unattended. Install the unattended-upgrades package if it is not already present; elementary OS enables it by default, but you can verify with apt list --installed. Edit /etc/apt/apt.conf.d/50unattended-upgrades to ensure the Unattended-Upgrade::Remove-Unused-Kernel-Packages setting is true, which tells the system to delete kernel packages no longer required after each upgrade cycle.

A complementary trick is to cap the number of retained kernels through the Unattended-Upgrade::Keep-Deprecated-Kernels setting. Setting it to two keeps the current kernel plus one previous version, which on a 512 MB EFI partition leaves roughly 200 MB of permanent headroom. Combined with weekly Timeshift snapshots stored on an external drive purchased from your local Officeworks, this creates a routine that needs no manual intervention.

A final habit worth forming is a monthly glance at the output of df -h, the same command used during diagnosis. Running it after a typical patch cycle in Australia, when most local businesses finish their monthly maintenance window, quickly confirms that /boot remains comfortably under seventy percent full. Catching a creeping fill before it blocks an update saves an evening of troubleshooting.

The thing worth carrying away is that the boot partition is a small, fixed container that fills predictably as elementary OS rolls forward through its LTS cadence. Treat the running kernel as off-limits, keep one previous version as insurance, and let the package manager do the heavy lifting through unattended upgrades rather than chasing one-off fixes. With a recovery USB, a working Timeshift schedule, and the basic apt and dpkg commands outlined here, the cleanup is a calm and repeatable task rather than an emergency.