On 2021-08-01 at 06:21, Ilkka Huotari wrote: > Hi Paul, > > 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? It could be argued, but I'm not sure what dpkg could plausibly do about it, so I'm not convinced just up-front. > 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" That could (I don't know, myself) just be the way cpio reports failing to write in the case when the disk would have been full, after which the automatic system cleans up the incomplete file it was creating, so the disk is no longer full. > Contents of the /boot: > > total 343M > -rw-r--r-- 1 root root 248K kesä 17 01:38 config-5.11.0-22-generic > -rw-r--r-- 1 root root 248K heinä 9 20:42 config-5.11.0-25-generic > drwx------ 6 root root 4,0K tammi 1 1970 efi > drwxr-xr-x 4 root root 4,0K heinä 23 13:13 grub > -rw-r--r-- 1 root root 153M heinä 10 14:22 initrd.img-5.11.0-22-generic > -rw-r--r-- 1 root root 151M heinä 23 13:13 initrd.img-5.11.0-25-generic > lrwxrwxrwx 1 root root 28 heinä 23 06:04 initrd.img.old -> > initrd.img-5.11.0-22-generic > drwx------ 2 root root 16K heinä 6 08:52 lost+found > -rw-r--r-- 1 root root 179K elo 18 2020 memtest86+.bin > -rw-r--r-- 1 root root 181K elo 18 2020 memtest86+.elf > -rw-r--r-- 1 root root 181K elo 18 2020 memtest86+_multiboot.bin > -rw------- 1 root root 5,7M kesä 17 01:38 System.map-5.11.0-22-generic > -rw------- 1 root root 5,7M heinä 9 20:42 System.map-5.11.0-25-generic > lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz -> > vmlinuz-5.11.0-25-generic > -rw------- 1 root root 15M kesä 17 01:55 vmlinuz-5.11.0-22-generic > -rw------- 1 root root 15M heinä 9 21:04 vmlinuz-5.11.0-25-generic > lrwxrwxrwx 1 root root 25 heinä 23 06:04 vmlinuz.old -> > vmlinuz-5.11.0-22-generic Which kernel are you currently running? If you're running 5.11.0-22-generic, then things are trickier. I don't have any immediate suggestions for that circumstance. If you're running 5.11.0-25-generic, then I think I see a possible way out of this for a one-off instance, although it involves doing some things by hand. At that point, it should be safe to remove the -22-generic kernel, it's just that the automatic tools for doing so want to do something else first which is failing. What I might try doing in that circumstance is to identify the largest file in that directory which would be removed as part of the removal of the -22-generic kernel (in this case, initrd.img-5.11.0-22-generic), move it to another filesystem, create a symlink to it from its original location, try the removal again, and - assuming it succeeds - (eventually) delete the moved file from its new location. Of course, depending on exactly how much checking of what the files it's processing at removal time dpkg actually does, that might just make the removal fail another way. In which case things would have to get trickier again. And do note that I am *not* certain that this would actually work correctly, and there's a minor chance that it could break things. Please don't proceed on anything involving manually manipulating the contents of /boot without having a recovery-boot medium (e.g., live-boot USB drive) available as a fallback! (None of this resolves the underlying problem: the filesystem in question is too small for today's boot-configuration requirements. Given the constraint on enlarging it which you noted in your original inquiry, however, I don't have any suggestions at all on that front.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature