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

17 posts / 0 new
Last post
#1 Tue, 02/23/2016 - 09:56
marciano

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

Centos 6.7
I had this problem in the past I was able to fix. Not this time.

http://s13.postimg.org/cz3x04fbr/Screenshot_from_2016_02_23_12_14_39.png

http://s13.postimg.org/4i4ep7amv/Screenshot_from_2016_02_23_12_15_27.png

# package-cleanup --oldkernels --count=2
Loaded plugins: fastestmirror
There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.
--> Running transaction check
---> Package kernel-devel.x86_64 0:2.6.32-573.18.1.el6 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
kernel-devel x86_64 2.6.32-573.18.1.el6 @updates 25 M

Transaction Summary
================================================================================
Remove 1 Package(s)

Installed size: 25 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : kernel-devel-2.6.32-573.18.1.el6.x86_64 1/1
Verifying : kernel-devel-2.6.32-573.18.1.el6.x86_64 1/1

Removed:
kernel-devel.x86_64 0:2.6.32-573.18.1.el6

Complete!

---------------------------------------------

[root@host ~]# yum-complete-transaction
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.mirror.iweb.ca
* epel: mirror.seas.harvard.edu
* extras: centos.mirror.iweb.ca
* updates: centos.mirror.ca.planethoster.net
There are 17 outstanding transactions to complete. Finishing the most recent one
The remaining transaction had 2 elements left to run
--> Running transaction check
---> Package kernel.x86_64 0:2.6.32-573.12.1.el6 will be erased
---> Package kernel.x86_64 0:2.6.32-573.18.1.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================
Package Arch Version Repository Size
======================================================================================================
Installing:
kernel x86_64 2.6.32-573.18.1.el6 updates 30 M
Removing:
kernel x86_64 2.6.32-573.12.1.el6 @updates 126 M

Transaction Summary
======================================================================================================
Install 1 Package(s)
Remove 1 Package(s)

Total size: 30 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Transaction couldn't start:
installing package kernel-2.6.32-573.18.1.el6.x86_64 needs 4MB on the /boot filesystem

[('installing package kernel-2.6.32-573.18.1.el6.x86_64 needs 4MB on the /boot filesystem', (9, '/boot', 3485696L))]
Not removing old transaction files

---------------------------------------------

[root@host ~]# package-cleanup --oldkernels --count=2
Loaded plugins: fastestmirror
There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.
No old kernels to remove

Reboot
Repeat update, nothing has changed.
What can I do without having to manually erase files?
Thank you
M

Tue, 02/23/2016 - 10:24
Welshman
Welshman's picture

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.

Chaos Reigns Within, Reflect, Repent and Reboot, Order Shall Return.

Tue, 02/23/2016 - 12:25
marciano

Not to screw it up is why I used #package-cleanup --oldkernels --count=2 but it seems it is not enough
This is the kernel grep

kernel-2.6.32-573.8.1.el6.x86_64
kernel-headers-2.6.32-573.18.1.el6.x86_64
dracut-kernel-004-388.el6.noarch
abrt-addon-kerneloops-2.0.8-34.el6.centos.x86_64
kernel-devel-2.6.32-573.8.1.el6.x86_64
libreport-plugin-kerneloops-2.0.9-25.el6.centos.x86_64
kernel-2.6.32-573.12.1.el6.x86_64
kernel-firmware-2.6.32-573.18.1.el6.noarch

*.8 and *.12 are the 2 older than the new *.18
*.12 is running

Tue, 02/23/2016 - 22:52
joe443

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.

Wed, 02/24/2016 - 09:00
marciano

Thanks Joe for your reply.
This is a remote dedicated server.
If it does worth I upgrade it to a new server/OS every 2, 3 or 4 years.
The service provider is who install the OS, maybe an automated procedure.
After that, I install webmin/virtualmin

In this particular case Webmin info:
Kernel and CPU Linux 2.6.32-573.12.1.el6.x86_64 on x86_64
So I only have one previous kernel version: kernel-2.6.32-573.8.1.el6.x86_64
Do I have to remove it (let's say remove ALL previous version)?!
Do I have to upgrade to *.18 without having any previous version than the present one *.12?

Wed, 02/24/2016 - 10:32
andreychek

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

Wed, 02/24/2016 - 14:55 (Reply to #6)
marciano

Hi Eric,
This is my /boot content

http://s9.postimg.org/rok8q2g7z/Screenshot_from_2016_02_24_17_48_32.png

Dirs weight a few Kbs
So I guess I can delete vmlinuz-2.6.32-573.8.1.el6.x86_64
Also System.map-2.6.32-573.8.1.el6.x86_64 ?
And then update from Webmin
Is that so?

Wed, 02/24/2016 - 15:29
andreychek

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

Wed, 02/24/2016 - 21:27
joe443

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:

cd /boot ; /bin/ls -1f | egrep -v '^(\.\.|\.)$' | xargs -L 1000 du -s
Thu, 02/25/2016 - 14:14
marciano

This is /boot content

1 .vmlinuz-2.6.32-573.12.1.el6.x86_64.hmac
24242 initramfs-2.6.32-573.8.1.el6.x86_64.img
202 symvers-2.6.32-573.12.1.el6.x86_64.gz
2526 System.map-2.6.32-573.12.1.el6.x86_64
1 .vmlinuz-2.6.32-573.8.1.el6.x86_64.hmac
105 config-2.6.32-573.8.1.el6.x86_64
2525 System.map-2.6.32-573.8.1.el6.x86_64
105 config-2.6.32-573.12.1.el6.x86_64
255 efi
24264 initramfs-2.6.32-573.12.1.el6.x86_64.img
276 grub
4122 vmlinuz-2.6.32-573.8.1.el6.x86_64
202 symvers-2.6.32-573.8.1.el6.x86_64.gz
4123 vmlinuz-2.6.32-573.12.1.el6.x86_64
13 lost+found

I don't know why /boot is so tiny. This is an iWeb dedicated server. They give it us with CentOS and all structure installed.
Is there a way to increase /boot size?
To solve that now, would it be enough to delete
24242 initramfs-2.6.32-573.8.1.el6.x86_64.img ?

Sysinfo:
Operating system CentOS Linux 6.7
Webmin version 1.782
Theme version Authentic Theme 17.72
Time on system Thursday, February 25, 2016 5:10 PM
Kernel and CPU Linux 2.6.32-573.12.1.el6.x86_64 on x86_64

Thank you
M

Fri, 02/26/2016 - 02:44
craigh

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

Fri, 02/26/2016 - 02:52
coderinthebox

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

Visit me at coderinthebox.com

Fri, 02/26/2016 - 10:22
andreychek

Howdy,

What's the output of this command:

df -h

Fri, 02/26/2016 - 18:09
marciano

Filesystem Size Used Avail Use% Mounted on
/dev/md2 913G 376G 491G 44% /
tmpfs 3.5G 0 3.5G 0% /dev/shm
/dev/md0 93M 63M 25M 72% /boot
/dev/md1 2.0G 3.1M 1.9G 1% /tmp

Fri, 02/26/2016 - 19:04
joe443

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.

Sat, 02/27/2016 - 09:54
marciano

To solve that now, would it be enough to delete
24242 initramfs-2.6.32-573.8.1.el6.x86_64.img ?

Sysinfo:
Operating system CentOS Linux 6.7
Webmin version 1.782
Theme version Authentic Theme 17.72
Time on system Thursday, February 25, 2016 5:10 PM
Kernel and CPU Linux 2.6.32-573.12.1.el6.x86_64 on x86_64

Sat, 02/27/2016 - 11:19
joe443

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.

Topic locked