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.

alex345
  • 703
  • 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 04 '20 at 08:41

4 Answers4

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

Mathieu J.
  • 1,172
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
alex345
  • 703
  • 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 '20 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
Wladimir Palant
  • 183
Eric Woodruff
  • 429
  • I remounted my original boot and restarted the OS following this and it saved me from a severe situation. Ty – Tmanok Apr 15 '22 at 03: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.

guiverc
  • 30,396
  • 1
    this isn't much of an answer; but I don't know what else to say, or what link to paste. – guiverc Feb 04 '20 at 08: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 04 '20 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 04 '20 at 13:20
  • This is very incorrect. https://www.kernel.org/ – Mathieu J. Jun 27 '21 at 03: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 '21 at 03:49