DNF install and conflicting requests – nothing provides module(platform:el8) needed by module

Here there are broken modules in the DNF package manager. It was a result of an upgrade, but it may occur if some unofficial repositories mess up with them:
On every DNF command, there are multiple problem-reporting lines about conflicts in different DNF modules.

[root@srv ~]# dnf info epel-release
Last metadata expiration check: 0:13:42 ago on Tue Oct 11 13:11:51 2022.
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(platform:el8) needed by module httpd:2.4:8050020211112043353:b4937e53.x86_64
 Problem 2: conflicting requests
  - nothing provides module(platform:el8) needed by module nginx:1.14:8000020191007205758:55190bc5.x86_64
 Problem 3: conflicting requests
  - nothing provides module(platform:el8) needed by module nodejs:10:8030020210304194401:30b713e6.x86_64
 Problem 4: conflicting requests
  - nothing provides module(platform:el8) needed by module perl:5.26:8000020190628020724:55190bc5.x86_64
 Problem 5: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-IO-Socket-SSL:2.066:8030020201222215140:1e4bbb35.x86_64
 Problem 6: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-libwww-perl:6.34:8030020201223164340:b967a9a2.x86_64
 Problem 7: conflicting requests
  - nothing provides module(platform:el8) needed by module php:7.2:8020020200507003613:2c7ca891.x86_64
 Problem 8: conflicting requests
  - nothing provides module(platform:el8) needed by module satellite-5-client:1.0:8010020191114035551:cdc1202b.x86_64
 Problem 9: conflicting requests
  - nothing provides module(platform:el8) needed by module virt:rhel:8050020211221192853:b4937e53.x86_64
Installed Packages
Name         : epel-release
Version      : 9
Release      : 4.el9
Architecture : noarch
Size         : 25 k
Source       : epel-release-9-4.el9.src.rpm
Repository   : @System
From repo    : epel
Summary      : Extra Packages for Enterprise Linux repository configuration
URL          : http://download.fedoraproject.org/pub/epel
License      : GPLv2
Description  : This package contains the Extra Packages for Enterprise Linux (EPEL) repository
             : GPG key as well as configuration for yum.

The DNF package manager offers modules to group software. Each module may have one or multiple streams, representing the major version of the software it groups in a single entity. As can be seen above from the DNF output, the module name is httpd and the stream is 2.4. It is clear the module httpd is responsible for the installation of Apache Web server. More on the subject here – https://docs.fedoraproject.org/en-US/modularity/using-modules/

To fix the problems above and clear the errors just reset the modules to their initial default state with:

dnf module reset httpd

Keep on reading!

libelf was not found in the pkg-config search path

Building from source under CentOS the user may stumble on some compilation errors and most of them are for missing -devel packages. Here is such example with not so easy to find the name of a missing library:

[/tmp/netdata-libbpf-El77Ld/libbpf-0.0.9_netdata-1/src]# env CFLAGS=-fPIC CXXFLAGS= LDFLAGS= BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=.. make install 
Package libelf was not found in the pkg-config search path.
Perhaps you should add the directory containing `libelf.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libelf' found
mkdir -p build/staticobjs
cc -I. -I../include -I../include/uapi -DCOMPAT_NEED_REALLOCARRAY -fPIC -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -c bpf.c -o build/staticobjs/bpf.o
cc -I. -I../include -I../include/uapi -DCOMPAT_NEED_REALLOCARRAY -fPIC -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -c btf.c -o build/staticobjs/btf.o
btf.c:17:18: fatal error: gelf.h: No such file or directory
 #include <gelf.h>
                  ^
compilation terminated.
make: *** [build/staticobjs/btf.o] Error 1
 FAILED   

The missing development library file is with the name: elfutils-libelf-devel. Installing the package with yum or dnf will resolve the above error:

yum install -y elfutils-libelf-devel

Or for CentOS 8 and newer Fedora versions:

dnf install -y elfutils-libelf-devel

removing the default kernel in CentOS 8 – remove elrepo kernel

Removing the default kernel aka the loaded kernel in CentOS 8 maybe challenging because the package is protected and cannot be removed by the yum or dnf.
Here is the case: an elrepo kernel-ml loaded and the dnf prints it cannot remove the package, because it is protected:

[root@srv ~]# dnf remove kernel-ml kernel-ml-core kernel-ml-modules
Error: 
 Problem: The operation would result in removing the following protected packages: kernel-ml-core
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@srv ~]# uname -a
Linux srv.localhost 5.10.4-1.el8.elrepo.x86_64 #1 SMP Tue Dec 29 11:04:23 EST 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@srv ~]# grubby --default-kernel
/boot/vmlinuz-5.10.4-1.el8.elrepo.x86_64

The system is booted up with the kernel we are trying to remove, which is impossible.

The solution is to set a new default kernel and load it. Then dnf will be able to remove the first kernel.

For CentOS 7, just use the yum instead of dnf command.
Using grubby is really easy and straightforward:

STEP 1) List all installed and available to boot kernels

[root@srv ~]# grubby --info=ALL |grep ^kernel
kernel="/boot/vmlinuz-5.10.4-1.el8.elrepo.x86_64"
kernel="/boot/vmlinuz-4.18.0-259.el8.x86_64"
kernel="/boot/vmlinuz-4.18.0-257.el8.x86_64"
kernel="/boot/vmlinuz-0-rescue-45e12f0814fd4947b99cbdcb88950361"

STEP 2) Select the kernel to load the next time

[root@srv ~]# grubby --set-default "/boot/vmlinuz-4.18.0-259.el8.x86_64"
The default is /boot/loader/entries/45e12f0814fd4947b99cbdcb88950361-4.18.0-259.el8.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-259.el8.x86_64

Keep on reading!