Something is eating my /boot partition making installations of programs fail

[Red Squirrel]

Something keeps eating all the space in that partition and any time I use apt-get it seems it tries to write to that and fails. I can't even update my system anymore.

I tried apt-get autoremove and apt-get autoclean but it was failing, so I moved a couple files to /tmp just so that it works, but all it did is it caused even more space to be used!

Anything else I can try? I know there is something about purging old kernels, which I thought this command was going to do, but can't find much info on how to do it.

These are the biggest files:

40561 -rw-r--r-- 1 root root 41371472 Apr 19  2019 initrd.img-4.4.0-103-generic
40559 -rw-r--r-- 1 root root 41369245 Apr 19  2019 initrd.img-4.4.0-112-generic
40803 -rw-r--r-- 1 root root 41617772 Apr 19  2019 initrd.img-4.4.0-134-generic
40803 -rw-r--r-- 1 root root 41618079 Oct 22 22:28 initrd.img-4.4.0-135-generic
40833 -rw-r--r-- 1 root root 41648182 Nov  1 02:38 initrd.img-4.4.0-166-generic
39933 -rw-r--r-- 1 root root 40729863 Apr 19  2019 initrd.img-4.4.0-21-generic
40418 -rw-r--r-- 1 root root 41224852 Apr 19  2019 initrd.img-4.4.0-45-generic
40457 -rw-r--r-- 1 root root 41265117 Apr 19  2019 initrd.img-4.4.0-47-generic
40194 -rw------- 1 root root 40996864 Nov  1 02:39 initrd.img-4.4.0-67-generic

Are any of those safe to delete? Those are the actual kernels right? So as long as I don't delete the latest one I should be good?

 

[lxskllr]

I usually keep two kernels/associated files. Current, and previous. Those should be safe to remove, but they aren't the actual kernels. The kernel will be named something like linux-image-4.4.0-103-amd64, and it'll be ~125mb. There's also an associated headers file that's tens of megabytes.

 

[Red Squirrel]

Odd I don't see files called linux-image anywhere. I'm on Mint do they maybe do things differently? This is what my /boot looks like:

otal 433957
 1226 -rw-r--r-- 1 root root  1249214 Dec  4  2017 abi-4.4.0-103-generic
 1227 -rw-r--r-- 1 root root  1249685 Jan 19  2018 abi-4.4.0-112-generic
 1229 -rw-r--r-- 1 root root  1251923 Aug 15  2018 abi-4.4.0-134-generic
 1229 -rw-r--r-- 1 root root  1251923 Aug 27  2018 abi-4.4.0-135-generic
 1217 -rw-r--r-- 1 root root  1239577 Apr 18  2016 abi-4.4.0-21-generic
 1220 -rw-r--r-- 1 root root  1242701 Oct 19  2016 abi-4.4.0-45-generic
 1220 -rw-r--r-- 1 root root  1243086 Oct 26  2016 abi-4.4.0-47-generic
 1223 -rw-r--r-- 1 root root  1245659 Mar  8  2017 abi-4.4.0-67-generic
  188 -rw-r--r-- 1 root root   190517 Dec  4  2017 config-4.4.0-103-generic
  188 -rw-r--r-- 1 root root   190533 Jan 19  2018 config-4.4.0-112-generic
  188 -rw-r--r-- 1 root root   190624 Aug 15  2018 config-4.4.0-134-generic
  188 -rw-r--r-- 1 root root   190624 Aug 27  2018 config-4.4.0-135-generic
  188 -rw-r--r-- 1 root root   190973 Oct  1 06:50 config-4.4.0-166-generic
  186 -rw-r--r-- 1 root root   189412 Apr 18  2016 config-4.4.0-21-generic
  187 -rw-r--r-- 1 root root   189760 Oct 19  2016 config-4.4.0-45-generic
  187 -rw-r--r-- 1 root root   189809 Oct 26  2016 config-4.4.0-47-generic
  187 -rw-r--r-- 1 root root   190236 Mar  8  2017 config-4.4.0-67-generic
    1 drwxr-xr-x 5 root root     1024 Nov  2 02:39 grub
40560 -rw-r--r-- 1 root root 41370044 Nov  2 02:40 initrd.img-4.4.0-103-generic
40558 -rw-r--r-- 1 root root 41367912 Nov  2 02:40 initrd.img-4.4.0-112-generic
40803 -rw-r--r-- 1 root root 41617520 Nov  2 02:40 initrd.img-4.4.0-134-generic
40802 -rw-r--r-- 1 root root 41617034 Nov  2 02:40 initrd.img-4.4.0-135-generic
40834 -rw-r--r-- 1 root root 41649427 Nov  2 02:40 initrd.img-4.4.0-166-generic
40419 -rw-r--r-- 1 root root 41226177 Nov  2 02:41 initrd.img-4.4.0-45-generic
40460 -rw-r--r-- 1 root root 41267293 Nov  2 02:41 initrd.img-4.4.0-47-generic
40459 -rw-r--r-- 1 root root 41267042 Nov  2 02:40 initrd.img-4.4.0-67-generic
   12 drwx------ 2 root root    12288 Sep 11  2016 lost+found
  180 -rw-r--r-- 1 root root   182704 Jan 28  2016 memtest86+.bin
  182 -rw-r--r-- 1 root root   184380 Jan 28  2016 memtest86+.elf
  182 -rw-r--r-- 1 root root   184840 Jan 28  2016 memtest86+_multiboot.bin
    1 -rw-r--r-- 1 root root      255 Aug 15  2018 retpoline-4.4.0-134-generic
    1 -rw-r--r-- 1 root root      255 Aug 27  2018 retpoline-4.4.0-135-generic
 3813 -rw------- 1 root root  3887726 Dec  4  2017 System.map-4.4.0-103-generic
 3817 -rw------- 1 root root  3891234 Jan 19  2018 System.map-4.4.0-112-generic
 3828 -rw------- 1 root root  3902867 Aug 15  2018 System.map-4.4.0-134-generic
 3828 -rw------- 1 root root  3902867 Aug 27  2018 System.map-4.4.0-135-generic
 3837 -rw------- 1 root root  3912700 Oct  1 06:50 System.map-4.4.0-166-generic
 3780 -rw------- 1 root root  3853719 Apr 18  2016 System.map-4.4.0-21-generic
 3796 -rw------- 1 root root  3869895 Oct 19  2016 System.map-4.4.0-45-generic
 3799 -rw------- 1 root root  3873447 Oct 26  2016 System.map-4.4.0-47-generic
 3808 -rw------- 1 root root  3882318 Mar  8  2017 System.map-4.4.0-67-generic
 6967 -rw------- 1 root root  7104176 Dec  4  2017 vmlinuz-4.4.0-103-generic
 6973 -rw------- 1 root root  7110608 Jan 19  2018 vmlinuz-4.4.0-112-generic
 7023 -rw------- 1 root root  7161824 Aug 15  2018 vmlinuz-4.4.0-134-generic
 7024 -rw------- 1 root root  7161952 Aug 27  2018 vmlinuz-4.4.0-135-generic
 7067 -rw------- 1 root root  7206328 Oct  3 06:28 vmlinuz-4.4.0-166-generic
 6878 -rw-r--r-- 1 root root  7013968 Jun 28  2016 vmlinuz-4.4.0-21-generic
 6917 -rw------- 1 root root  7054208 Oct 19  2016 vmlinuz-4.4.0-45-generic
 6924 -rw------- 1 root root  7060896 Oct 26  2016 vmlinuz-4.4.0-47-generic
 6946 -rw------- 1 root root  7083312 Mar  8  2017 vmlinuz-4.4.0-67-generic

I deleted a couple of those larger initrd files but seems no matter what they just get regenerated any time I use apt-get and it ends up filling the drive again.

Might have to break out gparted and just resize the partitions around.

 

[Red Squirrel]

Ok think I may have figured it out, hopefully I'm doing this right...

falcon boot # dpkg --list | grep "linux-image"
ii  linux-image-4.4.0-103-generic                 4.4.0-103.126                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-112-generic                 4.4.0-112.135                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-134-generic                 4.4.0-134.160                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-135-generic                 4.4.0-135.161                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-166-generic                 4.4.0-166.195                                amd64        Signed kernel image generic
ii  linux-image-4.4.0-21-generic                  4.4.0-21.37                                  amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-45-generic                  4.4.0-45.66                                  amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-47-generic                  4.4.0-47.68                                  amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-67-generic                  4.4.0-67.88                                  amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-79-generic                  4.4.0-79.100                                 amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-103-generic           4.4.0-103.126                                amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-112-generic           4.4.0-112.135                                amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-134-generic           4.4.0-134.160                                amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-135-generic           4.4.0-135.161                                amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-21-generic            4.4.0-21.37                                  amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-45-generic            4.4.0-45.66                                  amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-47-generic            4.4.0-47.68                                  amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-67-generic            4.4.0-67.88                                  amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-extra-4.4.0-79-generic            4.4.0-79.100                                 amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP

Then I run apt-get purge on the older versions. Hopefully I'm not breaking anything.... I see lot of output having to do with kernel modules including virtualbox stuff so hopefully I'm not hosing stuff. Worse case scenario I am due for an OS upgrade anyway... Mint is at 19 now and I'm on 18.

 

[mv2devnull]

I tried apt-get autoremove and apt-get autoclean but it was failing

Are any of those safe to delete?

There is no such thing as "it was failing" in computer world.
There are error messages and detailed description of what did happen.

Deleting files directly (that have been installed by package manager) is not safe. You use package manager to maintain known, consistent state.

If /boot is a separate filesystem, you moved files away from it to make space, yet package manager still "fails", then the issue is not with the /boot. (Presumably, we don't know what your "fail" really was.)

I don't know debian/ubuntu/mate, but apparently there are multiple possibilities:

How to Remove Old Kernels in Debian and Ubuntu - pontikis.net

After installing a new Linux kernel, old kernels are not automatically deleted. They remain in your disk. You have to delete them manually. Why?

www.pontikis.net

 

[Red Squirrel]

Maybe I was not clear but by failing, it's because it was running out of disk space. So yes, it was failing. Computers can fail. There is usually a reason for it, but they can. Apt-get seems to write a lot to /boot throughout the process of updating and because there is no space left it fails.

I think I managed to solve it with the purge command by specifying the kernel files. I have not rebooted yet though and kinda worried to... but assuming I didn't blow away anything important I think this worked. I was just not sure how to get a list of the kernels but found it.

 

[H T C]

Maybe I was not clear but by failing, it's because it was running out of disk space. So yes, it was failing. Computers can fail. There is usually a reason for it, but they can. Apt-get seems to write a lot to /boot throughout the process of updating and because there is no space left it fails.

I think I managed to solve it with the purge command by specifying the kernel files. I have not rebooted yet though and kinda worried to... but assuming I didn't blow away anything important I think this worked. I was just not sure how to get a list of the kernels but found it.

I've had this happen to me when attempting to install another kernel: i fixed it by deleting the oldest kernel i had installed which provided enough space for the newer one. Since then, i never have more than 3 different kernel versions installed @ the same time, to ensure i always have enough space for newer kernel's installations.

I use uKuu to install / remove kernels: too much of a linux noob to do it any other way.

This never happened to me while using apt-get, though.

 

[Red Squirrel]

Yeah for some reason old kernels arn't getting deleted automatically so I didn't know how to delete them. I just hope I don't have some stuff relying on them. When I used the purge command I was seeing lot of stuff to do with kernel modules like virtualbox etc so wonder if some software is actually using older kernels for some reason. I started a VM and it worked though... just have not rebooted yet. I will do that at a time where I'm ready to deal with the possibility of it not coming back.

 

[lxskllr]

Those are just modules that get built against that specific kernel. If you don't use that specific kernel, virtualbox won't know any different. If the kernel isn't active, it's just sitting there taking up space.

 

[Red Squirrel]

That's kinda what I was wondering too. So seems these are safe to delete then and I can just keep a couple. I guess I can probably check the grub file and see which ones are in the boot menu and delete everything but those ones.

 

[Fallen Kell]

Yeah for some reason old kernels arn't getting deleted automatically so I didn't know how to delete them. I just hope I don't have some stuff relying on them. When I used the purge command I was seeing lot of stuff to do with kernel modules like virtualbox etc so wonder if some software is actually using older kernels for some reason. I started a VM and it worked though... just have not rebooted yet. I will do that at a time where I'm ready to deal with the possibility of it not coming back.

Old kernels, initrd, config, and abi are never automatically deleted. The reason is that your system may have a failure when attempting to use a new kernel (i.e. it was compiled wrong, has incomplete hardware drivers for your system, is missing compile options needed for your system, ran out of space, is corrupt, etc., etc., etc.). If any of the thousands of reasons why it could fail occur, you simply boot the system using the previous working kernel and proceed to having an operating computer, vs having to reinstall the OS and rebuild from backups.

There are other reasons for having multiple kernels as well, such as needing to periodically support a real-time kernel, or testing various compile time kernel options, etc.

Once you know that the new kernel is working and is stable (stable being a key thing), you can then periodically go back and remove the older kernel if you feel you no longer have a need for them.

 

[Red Squirrel]

Yeah kinda figured it's a good idea to keep a few though I just would have figured they would get deleted over time. Ex: keep no more than like 5 or whatever.

But anyway is the way I did it the proper way?

dpkg --list | grep "linux-image"

Then pick ones out from the list (ideally oldest) and do:

apt-get purge [name of kernel]

The apt-get autoremove and similar commands were not working for me as the commands were failing with disk space errors due to not having enough disk space in /boot. I guess it needs to write stuff to there temporarily during that process.[/code]

 

[lxskllr]

On Debian and Xubuntu older kernels are marked as auto removable. It keeps one back, and marks the rest. Not sure why yours isn't behaving that way. What you're doing should be fine. Since it's a desktop system, you might want to try synaptic as a gui package manager. You can then tick a bunch of boxes, and remove packages without a lot of typing.