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.)
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
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.
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.
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.
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.