Long ago, during the time of creation, I confidently waved my hand and allocated a 1GB ESP partition and a 1GB boot partition, thinking to myself with a confident smile that this would surely be more than enough for the foreseeable future. However, this foreseeable future quickly vanished along with my smile. What was bound to happen eventually came, but I didn’t expect it to arrive so soon. What could possibly require such a large boot partition? And how should we resolve this? Here, I would like to introduce the boot partition issue I encountered, as well as temporary coping methods and final solutions, mentioning the problems encountered along the way for reference.

Issue

If you go on Google to see everyone’s answers about how large the boot partition should be, you’ll find a variety of responses, with the absolute majority resting around 500MB. The reason for the variety is quite normal, as everyone’s environments and distributions differ. For instance, if using systemd-boot, the ESP partition needs to be larger, while the boot partition can sometimes be unnecessary. With grub, the situation varies; if the device has a graphics card, it usually means that driver modules need to be placed in the boot as well. In this case, having an ample 1GB on devices without a dedicated graphics card starts to feel insufficient. As for the 500MB figure, it could only be considered, in historical terms, a somewhat decent choice, but today it is undoubtedly outdated.

I encountered a similar problem; at first, it was not an issue until I faced a situation during daily package updates when a new kernel version needed to be installed. At that moment, apt began complaining that the boot partition was insufficient. This was due to the fact that the graphics card I later installed meant that the boot partition couldn’t accommodate the NVIDIA modules anymore. Since that’s the case, the problem became evident: the direct reason was that the new device required more items to be placed in the boot, thus the previously designated size became inadequate, and the fundamental reason was that the boot partition was originally not sized generously enough. Historically, 500MB or even 1GB is no longer sufficient for modern boot usage.

Temporary Solution

Fortunately, Debian’s update policy is very conservative, keeping at least two versions of the kernel in the boot for emergencies. Thus, temporarily addressing this issue becomes quite simple: just clean out the old versions.

dpkg --list | grep linux-image

After finding the oldest version, you can run apt purge. If it hasn’t been cleaned up, you can check inside /etc/boot:

If all goes well, we should be able to see some old versions of initramfs and initrd, which can be cleaned up.

If cleaning them up is still not enough, we can continue to clean more. The reason for not cleaning all the old ones at once is a conservative consideration; it allows us to boot with an old version if there is an issue with the current kernel.

Final Plan

Of course, manually cleaning up old versions every time brings too much mental burden. To completely solve this problem, we must approach it fundamentally, which means expanding the boot partition.

As we all know, a partition can only be expanded backward, not forward. Therefore, what we need to do is quite simple: shrink the / partition that comes after the boot partition, and then use the space freed up as the new boot partition. Actually, it was planned to operate conservatively first in a Live CD environment, but after confirming the plan with @NickCao, I plan to start directly under the current operating system, and the specific steps of the plan are as follows:

1. Use GParted to shrink the / partition from the back;
2. Also in GParted, format the unallocated space into a new boot partition;
3. Migrate the data from the original boot partition using rsync -a;
4. Edit fstab to update the boot partition information;
5. Restart and check if the new boot partition is successfully mounted by fstab;
6. Apply changes using grub install and update grub;
7. Clean up the old boot partition;
8. Restart.

The most complicated parts can basically be completed using GParted, and the final result is as follows:

It’s important to note that you must run grub install first, and then clear the original boot partition; otherwise, the system will continue to attempt to use the old boot partition upon reboot, because according to GRUB - ArchWiki, this part seems to be hardcoded: