Sure, I'll just use 1/6th of SSD to store 60 megabytes.
$ du -hs /boot/
56M /boot/
I don't know what planet you're living on but it's certainly not this one. Between a Ubuntu desktop, a laptop and personal server with multiple Ubuntu VM's on it, all of which are kept up rigorously to date, I fix this problem at least three times a year, every year.
The command line process to fix it[1] is a multi-stage mess of dense bash-foo that comes with a 140 word, two paragraph explanation so that /ubuntu veterans/ can figure out what is going on without resorting to scouring the man page for flags. The friendly GUI process to fix it relies on a third party tool that is no longer maintained[2].
It is not possible to explain to non-technical users what is happening here, which means the only thing they can do when they see this is call their technical friend and cry for help. This is exactly the kind of user experience that makes people think Linux is not ready for widespread desktop use.
This is definitely something the OS should take care of itself. I'm ignorant of the challenges that caused it to be this way in the first place, but in my ignorance I would advocate that:
a) the partition be made larger by default b) the OS auto-purge any kernel package more than three revisions old
[1] https://askubuntu.com/questions/89710/how-do-i-free-up-more-... [2] https://launchpad.net/ubuntu-tweak/
IOW, it does automatically remove old kernels, it just keeps the last 2-3.
So, yes, run "apt-get autoremove", that's it.
I love having a terminal with bash and use it constantly, but I don't think it should be needed for the system to just go on working.
(warning, rant inside)
Which is not to say you're lying, I'm just sort of flabbergasted that this is an issue for so many people. Do you run autoremove much? Maybe that would solve it for you?
sudo bash -c "apt auto-remove --purge; apt update; apt upgrade" is what I usually run.
Prefer they focus engineering cycles on actual engineering problems.
And I believe my boot partition is only 256MB, and I didn't set it to that. That was a system default.
Super common in enterprise deployments. I ran into this a bunch on my $EMPLOYER-issued workstation.
I understand that it may be wise to keep the old kernel around so the system can be booted in case there is a hardware incompatibility or breakage in the new release, but that justifies only one additional kernel. Ubuntu keeps those kernels sitting there until you `apt-get autoremove`, and that means that unless you're running that command routinely, the boot partition is going to fill up at some point, no matter how big you make it.
This is especially a problem for people who use the unattended-upgrades package. I've autoremoved and had it clean up almost a gig of old kernel images before.
The update process generates on the order of 100mb/month.