Release
System version
NethServer release 7.5.1804 (final)
Kernel release
3.10.0-862.3.3.el7.x86_64
---> Package sssd-proxy.x86_64 0:1.16.0-19.el7_5.5 will be an update
---> Package sudo.x86_64 0:1.8.19p2-13.el7 will be updated
---> Package sudo.x86_64 0:1.8.19p2-14.el7_5 will be an update
--> Finished Dependency Resolution
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-327.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.6.1.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.6.2.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.10.2.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.16.1.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.21.1.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.21.2.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.26.1.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-514.26.2.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-693.2.2.el7 will be erased
---> Package kernel.x86_64 0:3.10.0-693.5.2.el7 will be erased
--> Finished Dependency Resolution
(36/37): kernel-tools-libs-3.10.0-862.6.3.el7.x86_64.rpm | 6.2 MB 00:00:22
(37/37): kernel-3.10.0-862.6.3.el7.x86_64.rpm | 46 MB 00:00:19
------------------------------------------------------------------------------------------------------------------------------------------------------
Total 2.6 MB/s | 95 MB 00:00:36
Running transaction check
Running transaction test
Transaction check error:
installing package kernel-3.10.0-862.6.3.el7.x86_64 needs 13MB on the /boot filesystem
Error Summary
-------------
Disk Requirements:
At least 13MB more space needed on the /boot filesystem.
The gui error is one of yum cache and metadata, so it’s misleading.
Oh, I’ve seen you’ve posted at this thread, which is linked in mine:
The problem always occurs if updates are installed over softwarecenter. Perhaps @giacomo has an idea what to do, that also by updating at softwarecenter old kernels will be removed?
Looking at my yum logs, it looks like the issue with ever increasing kernels was resolved before the update I applied on Mar 9th, where 10 old kernels were removed.
But it looks like the OP is in a catch-22 situation where yum wants to remove 11 kernels, but will only do so after it installs the latest one, which it can’t because of space issues.
So perhaps following the @m.traeumner advice will allow the update to continue and then the issue will be resolved moving forward.
By command line, both show the same output (packages to install, and to remove). @EddieA,the updates were handled from the server-manger GUI or by yum-cron? Edit: Said nothing, yum-cron was officially released at a later date.
@m.traeumner the machine version is at the top of the post.
Apologies, I posted this as a heads up because I thought this issue resolved long ago with v6, I had already solved this machine’s issue by removing the kernels after installing yum-utils and then applying the updates via the Software center instead of at terminal.
A little more information here, as today I received the email saying that there are updates ready to apply. At the bottom of that email I noticed this:
Removing:
kernel x86_64 3.10.0-693.11.1.el7 @updates 59 M
kernel x86_64 3.10.0-693.11.6.el7 @updates 59 M
This got me looking back at the previous update, and here’s what I found:
The email stated it had a single kernel to remove:
Removing:
kernel x86_64 3.10.0-693.11.1.el7 @updates 59 M
However looking at the yum.log (and the contents of /boot), this action did NOT take place. The updates were applied via the Software Center UI.
As I haven’t applied the latest updates, so far, is there any particular way you would like me to try in an attempt to narrow this down.
server-manger GUI does not remove old kernels due to either pkgaction update not implementing a “packages to remove” action, or some quirks in yum’s python-API version.
I not a software developer most definitely not a python developer nor a yum specialist;
so the next can be not accurate or even completely wrong, still i think it valuable to try to describe my findings.
Yum update from the command line and yum update from the server-manger (GUI) are completely different beasts.