Update Manager woes...

[Landon]

Hi, I have 19.3 Tricia, this has been going on for some time but overall doesn't really seem to be causing any problems but I would like it to go away.

Whenever the Update Manager has an update regarding the kernel I also end up with an error like this one...

Code: Select all

gzip: stdout: No space left on device
cpio: write error: Broken pipe
E: mkinitramfs failure cpio 2 gzip 1
update-initramfs: failed for /boot/initrd.img-5.4.0-80-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-5.4.0-80-generic (--configure):
 installed linux-image-5.4.0-80-generic package post-installation script subprocess returned error exit status 1
Processing triggers for initramfs-tools (0.130ubuntu3.13) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-77-generic
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
Warning: No support for locale: en_US.utf8

gzip: stdout: No space left on device
cpio: write error: Broken pipe
E: mkinitramfs failure cpio 2 gzip 1
update-initramfs: failed for /boot/initrd.img-5.4.0-77-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:
 linux-image-5.4.0-80-generic
 initramfs-tools

From there if I click OK it says that my system is up to date and I get the green check mark icon and it wants me to do a Reboot.

But meanwhile... If I go into the BOOT folder down at the bottom of the frame it says that I have 37 megs of free space but the latest kernel file that came through is 70 megs and I'm expecting that the next kernel download is going to be greater than 70 megs and there won't be any space for it, so I have to go into Kernels in the Update Manager and delete the currently replaced old one to make space for what is going to be the new one...

Being an old school computer user (the first computer that I ever used was a "Tandy Model 3") I feel that this is something that should just be taking care of itself and not something that the User should really ever have to deal with, so my question is how to do I automate this to take care of itself or if there a way that I can give the BOOT folder like four times the current space that it has and not have to deal with this for a while?

I don't mind giving it more space as I have a 1 TB drive that is currently 75% empty with no current plans to suddenly fill it up.

[JoeFootball]

But meanwhile... If I go into the BOOT folder down at the bottom of the frame it says that I have 37 megs of free space but the latest kernel file that came through is 70 megs and I'm expecting that the next kernel download is going to be greater than 70 megs and there won't be any space for it, so I have to go into Kernels in the Update Manager and delete the currently replaced old one to make space for what is going to be the new one...

Clean up some space by trying: sudo apt autoremove

Then, in Update Manager, go to Edit > Preferences > Automation, and in the Automatic Maintenance section, select: "Remove obsolete kernels and dependencies"

(the first computer that I ever used was a "Tandy Model 3")

Mine was the TRS-80 Model I.

[Landon]

Thank you, I did all of that I'll reply to this again when the next kernel update comes through.

[Moonstone Man]

Mine was the TRS-80 Model I.

I owned serial number 0007, and it launched a 42+ year career for me.

[Pierre]

Mine was the TRS-80 Model I.

I owned serial number 0007, and it launched a 42+ year career for me.

that would be an amazing start to your career.

[JoeFootball]

I owned ...

The Model I which I had used was the singular computer my school had in 1978(?). I'm fairly sure it had BASIC in ROM, but everything else was loaded/saved via cassette. If I remember correctly, of course. I better write this down before it slips away for good.

[karlchen]

Hello, Landon.

The 2 blocks of error messages, which you shared with us, each start with the message gzip: stdout: No space left on device
This strongly suggests that the disk partition is full, where your directory /boot is located.
In addition to executing sudo apt autoremove, it may be necessary to uninstall obsolete kernels explicitly, which occupy the space on /boot.

Please, execute the commandline LC_ALL=C df -h | egrep "^/dev/|Filesystem" and share its output with us. This should help determine which filesystem precisely has run out of space.
Please, execute the commandline ls -Al /boot, too, and shar its output with us. This should help determine whether too many obsolete kernels have caused the error gzip: stdout: No space left on device.

Regards,
Karl

[Landon]

This is what it gave me...

Code: Select all

landon@landon-desktop ~ $ LC_ALL=C df -h | egrep "^/dev/|Filesystem"
Filesystem                           Size   Used    Avail   Use% Mounted on
/dev/mapper/mint--vg-root  915G  170G   699G  20% /
/dev/sdb1                            917G  651G   221G  75% /mnt/d5d78168-3080-4c0b-9578-8ed6dfe5d599
/dev/sda1                            236M  173M   51M   78% /boot

And...

Code: Select all

landon@landon-desktop ~ $  ls -Al /boot
total 167576
-rw-r--r-- 1 root root   237757 Jun 17 16:29 config-5.4.0-77-generic
-rw-r--r-- 1 root root   237757 Jul 13 10:52 config-5.4.0-80-generic
drwxr-xr-x 6 root root     1024 Jul 24 13:32 grub
-rw-r--r-- 1 root root 70890756 Jul 24 13:31 initrd.img-5.4.0-77-generic
-rw-r--r-- 1 root root 70898111 Jul 24 13:32 initrd.img-5.4.0-80-generic
drwx------ 2 root root    12288 Nov 18  2014 lost+found
-rw-r--r-- 1 root root   182704 Jan 28  2016 memtest86+.bin
-rw-r--r-- 1 root root   184380 Jan 28  2016 memtest86+.elf
-rw-r--r-- 1 root root   184840 Jan 28  2016 memtest86+_multiboot.bin
-rw------- 1 root root  4587290 Jun 17 16:29 System.map-5.4.0-77-generic
-rw------- 1 root root  4587397 Jul 13 10:52 System.map-5.4.0-80-generic
-rw------- 1 root root  9449728 Jun 17 16:30 vmlinuz-5.4.0-77-generic
-rw------- 1 root root  9453824 Jul 13 11:28 vmlinuz-5.4.0-80-generic

And if I go into Update Manager "5.4.0-80" is "Active" and "5.4.0-77" is "installed" so it looks like I can remove '77 and clear up some room.

[Moonstone Man]

And if I go into Update Manager "5.4.0-80" is "Active" and "5.4.0-77" is "installed" so it looks like I can remove '77 and clear up some room.

Yes. For future reference, your boot partition is far too small. It's best to avoid a separate boot partition. A separate boot partition was only needed in the dark ages when drives were expensive and slow.

[karlchen]

Hi, Kadaitcha Man.

Code: Select all

landon@landon-desktop ~ $ LC_ALL=C df -h | egrep "^/dev/|Filesystem"
Filesystem                Size Used Avail Use% Mounted on
/dev/mapper/mint--vg-root 915G 170G 699G 20%   /
/dev/sdb1                 917G 651G 221G 75%   /mnt/d5d78168-3080-4c0b-9578-8ed6dfe5d599
/dev/sda1                 236M 173M  51M 78%   /boot

LVM has been used. In this situation you have to have a dedicated /boot filesystem. Only thing is, you should not be a mizer and grant /boot a minimum of 2 GB of disk space. 236M may have been sufficient 20 years ago. But kernels and boot image files have gained in weight and size a lot since then.

Cheers,
Karlk

[Moonstone Man]

LVM has been used. In this situation you have to have a dedicated /boot filesystem.

Drats. Wrong again. maybe it's time to retire...

[Landon]

Thanks for the replies, yes I am aware that the BOOT folder is too small which is why I asked the original question about making it bigger, so...

How do I make it bigger?

Can I make it bigger?

Is this something that has to be done during installation?

Back in the day when I first installed Mint on this system I just let it do everything automatically and this is what I ended up with, if this isn't really fixable in 19.3 would wiping my drive and installing 20' fix the problem?

[karlchen]

Hello, Landon.

In order to be able to extend the disk partition which holds /boot, you need unallocated disk space.
In case your whole disk device /dev/sda has been distributed completely to
+ /dev/sda1 - /boot
+ /dev/sda2 - holding /dev/mapper/mint--vg-root i.e. your root file system /
then extending may be tricky, because you would have to use LVM in order to reduce the size of /dev/mapper/mint--vg-root first, then reduce the size of /dev/sda2. Only then you would be able to resize /dev/sda1.

No need to tell explicitly that filesystems and disk partitions can only be resized when they are not in use. I.e. the work will have to done from a live-system.

Whether wiping the disk and installing LM 20.x will resolve your problem? - Depends on whether you trust the installer once again to size /boot properly.
Else you will have to use the "Do something else" option and size the disk paritions yourself.

Karl