Can't upgrade from 20.04 to 22.04 due to extreme space requirement for /boot

[Arthur Blair]

I'm attempting to upgrade from 20.04 to 22.04 and my installation uses full disk encryption, so I have a separate partition for /boot.

The size of the /boot partition was set by the installer for 20.04 (to 704 MiB) and I currently have 329 MiB free after removing old kernels with apt autoremove:

  $ df -h /boot
  Filesystem Size Used Avail Use% Mounted on
  /dev/sdb2 704M 324M 329M 50% /boot

When attempting to upgrade to 22.04 it fails with:

  The upgrade has aborted. The upgrade needs a total of 787 M free
  space on disk '/boot'. Please free at least an additional 442 M of
  disk space on '/boot'. You can remove old kernels using 'sudo apt
  autoremove' and you could also set COMPRESS=xz in
  /etc/initramfs-tools/initramfs.conf to reduce the size of your
  initramfs.

So it claims to need more space than the total size of the partition (so presumably no amount of compressing initramfs will be enough!), which as noted above is the default size for /boot chosen by the 20.04 installer.

Another instance of this issue has been raised here: https://askubuntu.com/q/1423156/57751
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CrashDB: ubuntu
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-04-25 (859 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
NonfreeKernelModules: nvidia_modeset nvidia
Package: ubuntu-release-upgrader (not installed)
ProcVersionSignature: Ubuntu 5.15.0-46.49~20.04.1-generic 5.15.39
Tags: focal dist-upgrade
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: Upgraded to focal on 2022-08-31 (1 days ago)
UserGroups: adm cdrom dip docker lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1988299

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

(Please also check your original bug description; you state the installer for Ubuntu 22.04 LTS set the size [of /boot], but your bug report implies you installed Ubuntu 20.04 LTS (not 22.04) & are trying to release-upgrade to 22.04)

[sjjh (simon-harhues)]

I'm in a similar situation, running 20.04 with FDE (luks) wanting to upgrade to 22.04. I'm also getting the error message that /boot has not enough free space (needing 575MB free space it says for me), aborting the upgrade. If I try to purge the older of the two currently installed kernels (linux-image-5.15.0-43-generic and linux-image-5.15.0-46-generic are installed) via synaptic to free up some space on /boot, automatically another (second) kernel image is marked to be installed ("linux-image-unsigned-5.15.0-43-generic"), actually taking up more space than freeing... :-/

$ df -h /boot/
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 703M 275M 377M 43% /boot

[sjjh (simon-harhues)]

ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CrashDB: ubuntu
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-09-12 (718 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
Package: ubuntu-release-upgrader (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 5.15.0-46.49~20.04.1-generic 5.15.39
Tags: focal dist-upgrade
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: Upgraded to focal on 2022-08-31 (0 days ago)
UserGroups: adm cdrom dialout dip lpadmin lxd plugdev sambashare sudo
VarLogDistupgradeTermlog:

_MarkForUpload: True

[sjjh (simon-harhues)]

apport information

[sjjh (simon-harhues)]

apport information

[sjjh (simon-harhues)]

apport information

[sjjh (simon-harhues)]

apport information

[sjjh (simon-harhues)]

apport information

[sjjh (simon-harhues)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

apport information

[Arthur Blair (adblair)]

@guiverc Thanks for pointing out my typo in the description (22.04 vs 20.04)—I've now corrected it.

[Raphaël Droz (raphael-droz)]

# Error message
/usr/lib/python3/dist-packages/UpdateManager/UpdatesAvailable.py

# Size calculation (checkFreeSpace())
/usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeCache.py
which uses `kernel_count * KERNEL_SIZE + (kernel_count + 1) * INITRD_SIZE`

# The code refers to
https://bugs.launchpad.net/bugs/1646222

[George (pxsort)]

I had the same issue. I managed to work around it by removing all but the running kernel version (5.15.0-46) and changing the initramfs compression setting to 'lzma'.

The issue seems to result from lines 1146, 1148 of DistUpgrade/DistUpgradeCache.py:

1146 if pkg.marked_install or pkg.marked_upgrade:
1148 kernel_count += 1

The package for my running kernel (5.15.0-46) was marked for upgrade to the jammy version of the same kernel. As far as I know, this package upgrade would not result in an *additional* kernel image and initrd image being generated, so incrementing kernel_count erroneously increases /boot space requirements.

However, there is justification on lines 1144, 1145 for the above code snippet:

1144 # upgrade because early in the release cycle the major version
1145 # may be the same or they might be -lts- kernels

so I am not sure if this behavour of the upgrade tool should be considered a bug.

It seems like the boot-performance-motivated switch to lz4 for initramfs compression may have left those with separate /boot partitions in a situation where Ubuntu's default initramfs.config is inappropriate. Ultimately, this seems to be an Ubuntu UX issue caused by inappropriate default configs generated at install-time. So it may make sense to close this issue as a wontfix, and open a new issue for the installer regarding its selection of initramfs compression settings in the case where a separate /boot partition is used.

[sjjh (simon-harhues)]

> I had the same issue. I managed to work around it by removing all
> but the running kernel version (5.15.0-46) and changing the
> initramfs compression setting to 'lzma'.

How did you remove the other kernel versions? As stated above, me trying to remove them via synaptic ended up in wanting to install another kernel package, actually increasing the used space.

What was your initial initramfs compression setting? Because for me the current setting is `lz4`, thus I'm not sure if I will gain anything by changing it to either `xz` (as suggested by the upgrade dialogue) or `lzma` (as suggested by you).

[Jim Fulton (jim-zope)]

I have the same problem.

$ df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 704M 144M 509M 22% /boot
$ ls -lh /boot
total 136M
-rw-r--r-- 1 root root 257K Aug 4 12:44 config-5.15.0-46-generic
drwx------ 3 root root 4.0K Dec 31 1969 efi
drwxr-xr-x 4 root root 4.0K Aug 31 09:02 grub
lrwxrwxrwx 1 root root 28 Aug 31 09:01 initrd.img -> initrd.img-5.15.0-46-generic
-rw-r--r-- 1 root root 118M Sep 18 11:13 initrd.img-5.15.0-46-generic
drwx------ 2 root root 16K Sep 20 2021 lost+found
-rw-r--r-- 1 root root 179K Aug 18 2020 memtest86+.bin
-rw-r--r-- 1 root root 181K Aug 18 2020 memtest86+.elf
-rw-r--r-- 1 root root 181K Aug 18 2020 memtest86+_multiboot.bin
-rw------- 1 root root 6.0M Aug 4 12:44 System.map-5.15.0-46-generic
lrwxrwxrwx 1 root root 25 Aug 31 09:01 vmlinuz -> vmlinuz-5.15.0-46-generic
-rw------- 1 root root 11M Aug 4 12:47 vmlinuz-5.15.0-46-generic

I'm guessing I can't resize /boot as most of my disk is encrypted.

[George (pxsort)]

> How did you remove the other kernel versions?
I just ran `apt remove` on the relevant kernel packages.
Maybe synaptic has some guardrails to prevent a user from configuring the system to only have a single kernel installed?

> What was your initial initramfs compression setting?
Mine was initially lz4.
This is the default for Ubuntu 20.04 installations I think.
It is actually not a good choice from a space perspective - it achieves a compression ratio even lower than gzip.
Rather, it was chosen because it is very quick, which speeds up boot times quite a bit.
Both lzma and xz should offer substantial reductions in the footprint of installed kernels in /boot, but this comes at the expense of longer boot times.
This is actually moot though, since the upgrade tool for 22.04 overwrites the compression setting (if you let it - I did to no ill effect).

[sjjh (simon-harhues)]

After removing the old kernel package via apt (it also installed another kernel package, but still freed up some space) and changing the initramfs compression level, I were also able to update to 22.04.

[Ryan Beisner (1chb1n)]

I think this is more an issue of having installer defaults that won't paint you into a corner later.

My machine has traveled the path of 20.04 -> 20.10 -> 21.04 -> 21.10 -> 22.04 now trying to go to 22.10, and I have no way to proceed other than to remove N-1 kernel. There are just 2 on the system, which is also the default. These default behaviors are at odds with one another.

I think a re-think of the default /boot partition sizing is in order.

[Randall Whitman (ubuntu-whizman)]

Cross-reference, among others:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1355026
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1360556
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1895416