I’m trying to do a release upgrade via sudo do-release-upgrade and am running into issues because of insufficient space on /boot. The upgrade tool is warning that I need at least 827MB but by /boot is only 768MB.
I would like to resize my /boot partition but because I don’t have any space directly after the partition I’m unsure how to proceed. Google-ing around seems to advise against trying to move my LVM partition due to slowness + possible data corruption so I’m wondering what the possible options are for upgrading? Or would doing a fresh install from a Live CD over the ext partition be advisable here?
Relevant System Information:
(base) matt@xps:~$ sudo parted --list
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vgubuntu-root: 999GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 999GB 999GB ext4
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vgubuntu-swap_1: 1023MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 1023MB 1023MB linux-swap(v1)
Error: /dev/mapper/nvme0n1p3_crypt: unrecognised disk label
Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/nvme0n1p3_crypt: 1023GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Model: Micron 2300 NVMe 1024GB (nvme)
Disk /dev/nvme0n1: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 EFI System Partition boot, esp
2 538MB 1305MB 768MB ext4
3 1305MB 1024GB 1023GB
This tidies things up and removes extraneous kernel images freeing up some space. Still may not be enough but worth a try before trying do release again.
Your release upgrade needs to go to 22.04 LTS first, then again to 24.04 LTS, if 24 is where you want to end up.
While 500MB or more is often suggested for the ESP, Ubuntu rarely uses very much at all. It often easily shares with a Windows ESP of 100MB. If you find you are not using much of the ESP, you could shrink it & expand /boot.
But not sure why /boot needs so much space. If from previous upgrades in place, you may have very old kernels that the dpkg housecleaning will not remove. Typically two kernels are kept, do you have more? But if running enablement stack, you probably have orginal & updated kernels. Agian you may be able to manually house clean older kernels.
(base) matt@xps:~$ lsblk -e 7 -o MODEL,NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,fsused,uuid
MODEL NAME FSTYPE LABEL MOUNTPOINT SIZE FSUSED UUID
Micron 2300 NV nvme0n1 953.9G
├─nvme0n1p1 vfat /boot/efi 512M 55.8M 1E2C-94F1
├─nvme0n1p2 ext4 /boot 732M 315.7M 1bbb5f56-b101-4ffa-904b-15bfe23a0685
└─nvme0n1p3 crypto_LUK 952.7G 2c8d389f-453c-4ab2-bb6a-b2b274becd14
└─nvme0n1p3_crypt LVM2_membe 952.7G 4c7HIi-dPDj-fSby-TbeL-R9yq-DVlA-tH8CUB
├─vgubuntu-root ext4 / 930.4G 316G 83b4c9e9-065a-4a79-ae3c-ac88afd2962c
└─vgubuntu-swap_1 swap [SWAP] 976M 760ed152-d594-4940-bb75-0a4e4a3c301d
(base) matt@xps:~$ uname --kernel-release
5.15.0-139-generic
(base) matt@xps:~$
(base) matt@xps:~$ sudo grep initrd /boot/grub/grub.cfg | uniq
if [ "${initrdfail}" = 2 ]; then
set initrdfail=
elif [ "${initrdfail}" = 1 ]; then
set initrdfail=2
function initrdfail {
if [ -z "${initrdfail}" ]; then
set initrdfail=1
save_env initrdfail
initrd /initrd.img-5.15.0-139-generic
initrd /initrd.img-5.15.0-139-generic
initrd /initrd.img-5.15.0-131-generic
It seems like I do have some extra kernels but the thing that I am unclear on is the upgrade tool seems to be asking for more space than the entire /boot drive so not sure how cleaning up will help resolve this?
(base) matt@xps:~$ dpkg --list | grep linux-image
rc linux-image-5.14.0-1024-oem 5.14.0-1024.26 amd64 Signed kernel image oem
rc linux-image-5.14.0-1027-oem 5.14.0-1027.30 amd64 Signed kernel image oem
rc linux-image-5.14.0-1029-oem 5.14.0-1029.32 amd64 Signed kernel image oem
rc linux-image-5.14.0-1033-oem 5.14.0-1033.36 amd64 Signed kernel image oem
rc linux-image-5.14.0-1036-oem 5.14.0-1036.40 amd64 Signed kernel image oem
rc linux-image-5.14.0-1042-oem 5.14.0-1042.47 amd64 Signed kernel image oem
rc linux-image-5.14.0-1045-oem 5.14.0-1045.51 amd64 Signed kernel image oem
rc linux-image-5.14.0-1051-oem 5.14.0-1051.58 amd64 Signed kernel image oem
rc linux-image-5.14.0-1054-oem 5.14.0-1054.61 amd64 Signed kernel image oem
rc linux-image-5.14.0-1055-oem 5.14.0-1055.62 amd64 Signed kernel image oem
rc linux-image-5.14.0-1056-oem 5.14.0-1056.63 amd64 Signed kernel image oem
rc linux-image-5.14.0-1057-oem 5.14.0-1057.64 amd64 Signed kernel image oem
rc linux-image-5.14.0-1058-oem 5.14.0-1058.66 amd64 Signed kernel image oem
rc linux-image-5.14.0-1059-oem 5.14.0-1059.67 amd64 Signed kernel image oem
rc linux-image-5.15.0-127-generic 5.15.0-127.137~20.04.1 amd64 Signed kernel image generic
rc linux-image-5.15.0-130-generic 5.15.0-130.140~20.04.1 amd64 Signed kernel image generic
ii linux-image-5.15.0-131-generic 5.15.0-131.141~20.04.1 amd64 Signed kernel image generic
rc linux-image-5.15.0-136-generic 5.15.0-136.147~20.04.1 amd64 Signed kernel image generic
rc linux-image-5.15.0-138-generic 5.15.0-138.148~20.04.1 amd64 Signed kernel image generic
ii linux-image-5.15.0-139-generic 5.15.0-139.149~20.04.1 amd64 Signed kernel image generic
rc linux-image-5.4.0-42-generic 5.4.0-42.46 amd64 Signed kernel image generic
ii linux-image-generic-hwe-20.04 5.15.0.139.149~20.04.1 amd64 Generic Linux kernel image
You are only using 10% of your ESP, so can shrink it & expand /boot.
man dpkg-query
rc= removed (some configuration files remain)
ii = installed
If you look in /boot after running the dpkg commands to houseclean the files dpkg knows about, do you have more kernels & files like kernel files by version - initrd, vmlinuz, abi, system.map that are not the current & previous versions. You should only have two versions. ll /boot
Or do you have other folders added (somehow) beyond just grub. It will show efi, but that is just mounted in /boot and not in /boot partition.
Caution, I don’t use a /boot or logical vols, so I may be missing something below.
Have tested backups, things can go badly wrong when editing partitions.
Steps to make a bigger /boot partition, populate it with old /boot files, edit the …/EFI/ubuntu/grub.cfg with the new UUID, ensure it boots, and then run the upgrade.
The gparted new partition command should reserve the appropriate space at the end of the disk for a backup gpt table (33 sectors at least). filesystem ext4, and add the boot,esp flags. Remove the flags on the old /boot.
mkfs -text4 on the new partition, and copy over the old /boot files to the new partition.
Edit the stub file …EFI/ubuntu/grub.cfg to change the UUID from the old /boot to the new /boot. Use sudo blkid to get the UUIDs (not the partition UUIDs).
Edit the /etc/fstab mount of the efI partition to the new one by changing the UUID to the new one.
Check everything by trying to boot. Check your free space on /boot, and run your upgrade.
It seems like after running dpkg -P I know only have two versions but the core issue that /boot still is less that 827 MB still remains. I.e. when I try sudo do-release-upgrade I still see
Not enough free disk space
The upgrade has aborted. The upgrade needs a total of 827 M free
space on disk '/boot'. Please free at least an additional 475 M of
A related question, is there any advantage to using sudo do-release-upgrade vs just doing a fresh install from a live CD over the same ext4 partition? I.e. in terms of maintaining my desktop environment + files I think this will be equivalent since these all exist on a different partition?
I only do new installs but I only have desktop installs. And I keep two / (root) partitions, one old or future and one main working install on NVMe drive. And two drives in main desktop with another test install or two in HDD. All my data is in a separate data partition separately backed up.
Server type installs often have added settings or programs in / , I only edit a few files in /, primarily grub & copy those into /home for my backup. So if you know what you change in / , good list of installed apps, and have good backups, a new install does houseclean a lot of cruft that builds even with good housekeeping.
The only way to expand a boot partition, is booting from a USB and resize the adjacent partition. Because Linux has a dynamic file tree, the os has to be not active on the disk. That is why your AI answer it that way.
Keep in mind AI does not really knows the answers and is only accurate in its ability to look at other people answers. If the source is the internet, the answer could be wrong because it can’t always determine the results. That is why debug programmers are not in danger of AI taking their job.
If you do a fresh install from a live CD, it will wipe those partitions you select, and will not preserve your files. In your case, /home is inside the same partition as root (/).
As already mentioned, make backups now if still needed before doing anything else. You are dealing with an encrypted logical volume, any number of things can go wrong if you don’t know what your doing w/ LUKS & LVM.
After a backup, I think it would be good to reread through some of these posts and report back what you have tried. There are some solid suggestions already given here.
