37

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.

1
  • 5.3 is a newer kernel than 5.0 (only the first two numbers are from upstream; the other minor numbers are internal Ubuntu digits that apply only to that kernel, ie. don't compare minor numbers of 5.3 series to a 5.0 series)
    – guiverc
    Feb 4, 2020 at 8:41

4 Answers 4

44

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

2
  • 1
    What a great answer. A real corker! Thanks, @Mathieu J. Jan 31, 2022 at 23:14
  • Still works fine in 23.04, I cleaned up my 5.x kernels. only keeping active one. good thing to do before upgrading to 23.10
    – Mathieu J.
    Oct 25, 2023 at 23:28
30

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
1
  • 2
    Yep. Thank you for pointing out that this is a free space issue, the error occuring whenever the initramfs needs regenerating and there isn't free space in the /boot file system. I'm starting to feel the need to expand the '/boot' FS to 300M or more (100M per kernel on average recently), as at new kernel release install time, ubuntu has 3 kernels installed (current running, old stable, and new incoming).
    – Samveen
    Sep 28, 2020 at 13:30
7

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
  • I remounted my original boot and restarted the OS following this and it saved me from a severe situation. Ty
    – Tmanok
    Apr 15, 2022 at 3:13
0

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.

5
  • 1
    this isn't much of an answer; but I don't know what else to say, or what link to paste.
    – guiverc
    Feb 4, 2020 at 8:42
  • Thanks for looking though. I think what I'm wanting is update-initramfs to work without an error. Its not affecting things so far but i'm not sure that will last for every. Also I've only assumed it relates to the kernel. Although I've been on ubuntu since version 6.06 I've certainly not become an initramfs master.
    – alex345
    Feb 4, 2020 at 13:15
  • 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
    – alex345
    Feb 4, 2020 at 13:20
  • This is very incorrect. kernel.org
    – Mathieu J.
    Jun 27, 2021 at 3:40
  • Ubuntu back-port fixes to the kernel they initially use... My point was the 18.04 used the 4.15 (GA), 4.18, 5.0, 5.3 finally 5.4 kernels from upstream; 19.10 uses the 5.3 kernel from upstream... the rest of the numbers are package versions which are influenced by a lot of things beyond just upstream linux kernel. We're talking about Ubuntu here.
    – guiverc
    Jun 27, 2021 at 3:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .