Cannot update kernel because of not enough space in /boot (again)

Have you tried to remove the old kernels?

You can search for them with:

rpm -qa | grep kernel

A list like this should show up e.g.:

kernel

kernel-old

kernel-older

You can remove the old kernels with e.g.:

rpm -e kernel-old

rpm -e kernel-older

Should be ok after you made some space.

Keep 2 though.

I had a lot of difficulty with /boot filling up in the old days. You just have to do the 'rpm -qa | grep kernel' thing, and viciously remove every old kernel that is not essential.

And then, the next time you install an OS, put everything into /. Having separate /boot sounds nice but in the long run only causes problems. Keep / at around 20 GB, more if you will accumulate lots of log files, and have /home be separate.

Since everybody is using VPSes/VMs these days, just make good backups, and re-image the VM if it ever completely fails to boot (which is very rare).

So long as it boots at all, you can fix anything that breaks without having a separate /boot.

Howdy,

You just need to make sure there's enough space in /boot... if you don't think there's many kernels installed, you could always just review your /boot directory (and sub-directories) in order to determine what's using up all the space.

But you could try just removing one old kernel, that may be enough to be able to install the latest one.

I would recommend updating your kernel to the newest one available for your distro though, as it will contain bug and security fixes.

-Eric

Well, that's all pretty small... likely what's taking up much of your space is in another directory under there.

Whatever you delete, just make sure you don't delete the running kernel :-)

But you can delete any older kernel packages that you aren't using. No need to just delete the files, you'd want to remove the RPM/DEB packages that were used to install them.

-Eric

Is your /boot very small? Try df /boot and see. Usually it should be 512 MB or more.

I would check for any files named "core" or "core*" anywhere within the /boot tree, just in case some program dumped core previously and it's taking up room. Try: cd /boot ; find . -name 'core*' -print

Also do cd /boot ; du -s * and it will tell you how much space is in each subdirectory.

Edited: Correction, cd /boot ; du -s * will miss files and directories beginning with a dot. To include those, while excluding .., try this instead:

Speaking from limited experience, this happens to me regularly on my Xubuntu laptop, but I've never experienced it on my RHEL or CentOS dedicated servers.

The /boot partition on my laptop is only 236 MB. This was the default when I installed Xubuntu -- i.e., Xubuntu chose such a small size on a clean 120 GB primary SSD -- and is clearly far less than the 512 MB that joe443 suggests. Every few kernel updates I have to move everything but the current and one older set of files out of /boot to a back-up location to provide space for the current update. It's a pain in the ass, but I haven't (touch wood) had any problems with this procedure yet.

Hope that piece of useless trivia about a non-server system helps. Good luck with it. :)

Craig

My boot is either located with the same partition as all my data or with a dedicated 2gb space on another partition. I don't use any kind of GUI except Virtualmin/Webmin and therefore have lots of extra space

Howdy,

What's the output of this command:

df -h

Looks like your /boot was set up at around 100 MB.

This could be a losing battle. You need a new server, maybe a new service provider.

This time around, make /boot just a subdirectory, not a separate filesystem.

I'm scared of telling you which kernel(s) to delete, just in case the advice turns out to be wrong.

I think you should ask your service provider to re-image your server preserving all data but making /boot into a subdirectory, not a separate filesystem.