increase boot partition size

Most guides on this topic tell you to run one command and call it done. That works maybe half the time. The other half, your partition layout doesn't cooperate, there's no free space adjacent to /boot, or you're dealing with LVM or encryption that changes everything. This guide covers all three scenarios, in order of complexity, so you can increase boot partition size properly without wiping anything.

What Causes the /boot Partition to Fill Up?

The root problem, almost always, is that the Linux installer defaulted to a tiny /boot partition years ago and nobody changed it. We're talking 100 to 200 MB in many cases. That was fine when kernels were smaller and you'd manually clean up old ones. Now, a single kernel plus its initramfs image can eat 60 to 80 MB on its own. Three or four kernels in and you're full. The system starts refusing updates, apt throws errors, and suddenly you can't install anything.

Here's what's actually happening on disk. Every time you install a kernel update, Linux drops a new vmlinuz file and a new initrd.img file into /boot. Old ones don't get removed automatically unless you tell the package manager to clean them up. So over time, you accumulate a graveyard of kernel versions you haven't booted in months. Some systems also generate rescue images (look for files with 'rescue' in the name in /boot) that take up another 60 to 100 MB and serve very little purpose on a well-maintained machine.

The second problem is partition layout. On many preinstalled systems, /boot sits at the very start of the disk, immediately followed by the root partition or an LVM physical volume with no free space between them. You can't just extend /boot without first shrinking whatever is next to it, and if that neighbour is an LVM volume or an encrypted partition, the steps get more involved. See our guide on managing LVM partitions on Linux if you're in that situation.

Virtual machines are a particular offender here. Whoever provisioned the VM picked a small disk size, the installer split it up with a tiny /boot, and now six months of kernel updates have filled it completely. The fix is the same, but you have the option of expanding the virtual disk first before touching partitions, which is much easier than working with a physically constrained disk.

EFI System Partitions (ESP) have their own version of this problem. On UEFI systems, the ESP is mounted at /boot/efi and holds bootloader files. If you're dual-booting or have installed multiple kernels, a 100 MB ESP fills up fast. The fix is similar to resizing a standard /boot partition but requires FAT32 formatting and the boot,esp flags, which we cover in the advanced section below.

Increase Boot Partition Size: Quick Fix by Removing Old Kernels

Before you touch any partition tables, check whether you actually need to resize at all. If your /boot partition is 300 MB or larger and it's just full of old kernels, you can recover 200 to 400 MB in about five minutes. This won't permanently increase boot partition size, but it buys you time and might be all you need if you're disciplined about kernel cleanup going forward.

This fix has a high success rate when the problem is purely too many old kernels. But if your /boot is 150 MB total and you've already cleaned it up, you need to actually increase boot partition size at the disk level. That's the next section.

Increase Boot Partition Size with a Partition Manager (Recommended)

This is the method that works for most people with a standard partition layout. You'll boot into a live environment, use a partition manager to shrink the partition next to /boot, and then extend /boot into the freed space. The whole process takes 15 to 30 minutes and doesn't require reinstalling GRUB as long as you're just enlarging the existing partition in place.

The critical rule here: you cannot resize a mounted partition. Full stop. If you try to resize /boot while your system is running from it, you will corrupt the filesystem. Boot from a live USB instead. Most distribution ISOs (Ubuntu, Fedora, Mint) include a partition manager in the live session. Alternatively, download the GParted Live ISO which is purpose-built for this job and boots fast.

Before you do anything, back up your important data. Partition resizing is generally safe with modern tools, but power cuts happen, disks have bad sectors, and mistakes happen. A backup takes 20 minutes. Recovering from a corrupted partition table without one takes days. For guidance on backing up your Linux system before major disk work, see our article on backing up Linux before partition changes.

One thing that catches people out: if the partition immediately after /boot has data right up to its start (no unallocated space between them), the partition manager will need to move that partition before it can extend /boot. GParted can do this, but moving a large partition takes a long time and the risk is slightly higher. Let it finish. Don't interrupt it. Took three reboots before one particular move operation on a 500 GB root partition finished cleanly in testing, but it did finish.

The Arch Linux wiki on parted has solid reference material on partition flags and filesystem types if you want to understand exactly what the partition manager is doing under the hood.

Advanced: Increase Boot Partition Size by Migrating to a New Partition

Sometimes you genuinely can't resize in place. The disk is completely full, the layout is too constrained, or you're working with LVM and encryption where moving partitions is risky. In that case, the cleanest approach is to create a new, larger /boot partition somewhere else on the disk (or on a second disk), copy everything across, and point the system at the new one. This is more involved, but it's reliable and doesn't require you to move existing data around.

This approach does require you to update /etc/fstab and reinstall GRUB. Don't skip those steps. If you copy /boot to a new partition and don't update the UUID in fstab, the system will try to mount the old (now empty or repurposed) partition on boot and fail. Same goes for GRUB: it needs to know where the new /boot lives.

For EFI System Partitions specifically, the process is nearly identical but you format the new partition as FAT32 and set the boot and esp flags in GParted before copying. The Ubuntu community documentation on partition resizing covers some of the EFI edge cases well, particularly around encrypted setups.

One thing worth knowing: the GNU parted manual documents every flag and partition type you might encounter. If you're unsure what type to assign a new partition, that's your reference.

Preventing /boot From Filling Up Again

Once you've fixed the immediate problem, here's how to stop it coming back. Most important first.

Size /boot generously from the start. If you're reinstalling or setting up a new system, give /boot at least 500 MB. For multi-boot setups or systems that get frequent kernel updates, 1024 MB is better. The historical 100 to 200 MB defaults are a known failure point and there's no good reason to use them in 2026.

Clean up kernels regularly. After each kernel update, remove the oldest version you're no longer using. On Debian and Ubuntu systems, sudo apt-get autoremove --purge handles this if you've already removed the specific package. Some systems can be configured to keep only the last two kernels automatically. Check your distribution's documentation for unattended-upgrades settings.

Consider skipping a separate /boot partition entirely. Unless your hardware requires it (some older BIOS setups, or full-disk encryption with LUKS where /boot must be unencrypted), you don't need a separate /boot partition. Booting directly from the root filesystem simplifies everything and removes this class of problem completely. This is worth considering if you're doing a clean install.

In virtual machines, expand the virtual disk first. If you're running Linux in a VM and /boot is filling up, expand the virtual disk from the hypervisor console before touching partitions inside the VM. It's much easier to add 10 GB to a virtual disk and then extend the partition than to work with a constrained fixed-size disk.

Back up before any disk work. This isn't optional. Partition operations are generally safe but not guaranteed. Keep a current backup before you touch partition tables, every single time.

Increase Boot Partition Size: Summary

To increase boot partition size on Linux, match the method to your situation. If /boot is 300 MB or more and just cluttered with old kernels, clean those up first. That's a five-minute fix. If the partition itself is too small, use a partition manager from a live USB to shrink the neighbouring partition and extend /boot into the freed space. That covers most standard layouts. And if your disk is too constrained to resize in place, create a new larger partition, migrate /boot to it with rsync, update /etc/fstab, and reinstall GRUB. It's more steps but it works cleanly on any layout. Going forward, size /boot at 500 to 1024 MB and clean up old kernels regularly. You won't hit this problem again.