Software Updater, Not enough free disk space

I think this is a problem of me being a newbie who doesn’t know much about Linux configuration. I’ve searched the forums and came across something similar but on Raspberry Pi’s Ubutu Mate…

The problem is, I go to install updates using Software Updater, and it complains about not enough free space in \boot which I suppose is the boot partition. And the program is right, there’s barely 100MB free there.

My question is: Why does it need to install software updates in the boot partition? Couldn’t it just use the rest of the mounted drive (>400GB)? And, if it is absolutely necessary, how can I extend the boot partition to give it more free space? Although I’m not really comfortable with touching the boot partion and I’d rather not do it.

Sorry if the question is dumb but I really need help. Thanks in advance!!

I’m not super familiar for Raspberry Pi, but here’s a general suggestion. Try running

sudo apt autoremove

This should offer to remove packages that are no longer needed. In this case you’re mostly looking for old kernels that you no longer need. (Make sure to look at what else is being removed before you accept, just to be safe.)

2 Likes

Its not a raspberry pi version, its a laptop that’s what weirded me (only seeing this happen in the raspberry pi version, according to my search). I will try your suggestion tough :slight_smile:

I saw somewhere /boot is created as its own partition when the the home directory is encrypted. Obviously, /boot can’t be encrypted but why the home directory affects this I’m not sure, unless whole-disk encryption was meant. It may explain the separate /boot partition.

The basic problem is old kernels accumulate filling /boot to capacity. This is where the excellent suggest from @elcste comes in as this removes all but the last 2 kernels. If your install is old you could have dozens of kernels in /boot.

Just wanted to add some background. I have a feeling this may drive some kernel-handling not yet invented as the topic is complex.

2 Likes

Clearly I skimmed your original post :stuck_out_tongue:

It’s not an uncommon thing to happen if the kernel gets upgraded a lot without the autoremove. (Canonical said they want to finally solve it for the 18.04 LTS release…)

Thanks elcste! Your solution did fix the issue, but I’m still confused to why it happens. I do have full disc encryption activated but I don’t know why I can’t choose a bigger \boot partition if this is gonna be an issue. :frowning:

I have 4 kernels in that dir, but apt autoremove does nothing.

I tried to get a listing but…

andy@7:/boot$ sudo ls > boot_dir_contents.txt
bash: boot_dir_contents.txt: Permission denied

-rw-r--r-- 1 root 38054281 08-28-2017 initrd.img-4.4.0-93-generic
-rw-r--r-- 1 root 38048571 08-15-2017 initrd.img-4.4.0-92-generic
-rw-r--r-- 1 root  1247269 08-11-2017 abi-4.4.0-93-generic
-rw-r--r-- 1 root   190356 08-11-2017 config-4.4.0-93-generic
-rw------- 1 root  3885811 08-11-2017 System.map-4.4.0-93-generic
-rw------- 1 root  7097296 08-11-2017 vmlinuz-4.4.0-93-generic
-rw-r--r-- 1 root  1246835 08-10-2017 abi-4.4.0-92-generic
-rw-r--r-- 1 root   190356 08-10-2017 config-4.4.0-92-generic
-rw------- 1 root  3884798 08-10-2017 System.map-4.4.0-92-generic
-rw------- 1 root  7098032 08-10-2017 vmlinuz-4.4.0-92-generic
-rw-r--r-- 1 root 38055787 05-20-2017 initrd.img-4.4.0-75-generic
-rw-r--r-- 1 root 38056362 05-20-2017 initrd.img-4.4.0-77-generic
-rw-r--r-- 1 root  1246313 04-26-2017 abi-4.4.0-77-generic
-rw-r--r-- 1 root   190355 04-26-2017 config-4.4.0-77-generic
-rw------- 1 root  3883390 04-26-2017 System.map-4.4.0-77-generic
-rw------- 1 root  7081808 04-26-2017 vmlinuz-4.4.0-77-generic
-rw-r--r-- 1 root  1246246 04-20-2017 abi-4.4.0-75-generic
-rw-r--r-- 1 root   190214 04-20-2017 config-4.4.0-75-generic
-rw------- 1 root  3883390 04-20-2017 System.map-4.4.0-75-generic
-rw------- 1 root  7081872 04-20-2017 vmlinuz-4.4.0-75-generic
drwxr-xr-x 4 root     4096 03-10-2017 grub.bak
-rw-r--r-- 1 root   182704 01-28-2016 memtest86+.bin
-rw-r--r-- 1 root   184380 01-28-2016 memtest86+.elf
-rw-r--r-- 1 root   184840 01-28-2016 memtest86+_multiboot.bin

I know of that thread and you are in a catch-22 with the solution unavailable. And with all the possibilities at risk of making it worse the best solution is a new install. Or…

Manually delete the oldest kernel files. Maybe apt will straighten out or (Risk!) make the system unbootable.

Manually run a live session and resize /boot. May take a long time and still may not work or worse (Risk!) unbootable.

The files take up 200 Mb.

Small percentage of my 2 Tb drive. :slight_smile:

Try to remove older kernels(Not all)and try again
A cool tool for kernel management is Ukuu
install it using these commands:

sudo apt-add-repository -y ppa:teejee2008/ppa
sudo apt update
sudo apt install ukuu
~$ df -h / /boot
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--mate--vg-root   27G  5.0G   21G  20% /
/dev/sda1                          472M  119M  329M  27% /boot

Well, I can see the problem. This is a brand new VM from the 16.04.3 ISO doing full disk encryption. With a 32GB virtual disk it automatically chose a size less than 500GB for /boot. I did an update so have 2 kernels now and already /boot is at 27% usage. Plus /boot is on sda1 making it the hardest to increase in size.

Don’t mind me - I’ve been wanting to look at this in detail for awhile.

So have you used that program successfully ?

I just want to be careful.

Screenshot of what Ukuu is showing.

-rw-r--r-- 1 root 38054281 08-28-2017 initrd.img-4.4.0-93-generic
-rw-r--r-- 1 root 38048571 08-15-2017 initrd.img-4.4.0-92-generic
-rw-r--r-- 1 root 38055787 05-20-2017 initrd.img-4.4.0-75-generic
-rw-r--r-- 1 root 38056362 05-20-2017 initrd.img-4.4.0-77-generic

It's confusing as to what kernel here corresponds to the active and installed than Ukuu is showing. ??

I removed the oldest kernel.

I decided to not push my luck by deleting the other installed but not in use kernel. :slight_smile:

No problems after a reboot.

I also decided not to install a newer kernel after reading that hardware can stop working.

I decreased space in /boot by 50 Mbs.

Thanks for the tip.

Here’s another way to clean up /boot – a one line command that will remove all but your current kernel – works a charm:

1 Like