Re: Updating kernels impossible when /boot is getting full
On Sunday 01 August 2021 06:57:54 Paul Duncan wrote:
> Hmmm... Thats a little annoying.
>
> Maybe try removing the -22 image manually, like this:
>
> apt-get remove linux-image-5.11.0-22
>
> See if that works. If it doesn't, I'm not sure what else to try -
> other than a re-install - at which I would make /boot a little bigger
> :-)
>
> I'm sure others more knowledgeable than me will chime in with ideas
> too.
>
> Best Regards,
>
> Paul.
>
> On Sun, 1 Aug 2021 at 10:39, Ilkka Huotari <ilkkah@gmail.com> 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?
> >
> > 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"
> >
> > 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
> >
> > Ilkka
I can offer some long term experience, applicable in this case only if
you can re-install.
1. SSD's and u-sd's have, generally speaking, more aggressive
housekeeping than spinning rust.
2. If they have room to work, they can be far more dependable than
spinning rust, but that is a BIG IF.
3. I rum a farm here with each machine running a CNC machine, a milling
machine or lathe for carving metal. And I've been doing it since K6-II
days for cpu's.
4. Because the kernels need to be special built for real time response
while moving multi-horsepower, potentially dangerous machines, they may
be built in-house or supplied by the LinuxCNC folks, in any event they
are generally pinned such that the package manager doesn't just upgrade
them unless it has a darned good reason.
5. example, a raspberry pi 4 with 2gigs of ram, I use a 64GB u-sd to boot
from. One of my wintel boxes also has a 64GB SSD as its only storage. In
the wintel case, it can boot from an ext4 drive, and the whole system is
about 7GB, and it has 28GB to play in. Only 2 partitions as I always
make a separate /home, so / and /home are it. But its a 4G of dram, so
it has a 4G swap, that's on the 64G SSD. And its been running that way
since a 64G SSD was the biggest thing available.
The pi is built different and can boot only from a vfat file system, so
its /boot is a partition of 256 megabytes on a 64G u-sd. But dpkg
doesn't have a way to make an installable kernel deb. So I made a
tarball out of what it needed, that can be unpacked to the u-sd, mounted
as vfat in another wintel machine, that simply overwrites whatever is
there or creates it new, and the uncompressed tarball is only 30 megs.
Nothing new has been written to that partition of that u-sd in about 5
years. The remaining space, about 61Gigs, is the rest of the linux
install, currently 25% occupied. Swap has been moved to a 120G SSD, and
a backup of /boot is also on that SSD, plugged into a usb3 adapter.
And a 2nd SSD, 256G is on the other usb3 port. Why? because I am running
a buildbot to build LinuxCNC deb packages everytime there is a commit to
github, master branch, playing the canary in a coal mine for LinuxCNC on
the armhf platform. Almost grotesque, a 2 oz pi running a 1500 lb lathe.
The only write traffic to the u-sd is the output of those deb's.
So If you wind up reinstalling, make /boot a minimum of 2G so you do not
hit this situation in the lifetime of the hardware ever again, make 2x
you memory as swap, and split the rest into / and /home. It just works
for me, your storage will have room to keep itself clean and functional.
But YMMV. :) The lesson here is that the cost is coming ever down,
scrimping on storage isn't the best use of ones available sheckels.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: