How to Increase the Size of the Boot Partition in Rocky Linux 8 or CentOS
You’ve got a full‑blown kernel dump on your /boot partition after a few updates, and now you can’t install new kernels without deleting old ones. This article walks through the real steps to grow that partition – no fluff, just what you need to do.
Check How /boot Is Set Up
Start by seeing if /boot lives on its own physical partition or inside LVM:
$ df -hT | grep /boot
If the filesystem type is lvm2, you’re in LVM land; if it’s a block device like /dev/sda1, you’ll need a different approach.
The commands that follow depend on whether you can just extend an LV or have to rebuild a raw partition from scratch.
Growing /boot Inside LVM
If /boot is an LVM logical volume, the process is straightforward:
# 1. Find the LV name and size $ lvdisplay | grep -E 'LV Name|LV Size' # 2. Extend it – give yourself a buffer (e.g., +512M) $ sudo lvextend -L+512M /dev/mapper/rhel-root # replace with your LV path # 3. Resize the filesystem $ sudo resize2fs /dev/mapper/rhel-root
Why each step matters:
- lvextend bumps the logical volume size on the LVM pool.
- resize2fs expands the actual ext4 filesystem to fill that space.
Afterwards, update GRUB so it knows the new layout:
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg # BIOS systems # or $ sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # UEFI
Reboot, and you’re good to go.
Expanding a Separate /boot Partition (No LVM)
When /boot lives on its own block device, you’ll have to use a live CD or rescue mode because the partition is mounted. Here’s the low‑down:
1. Back it up – never underestimate a backup.
$ sudo mkdir -p /mnt/boot_backup $ sudo rsync -aAXv /boot/ /mnt/boot_backup/
2. Boot from a Rocky/CentOS live USB and open GParted or gdisk.
3. Delete the old /boot partition (/dev/sda1, for example).
It’s okay to delete; we’ll recreate it.
4. Create a new, larger partition in its place.
- Start at the same sector (or next if you prefer) to avoid messing with boot sectors.
- Set the type to Linux (fd in GPT or 83 in MBR).
- Make it 1 GB (or whatever size you need).
5. Format the new partition:
$ sudo mkfs.ext4 /dev/sda1
6. Mount it and copy data back:
$ sudo mount /dev/sda1 /mnt/boot_new $ sudo rsync -aAXv /mnt/boot_backup/ /mnt/boot_new/
7. Update /etc/fstab to use the new UUID (get it with blkid /dev/sda1).
8. Reinstall GRUB so it boots from the correct device:
$ sudo mount /mnt/boot_new /boot $ sudo grub2-install /dev/sda # target disk, not partition $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
9. Reboot, unmount the live system, and verify everything works.
Why this is heavy: The boot loader relies on absolute sector positions. Deleting and recreating a partition can shift sectors, so you must let GRUB rebuild its config to keep the chainloader happy.
A Real‑World Scenario
I’ve seen users on small VPSs hit this wall after installing 10+ kernel versions over a year of updates. The /boot partition stayed at 512 MB, and the system refused to install new kernels with “no space left” errors. After following the LVM path above (most cloud images use LVM for /boot), they freed up gigabytes instantly without touching any other data.
Quick Tips & Warnings
- Don’t forget backups – you can lose both kernel and bootloader if something goes wrong.
- If you’re on UEFI, make sure the EFI partition is still pointing to your new GRUB config location.
- After resizing, run sudo dmesg | grep -i grub during boot to catch any loader hiccups early.
That’s it. Resize that /boot, keep your kernels happy, and avoid the “out of space” panic again.
