To much kernels installed, but config gives a limit of 5

(Michael Träumner) #1

NethServer Version: 7.4.1708
Module: yum kernel

I’ve found an already discussed problem. I’ve to much kernels installed and can’t do an update because the boot-filesystem has not enough space.

Transaction check error:
installing package kernel-3.10.0-693.17.1.el7.x86_64 needs 14MB on the /boot filesystem

The discussion is at:

yum list installed kernel

gives me

kernel.x86_64                     3.10.0-327.el7                           @anaconda
kernel.x86_64                     3.10.0-327.36.1.el7                      @updates
kernel.x86_64                     3.10.0-327.36.2.el7                      @updates
kernel.x86_64                     3.10.0-327.36.3.el7                      @updates
kernel.x86_64                     3.10.0-514.2.2.el7                       @updates
kernel.x86_64                     3.10.0-514.6.1.el7                       @updates
kernel.x86_64                     3.10.0-514.10.2.el7                      @updates
kernel.x86_64                     3.10.0-514.16.1.el7                      @updates
kernel.x86_64                     3.10.0-514.21.1.el7                      @updates
kernel.x86_64                     3.10.0-514.21.2.el7                      @updates
kernel.x86_64                     3.10.0-514.26.1.el7                      @updates
kernel.x86_64                     3.10.0-514.26.2.el7                      @updates
kernel.x86_64                     3.10.0-693.2.2.el7                       @updates
kernel.x86_64                     3.10.0-693.5.2.el7                       @updates
kernel.x86_64                     3.10.0-693.11.1.el7                      @updates

I’ve cleaned it with

package-cleanup --oldkernels --count=2

and it works, but the limit at the config is set to 5 and I’ve 15 installed.

# ================= DO NOT MODIFY THIS FILE =================
# Manual changes will be lost when this file is regenerated.
# Please read the developer's guide, which is available
# at NethServer official site:
# 20proxy - disabled

# 30groups use compat group mode

#  This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
#  It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

Has somebody an idea?

Again with the hoarding of kernels
6.9 /boot filling issue
(Filippo Carletti) #2

I never reproduced the problem. I checked tens of systems and all of them have 5 kernels installed.
Did you always apply updates using the server manager software center button?
The problem could come from the interface command. What do you think @davidep?

(Michael Träumner) #3

I did my updates always at the softwarecenter, but this time it didn’t worked, gives me the “clear yum cache” error. After clearing it I tried again, but no success. So I tried it at the commandline and got the “needs 14MB on the /boot filesystem” error.

You didn’t find any difference?

(Marc) #4

Question: Is installonlypkgs option enabled even if not present on yum.conf ? (I guess it is)

installonly_limit Number of packages listed in installonlypkgs to keep installed at the same time. Note that as of version 3.2.24, yum will now look in the yumdb for a installonly attribute on installed packages. If that attribute is “keep”, then they will never be removed.

installonlypkgs List of package provides that should only ever be installed, never updated. Kernels in particular fall into this category. Defaults to kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-PAE, kernel-PAE-debug.

Note that because these are provides, and not just package names, kernel-devel will also apply to kernel-debug-devel, etc.

(Filippo Carletti) #5

Quoting myself:

I’ve discovered the problem: that lone server had kernel-debug installed, doubling the count of kernels. So it really has 5 kernels installed.
We’re back to start: I can’t reproduce the problem, all servers have 5 kernels installed.

(Michael Träumner) #6
[root@groupware ~]# rpm -qa | grep kernel

I think the most are really different kernels. Only the ones with tools and headers are not different ones.

(Davide Principi) #7

Do these commands match anything?

find /var/lib/yum/yumdb/ | grep installonly
grep -R installonly /var/lib/yum/yumdb/

(Michael Träumner) #8

Thanks for answer Davide,
like I wrote at my first post I have done

package-cleanup --oldkernels --count=2

It also deletes the only one which was not an update

kernel.x86_64                     3.10.0-327.el7                           @anaconda

So I had only 2 kernels left, 3 after the last update.

Your commands gives out nothing, but I think after deleting the old ones it is not meaningful.
Perhaps somebody else has more than 5 kernels and can help with the output.

(Marc) #9

This is from a server installed long ago (~1y), and kernel limit seems to be working as expected. All updates were done through command line (not from server-manager).

Installed Packages
kernel.x86_64             3.10.0-514.21.1.el7             @updates
kernel.x86_64             3.10.0-514.26.2.el7             @updates
kernel.x86_64             3.10.0-693.5.2.el7              @updates
kernel.x86_64             3.10.0-693.11.1.el7             @updates
kernel.x86_64             3.10.0-693.11.6.el7             @updates

@davidep commands return empty.

(Rolf Bakker) #10

I too update always from CLI (yum update), never from server manager.
Is that a potentially hazardous way of updating?
(no problems with too many kernels either)

(Markus Neuberger) #11

Software Center uses yum for updating. I update via Software Center and yum directly and don’t have more than 5 kernels.

(Michael Träumner) #12

@Jim What is about you, how many kernels have you at this time.
I ask you, because you are the other one who had such problems.

(Eddie Atherton) #13


[root@Nethserver ~]# find /var/lib/yum/yumdb/ | grep installonly
[root@Nethserver ~]# grep -R installonly /var/lib/yum/yumdb/
[root@Nethserver ~]# yum list installed kernel
Loaded plugins: changelog, fastestmirror, nethserver_events
Loading mirror speeds from cached hostfile
 * base:
 * epel:
 * extras:
 * nethforge:
 * nethserver-base:
 * nethserver-updates:
 * updates:
Installed Packages
kernel.x86_64                   3.10.0-514.el7                         @anaconda
kernel.x86_64                   3.10.0-514.6.2.el7                     @updates
kernel.x86_64                   3.10.0-514.10.2.el7                    @updates
kernel.x86_64                   3.10.0-514.16.1.el7                    @updates
kernel.x86_64                   3.10.0-514.21.1.el7                    @updates
kernel.x86_64                   3.10.0-514.21.2.el7                    @updates
kernel.x86_64                   3.10.0-514.26.1.el7                    @updates
kernel.x86_64                   3.10.0-514.26.2.el7                    @updates
kernel.x86_64                   3.10.0-693.2.2.el7                     @updates
kernel.x86_64                   3.10.0-693.5.2.el7                     @updates
kernel.x86_64                   3.10.0-693.11.1.el7                    @updates
kernel.x86_64                   3.10.0-693.11.6.el7                    @updates
[root@Nethserver ~]#

All updates were done via the UI.


(Marc) #14

@davidep, should we investigate pkgaction and the python API for yum?

(Davide Principi) #15

Yes please!

It seems there are some clues leading to the UI. I looked at the python code of pkgaction. The way the configuration is initialized could differ from the yum cli command.

(Marc) #16

An observation and an idea/theory, hoping to bring some clues:

When using yum, if a new kernel is available and the number of installed kernels matches the number of kernels to keep, an old kernel is removed:

 Package                           Arch       Version                       Repository              Size
 kernel                            x86_64     3.10.0-693.17.1.el7           updates                 43 M

 dhclient                          x86_64     12:4.2.5-58.el7.centos.1      updates                282 k
 kernel-tools                      x86_64     3.10.0-693.17.1.el7           updates                5.1 M
 kernel-tools-libs                 x86_64     3.10.0-693.17.1.el7           updates                5.1 M
 kmod                              x86_64     20-15.el7_4.7                 updates                121 k
 kmod-libs                         x86_64     20-15.el7_4.7                 updates                 50 k

 kernel                            x86_64     3.10.0-514.21.1.el7           @updates               148 M

Maybe pkgaction update (or UI) only looks which packages can be updated but it’s unaware of associated removal actions.

Again with the hoarding of kernels