Comment 19 for bug 1988299

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.