Comment 3 for bug 1646222

Related bug, which led to the current behavior: bug #1173468

At the time, the decision was made to double the calculated value for required free space. This is better than being undersized, but it's over large; this sets the min free space value to 2 * N_kernels * (sizeof(kernel_package_bits) + sizeof(initramfs)).

The high water mark for disk usage is actually:

 1) all the newly installed kernels are unpacked to disk
 2) any kernels being upgraded are unpacked onto disk, but have not yet replaced the old files - i.e., unpacked as .dpkg-new (technically, I think this can only be true of one upgraded kernel package at a time, but it's highly unusual to ever have *a* kernel package being upgraded and exponentially unusual to have more than one)
 3) an initrd on disk for each of the new and upgraded kernels
 4) one additional initrd on disk (initrd.img-$version.new) being prepared as a replacement.

It's possible that 2) and 4) would never be unpacked at the same time, in which case the high water mark would actually be 1 + 3 + MAX(2,4). But this is only slightly smaller than 1+2+3+4 so probably doesn't matter in practice.

I think therefore that we should calculate N_kernels * sizeof(kernel_package_bits) + (N_kernels + 1) * sizeof(initramfs) and use that as the freespace value. This will require a moderate refactor between update-manager and ubuntu-release-upgrader.

The current fudge factor for kernel growth over time - currently, 1MiB additional per kernel - should be retained.