Home / ubuntu / Questions / 1207958
In Process
alex345
Asked: 2020-02-05 00:28:44 +0800 CST

Error 24 : Write error : cannot write compressed block

  • 772

I recently updated from Ubuntu 18.04 to 19.10. It looks to me as if the update installed an older kernel (5.3.0-29) than the one I had running under 18.04 (5.0.0-36). Since then I've had errors on all apt updates which show initramfs failing: 

Setting up initramfs-tools (0.133ubuntu10) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133ubuntu10) ...
update-initramfs: Generating /boot/initrd.img-5.3.0-29-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.3.0-29-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

My output of uname -r is 

5.3.0-29-generic

and 

alex@acer:~$ dpkg --list | grep linux-image
ii  linux-image-5.0.0-36-generic                  5.0.0-36.39                                         amd64        Signed kernel image generic
ii  linux-image-5.3.0-29-generic                  5.3.0-29.31                                         amd64        Signed kernel image generic
ii  linux-image-generic                           5.3.0.29.33                                         amd64        Generic Linux kernel image

Any ideas on how to solve? I'm not even sure what the issue is, but have gone through plenty of other solutions.

kernel initramfs

4 Answers

  1. OK I think I may have just solved this. I didn't notice at first that I was actually using the newer kernel rather than the old one. In my first couple of boots after update, the older kernel (5.0.-) was in use, rather than the newer one (5.3.-). So with sudo apt purge linux-image-5.0.0-36-generic it looked like that freed some some space on /boot and voila computer says 

    Setting up initramfs-tools (0.133ubuntu10) ...
update-initramfs: deferring update (trigger activated)
(Reading database ... 328490 files and directories currently installed.)
Purging configuration files for linux-image-5.0.0-36-generic (5.0.0-36.39) ...
rmdir: failed to remove '/lib/modules/5.0.0-36-generic': Directory not empty
Processing triggers for initramfs-tools (0.133ubuntu10) ...
update-initramfs: Generating /boot/initrd.img-5.3.0-29-generic
    • 29

  2. I encountered this problem as my /boot partitions was full.

    I carefully deleted a few large initrd.img files that I was sure I did not need anymore.

    Make sure you write down your last working kernel. Do not delete all others right away, because you don't want them all to be regenerated.

    I ran sudo apt autoremove --purge and did another sudo apt dist-upgrade -V to get the missind initrd image files generated.

    once you have rebooted on your last kernel. and things are fine. Then I invite you to clean up all the old stuff.

    Current packages you should NOT touch dpkg -l | egrep "linux-(signed|modules|image|headers)" | grep $(uname -r)

    Old packages you can purge dpkg -l | egrep "linux-(signed|modules|image|headers)" | grep -v $(uname -r | cut -d - -f 1)

    I purged them all with

    dpkg -l | egrep "linux-(signed|modules|image|headers)" | grep -v $(uname -r | cut -d - -f 1) | awk {'print $2'} | xargs sudo apt purge -y

    I still had 4.10 and 4.13 packages on a Ubuntu 20.10 running 5.8.0-45

    • 27

  3. As a workaround you can try this for more temporary scratch space:

    cd /
sudo rsync -av /boot /boot2
sudo mount --bind /boot2 /boot
sudo update-initramfs -u
sudo umount /boot
sudo rsync -av /boot2/ /boot/ --exclude "*.new" --exclude "*.dpkg-bak" --delete --inplace
    • 1

  4. 5.3 is a newer/later kernel than 5.0

    Only the first two numbers are from upstream and are significant in comparing kernels.

    The other trailing minor numbers are internal Ubuntu codes that apply only to that kernel, ie. don't compare minor numbers of a 5.3 series kernel to a 5.0 series kernel. The minor numbers (ie. those after 5.0/5.3, should only be used to compare within the same kernel)

    https://wiki.ubuntu.com/Kernel/MainlineBuilds

    note: by two numbers I mean number.number; so 4.19 example from the pasted link qualifies as first two numbers as I'm using the term.

    • 0