Upgrade to 20.04 LTS errors - mkinitramfs failure cpio

[X]

At the end of the upgrade process to 20.04 I got a message about mkinitramfs. It said I should consider submitting a bug.

Now after a re-boot I get:

$ sudo apt install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up initramfs-tools (0.136ubuntu6) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.136ubuntu6) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-28-generic
Error 24 : Write error : cannot write compressed block
E: mkinitramfs failure cpio 141 lz4 -9 -l 24
update-initramfs: failed for /boot/initrd.img-5.4.0-28-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned erro
r exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ lsb_release -rd
Description: Ubuntu 20.04 LTS
Release: 20.04

$ apt-cache policy initramfs-tools
initramfs-tools:
  Installed: 0.136ubuntu6
  Candidate: 0.136ubuntu6
  Version table:
 *** 0.136ubuntu6 500
        500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu focal/main i386 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: initramfs-tools 0.136ubuntu6
ProcVersionSignature: Ubuntu 5.4.0-28.32-generic 5.4.30
Uname: Linux 5.4.0-28-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun May 3 02:11:32 2020
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-11-16 (1994 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
PackageArchitecture: all
SourcePackage: initramfs-tools
UpgradeStatus: Upgraded to focal on 2020-05-03 (0 days ago)

[X (peptic-ductile-bobsled)]

This fixed my problem:

sudo apt purge linux-image-4.15.0-99-generic

from:
https://askubuntu.com/questions/1207958/error-24-write-error-cannot-write-compressed-block

Usually if it's a freespace thing, I'll get a popup about /boot not having enough space. That happened during upgrade process, but I wasn't able to purge old space, and it hasn't happened since finishing the upgrade.

There is usually enough space for the current and previous kernel in /boot as well.

[Sum Yung Gai (sumyunggai)]

That error message does not mean an unbootable system, fortunately, in most cases.

I just upgraded from Bionic Beaver (18.04 LTS) to Focal Fossa (20.04 LTS) today, and yes, it is a free space thing, specifically in /boot. The above link worked for me. The problem seems to be with systems that were originally installed with a smaller /boot partition, per some advice we were given for security reasons some years ago. Many of us still make a smaller /boot partition for this reason, especially on servers. It also is a good way to LUKS-encrypt / for security and still be able to boot the box (I think /boot still needs to be unencrypted). In my case, /boot was 256 MB in size. In the past, I would keep the current running kernel and the previous kernel and apt-purge (or through Synaptic, get rid of) the older ones. Before any subsequent kernel upgrade, I'd delete the oldest one, thus leaving one kernel (the running one), and thus there'd be no problem with space on /boot.

The problem is that kernel binaries, and especially their initrds, have been getting bigger as the years have gone on, and now with the new 5.4.0 kernel, we've kinda hit critical mass. Therefore, whatever script or other program does space-checking to see if there's enough apparently has a "cushion" built into its check so that even if there's enough, it throws an error if space is kinda close. This can happen when you have two kernels on the system when /boot is 256MB or so. That condition happens at the end of the upgrade during initrd generation, because I now had both 4.15.0-99 and the new 5.4.0-29 kernel; I was now down to 84% on /boot, and the error popped up.

Fortunately, since in the case of a 256MB partition and this upgrade, there *is* actually sufficient space, we get a bootable system. First, check to see that there's a 5.4.0-29 initrd first! If there is--and there should be--then go right ahead and reboot; you'll be fine. That's what I did.

After rebooting and thus verifying that 5.4.0-29 and the rest of the system is A-OK (it is), then go ahead and apt-purge the 4.15.0-99 kernel. I'd also recommend getting rid of linux-headers, linux-modules, and linux-modules-extra (all for 4.15.0-99, of course). This way you not only free up space on /, you also make sure to get rid of the System-map file in /boot for 4.15.0-99.

Hopefully this helps clear things up some more.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.