The volume "boot" has only 0 bytes disk space remaining.[Solved]

[terry_g]

I just did an update that included a kernel and got the following message:
The volume "boot" has only 0 bytes disk space remaining.
I suspect that there are a large number of kernels that could be cleaned up.
Any help would be greatly appreciated.

Terry

[WharfRat]

Before removing anything make sure the update completed successfully and reboot to the latest kernel.

Check with ls -lh /boot/|grep vmlin and uname -r

Make sure uname -r returns the latest kernel version of the list.

[AZgl1800]

at a minimum, keep the last oldest version, so you can backup if the newest kernel has a hiccup.

[Pierre]

this has become an re-occurring issue on the new LM 19 series,
& there is a few ways of dealing with it, & this is just one way:

- reboot your machine & from the Main Boot Menu:
select the Option "Advanced Options for Linux Mint 19 XXXX"
( where XXXX is your Desktop version & on this machine,, that is the Mate version.
then select the Option "Linux Mint 19 XXXX, with Linux 4.15.0-36- generic ( recovery mode )
( select the Kernel version that is the highest version - 4.15.0-36 in this case )

- wait for the Recovery Menu to load:
select the "Clean" option - which is the second option in the Menu
- select Yes at the prompt screen & then type Y for the next CLI prompt,
in order to Remove some of the Older Kernels in your system.

- Press Enter at the Final Prompt, to return to the Main Recovery Screen,
and then Resume to start a Normal Boot Sequence.

NB: in some cases, the Normal Resume may fail, as the Video may be incorrect,
and in this case,, force a Full Shutdown of your machine,
by holding down the Power Button, until you can see the Shutdown Sequence on the screen,
& then release that Power Button - - then restart your machine, as normal.

NB2: if you hold that Power Button down for too long, then you will force the machine to Hard Shutdown .. ..

NB3: this method does use the sudo apt-get autoremove command, to achieve this.

[terry_g]

Thanks Pierre
I ran the commands as you said and still get the same warning after boot.
I have seven kernels installed and am running the latest.

Terry

[Pierre]

did that give any indication, as to if anything did get removed ?.

from Gparted, can you post a screen_shot of that HDD?
- this can be installed from Package Manager AKA synaptic - if it's not already installed.

[WharfRat]

This might be easier to use.

Copy the following into a text editor page

Code: Select all

#!/bin/bash
#     
# clean_boot
#
CURKERNEL=$(uname -r|sed 's/-*[a-z]//g'|sed 's/-386//g')
LINUXPKG="linux-(image|headers|modules|ubuntu-modules|restricted-modules)"
METALINUXPKG="linux-(image|headers|restricted-modules)-(generic|i386|server|common|rt|xen)"
OLDKERNELS=$(dpkg -l|awk '{print $2}'|grep -E $LINUXPKG |grep -vE $METALINUXPKG|grep -v $CURKERNEL)
YELLOW="\033[1;33m"
RED="\033[0;31m"
ENDCOLOR="\033[0m"
     
if [ $USER != root ]; then
	echo -e $RED"Error: must be root"
	echo -e $YELLOW"Exiting..."$ENDCOLOR
	exit 0
fi
     
echo -e $YELLOW"Removing old kernels..."$ENDCOLOR
sudo apt-get purge $OLDKERNELS
   
echo -e $YELLOW"Script Finished!"$ENDCOLOR

exit $?

Save it as clean_boot then in the terminal chmod u+x clean_boot then sudo ./clean_boot

You will have the chance to say no if things don't look right.

[gm10]

NB3: this method does use the sudo apt-get autoremove command, to achieve this.

You cannot autoremove kernels on Ubuntu, they are specifically excluded from that. I don't have the script the clean option runs at hand though, maybe it overrides that.

OP, if you still need help after the suggestions above (I doubt the clean boot option will work but maybe I'm wrong, I'm sure the script one up will fail though), please first post output of this terminal command

Code: Select all

inxi -Fxz

and I'll talk you through it.

this has become an re-occurring issue on the new LM 19 series,

sadly... I've also had a bunch of full / root partitions here recently. They should add a better warning for this and/or automated remedies.

[terry_g]

Here it is:

Code: Select all

tglover@tglover-desktop ~ $ inxi -Fxz
System:    Host: tglover-desktop Kernel: 4.15.0-36-generic x86_64 (64 bit gcc: 5.4.0)
           Desktop: MATE 1.18.0 (Gtk 3.18.9-1ubuntu3.3)
           Distro: Linux Mint 18.2 Sonya
Machine:   Mobo: ASRock model: J4205-ITX
           Bios: American Megatrends v: P1.40 date: 07/14/2017
CPU:       Quad core Intel Pentium J4205 (-MCP-) cache: 1024 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 11980
           clock speeds: max: 2600 MHz 1: 1339 MHz 2: 1369 MHz 3: 1342 MHz
           4: 1299 MHz
Graphics:  Card: Intel Device 5a84 bus-ID: 00:02.0
           Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel HD Graphics 505 (Broxton)
           GLX Version: 3.0 Mesa 18.0.5 Direct Rendering: Yes
Audio:     Card Intel Device 5a98 driver: snd_hda_intel bus-ID: 00:0e.0
           Sound: Advanced Linux Sound Architecture v: k4.15.0-36-generic
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169 v: 2.3LK-NAPI port: e000 bus-ID: 01:00.0
           IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 1320.3GB (11.2% used)
           ID-1: /dev/sda model: ST3320620AS size: 320.1GB
           ID-2: /dev/sdb model: ST1000DM010 size: 1000.2GB
Partition: ID-1: / size: 286G used: 54G (20%) fs: ext4 dev: /dev/dm-0
           ID-2: /boot size: 472M used: 451M (100%) fs: ext2 dev: /dev/sda1
           ID-3: swap-1 size: 8.23GB used: 0.00GB (0%) fs: swap dev: /dev/dm-1
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 31.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 176 Uptime: 8 min Memory: 712.8/7635.4MB
           Init: systemd runlevel: 5 Gcc sys: 5.4.0
           Client: Shell (bash 4.3.481) inxi: 2.2.35 
tglover@tglover-desktop ~ $

[gm10]

Interesting, isn't that the latest kernel? Surprised you managed to boot to that despite the error message.

Here, let's have some fun, run this in a terminal (copy & paste as a whole):

Code: Select all

dpkg-query -W -f '${Version}\n' 'linux-image-[^g]*'|sort -u|sed -e '/^$/d' -e 's/\~[^~]*$//' -e 's/\.[^.]*$//' -e "/$(uname -r|sed s/-generic//)/d" -e 's/.*/sudo rm -rfv \/boot\/*-&-*/'|source /dev/stdin

Followed by this:

Code: Select all

sudo apt-get install -f -y
sudo apt-get autoremove --purge -y
sudo update-grub

(I don't need to see the output, the first one will probably generate a bunch of errors)

and finally this:

Code: Select all

dpkg-query -W -f '${Version}\n' 'linux-image-[^g]*'|sort -u|sed -e '/^$/d' -e 's/\~[^~]*$//' -e 's/\.[^.]*$//' -e "/$(uname -r|sed 's/-generic//')/d" -e 's/.*/linux-*-&*/'|tr '\n' ' '|xargs -r sudo apt-get remove --purge -y

It's possible this one generates errors, in that case I'd like to see them. They'll probably be repetitive for every kernel this runs through, one example of that is enough.

[kukamuumuka]

LVM is a headache if (and when) /boot partition is too small for normal use.

[terry_g]

Thanks! gm10
The last command did not generate any errors. I will reboot now and see what happens.

Terry

[terry_g]

Thanks again gm10 I rebooted and using gparted my /boot is at 19%.

Terry

[gm10]

Ah, a smooth run, those are my preferred, and no doubt yours, too. You're welcome.

[Pierre]

NB3: this method does use the sudo apt-get autoremove command, to achieve this.

You cannot autoremove kernels on Ubuntu, they are specifically excluded from that. I don't have the script the clean option runs at hand though, maybe it overrides that.

so far - - my method has worked for my machine,
but there is another machine, that also has the Disk Full Error,
and when I'm able to get over to that house, then I'll be able to check again, what does work.

[gm10]

so far - - my method has worked for my machine,
but there is another machine, that also has the Disk Full Error,
and when I'm able to get over to that house, then I'll be able to check again, what does work.

Interesting. The usual problem with disk full on separate boot partitions is that the removal script needs to create temporary files on the partition and fails because of that. That's why I didn't expect the clean to work. Might have to give this a try in a VM one of these days.

[Tootler]

Interesting, isn't that the latest kernel? Surprised you managed to boot to that despite the error message.

Here, let's have some fun, run this in a terminal (copy & paste as a whole):

Code: Select all

dpkg-query -W -f '${Version}\n' 'linux-image-[^g]*'|sort -u|sed -e '/^$/d' -e 's/\~[^~]*$//' -e 's/\.[^.]*$//' -e "/$(uname -r|sed s/-generic//)/d" -e 's/.*/sudo rm -rfv \/boot\/*-&-*/'|source /dev/stdin

Followed by this:

Code: Select all

sudo apt-get install -f -y
sudo apt-get autoremove --purge -y
sudo update-grub

(I don't need to see the output, the first one will probably generate a bunch of errors)

and finally this:

Code: Select all

dpkg-query -W -f '${Version}\n' 'linux-image-[^g]*'|sort -u|sed -e '/^$/d' -e 's/\~[^~]*$//' -e 's/\.[^.]*$//' -e "/$(uname -r|sed 's/-generic//')/d" -e 's/.*/linux-*-&*/'|tr '\n' ' '|xargs -r sudo apt-get remove --purge -y

It's possible this one generates errors, in that case I'd like to see them. They'll probably be repetitive for every kernel this runs through, one example of that is enough.

Many thanks for this. I had the same problem and this worked a treat. It both updated the failed kernel update and I then tested by trying the pending updates which had failed and they went in fine. I'll have to hang on to these scripts for future use.

Once again thanks.

[gm10]

Many thanks for this. I had the same problem and this worked a treat. It both updated the failed kernel update and I then tested by trying the pending updates which had failed and they went in fine. I'll have to hang on to these scripts for future use.

Once again thanks.

Thanks for the feedback, and you are very welcome.

Preferably you remove old kernels before it gets to this situation though (you can use Update Manager or the last script from my post for that).

[Tootler]

Thanks for the hint.

I wasn't aware of the issue until this happened. It seems to be a weakness in the update system that they don't deal with the old kernel in some way when you install an update to avoid the boot partition filling up with redundant files. If they did, this problem wouldn't arise at all.

The first thing I tried was autoremove and autoclean. When that didn't work, I looked in the forum. It took a bit of searching to find this thread as I was looking in the boot section of the forum not the newbies but a targeted search found it in the end and I didn't need to post a new query.

I've saved your scripts for future use, thanks.

Cheers

Geoff

[gm10]

I wasn't aware of the issue until this happened. It seems to be a weakness in the update system that they don't remove . the old kernel or, at least move it somewhere else in case in case problems arise when you install an update. If they did, this problem wouldn't arise at all.

I agree. If you want, here's a version of my script that will set it up to run automatically every week, removing all but your current kernel, that way you won't have to worry about it again:

Code: Select all

F=/etc/cron.weekly/purge_old_kernels;echo '#!/bin/bash'|sudo tee $F;echo "dpkg-query -W -f '\${Version}\n' 'linux-image-[^g]*'|sort -u|sed -e '/^$/d' -e 's/\~[^~]*$//' -e 's/\.[^.]*$//' -e \"/\$(uname -r|sed 's/-generic//')/d\" -e 's/.*/linux-*-&*/'|tr '\n' ' '|xargs -r apt-get remove --purge -y"|sudo tee -a $F;sudo chmod +x $F

(yes, I enjoy creating super long and complicated looking command lines )