Re: Updating kernels impossible when /boot is getting full
On Sun 01 Aug 2021 at 13:21:11 (+0300), Ilkka Huotari wrote:
> Thanks. I should have said, that also apt-get autoremove fails:
>
> $ sudo apt-get autoremove
> Reading package lists... Done
> Building dependency tree... Done
> 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.139ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools (0.139ubuntu3) ...
> update-initramfs: Generating /boot/initrd.img-5.11.0-25-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.11.0-25-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)
>
> Maybe this is a bug in the dpkg?
>
> This sounds like some disk (it's a few years old SSD) error, but I don't
> know:
> "Error 24 : Write error : cannot write compressed block"
If Ubuntu is parallelling Debian, I'd be very wary.
Would it be true to say that:
. You've got two kernels installed, 22 and 25, and 25 is running.
. You're trying to upgrade to a new version of 25, so the new
version is overwriting the old one.
This is exactly why you need 22 as a backup, in case the new version
of 25 doesn't work, for whatever reason. So I would not remove it
unless you take action to be able to boot up with it from another
location.
Whatever you do now involves risk, so it's just a matter of choosing
the risk you can most easily cope with.
BTW, and AIUI, apt/dpkg doesn't like installing/removing packages
when the system is "broken", so it will try to finish configuring
that failed one first. This may explain your "bug".
I have no idea whether any of these alternatives would work:
. Copy initrd.img-5.11.0-25-generic somewhere safe and external,
then delete it. Now reinstall 25, and the system should have
room to rebuild the initrd.img.
If it¹ doesn't work, restore the copy, and you've lost nothing.
. Reboot the system with 22. Now you can be more brutal with removing
25's files in /boot, in order to either reinstall it, or remove and
then install it.
. Copy the four *-5.11.0-22-generic files somewhere safe and external,
then delete them. Now reinstall 25, and the system should have
room to rebuild the initrd.img.
If it¹ doesn't work, restore the copies, and you've lost nothing.
In addition to any of these, I would consider copying all the four
files for each installed kernel onto a safe, external device, and
adding a custom entry to /boot/grub/grub.cfg by means of
/etc/grub.d/40_custom,
copying the first menuentry, but mangling it so that it can find
the external device, and load the kernel-… and initrd.img-… from
there.
(NB I've no idea how ubuntu differs from debian.)
¹ "it" means the process just described.
I don't mean "reboot the system and see if it works".
Check everything is correctly back in place before rebooting.
Cheers,
David.
Reply to: