2025-01-06

Issues I found with CentOS Stream 10

Notes on common issues with CentOS Stream 10

Stephen J Smoogen

2024-01-06

Introduction

I recently moved a home server from Fedora Linux 41 to CentOS Stream 10. The reason for the move was not related to Fedora, but due to a series of hardware failures on a 4 year old server. The internal NVME died and the 2 SSD drives I had as a raid array for running virtual guests, mock builds and other things started reporting SMART errors. With the recent release of CentOS Stream 10, and most of my day work going to be related to it, I figured it was time to buy some replacement drives and install a new operating system.

While doing this reinstall, I saw other people were running into issues and posting on mailing lists and forums for help. I figured I would try to collect all the info in one place and see if it would help people.

Problem 1: Old Hardware

Problem Description

You have tried to install CentOS Stream 10 on your system which ran previous versions of CentOS without problems. However now the system will crash at different points in the install or not boot at all during the media. Re-cutting the ISO or other items does not fix the issue.

Why is this happening?

The issue is due to CentOS Stream 10 only supports hardware that has the x86-64-v3 instruction set. This is an instruction set which Intel introduced in 2013 with the Haswell chip set and AMD added similar instructions in 2015. Sadly, Intel did not introduce the full instruction set to all their sold CPU’s after 2013, so there are various ‘low end’ Atom and similar Cups built from 2013 to maybe 2020 which will not work.

The reason for the change in instruction sets comes down to Red Hat Enterprise Linux being aimed at data center hardware which ‘theoretically’ gets replaced on a 8 year life cycle. Owners of this newer hardware usually want to use the hardware as much as possible so want libraries and tools to use the newer instructions. There is also the fact that supporting older hardware with newer code becomes harder and harder running anything from manufacturers no longer giving driver updates to the general problem of newer software using more memory and CPU cycles. People with older hardware are generally going to need to stick with CentOS Stream 9 until it reaches its EOL in early 2027 or move to another operating system which is aimed to support older systems.

What can I do?

This is a fundamental instruction set change. The only fixes are to buy newer hardware, stay on an EL clone of 8 or 9, or move to a different operating system.

Problem 2: Server Going to Sleep Problem

Problem Description

The system was installed with the default ‘Server with GUI’ and after the install completes the system goes into ‘deep sleep’ mode after no activity on the GUI console. This may only occur after a user has logged in one time to the server console, but may also happen without any user interaction.

Why is this happening?

My first worry was that the system had died, but when pressing a key, the system power back up from a low powered state. Doing a search for bugs, I ran into problems with Red Hat’s https://issues.redhat.com search capabilities and ended up looking through stack overflow and other places. The issue seems to be that the default GNOME settings assume that this is either a ‘desktop’ or ‘laptop’ which when not in constant use will want to sleep to save power. This is not a useful setting for a 24x7 server, and neither was the fact that the GUI settings to turn this off mentioned on the GNOME pages did not seem to exist in the version of GNOME shipped in the current CentOS Stream 10 (2024-12-30).

What can I do?

Doing some other searches I was able to cobble together some command line options which turned off the settings.

## Set the inactive sleep to 0 when there is power to the
## system.
$ sudo -u gdm dbus-run-session gsettings \
   set org.gnome.settings-daemon.plugins.power \
   sleep-inactive-ac-timeout 0
## Do the same for the main user
$ dbus-run-session gsettings \
   set org.gnome.settings-daemon.plugins.power \
   sleep-inactive-ac-timeout 0

I am expecting that this will be reported to Red Hat at some point and can be fixed in the install settings so new users won’t have this in the future.

Problem 3: Continuous prompt error mentioning EPEL

Problem Description

After enabling an external repository like the EPEL-10, the system will continually pause during shell entries and give an error like:

Failed to search for file: Failed to download gpg key for
repo 'epel': Curl error (37):
Could not read a file:// file for
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
[Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major]

Why is this happening?

This problem occurs because of two helpful changes coming into contact with each other.

The first helpful tool is that the various shells in CentOS Stream 10 come with helpers which will catch ‘command not found’ and try to figure out if you mistype it:

vm
bash: vm: command not found...
Similar command is: 'mv'

or if you need to install an additional package set from a repository. This can be helpful even on systems which are controlled by a tool like puppet or ansible as sometimes something expected was just missed on the system.

The second helpful change is that a much used additional repository EPEL is trying to fix a reoccurring problem with EL releases. Since the release of EL8 in 2019, Red Hat has been doing a major release every 3 years and around 10 minor releases per major release every 6 months. In a change with earlier Enterprise Linux, where major re-bases did not happen that much, each minor release may see one or more subsystems upgraded or ‘aged out’ as what Red Hat call’s an application stream is no longer supported. This is useful for systems which find they need a newer python for some reason but still be on an older base operating system. However this is also hard for people using external software which may no longer have base libraries needed.

In order to fix this, EPEL has decided that for EL10 they would build software CentOS Stream 10, and then branch every minor Red Hat Enterprise Linux 10.x release with updates and changes which match what is in a particular minor release. If a system administrator has decided that a system needs to stay on 10.2 even after 10.3 is released, they will be able set a variable which will keep EPEL working without having to mirror a version from the Fedora archives. Other repositories like rpmfusion should be able to do this also.

The problem is that the helper is not able to parse the new format of the EPEL release files and so isn’t filling out the variable $releasever_major. Because it is failing, the package cache looks to be invalid so it tries to renew the cache EVERY time. This becomes maddening if you have a shell prompt which is looking for a ‘command’ which hasn’t been installed on the system yet. My shell has an additional helper looking for git and and such. It manipulates the PS1 variable and so every command was giving me an error, then a long pause and the repeated line about unable to download the gpg key.

What can I do?

The command lookup helper in question comes with the GNOME PackageKit. This may take a while for it to be updated to understand the new repository environment $releasever_major so at the moment, I suggest getting rid of the helper.

$ sudo dnf remove PackageKit-command-not-found
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server.
You can use subscription-manager to register.

Dependencies resolved.

Any shells currently in use may need to restart or resource their .profile in order to stop erroring.

Problem 4: Unwanted Subscription Manager Messages

Problem Description

Whenever a dnf command is given, there is a warning printed out saying:

[root@xenadu etc]# dnf update
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server.
You can use subscription-manager to register.

Why is this happening?

This warning comes from the fact that CentOS Stream is the ‘upstream’ of Red Hat Enterprise Linux and in being that there is a desire to make the two install as similar set of packages as possible for testing. However in the case of ‘subscription-manager’ this is a tool which isn’t useful for a CentOS system since subscribing it to the Red Hat entitlement systems is not needed.

What can I do?

This problem is solved by removing a set of subscription manager packages from the box:

[root@xenadu etc]# dnf remove subscription-manager*
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server.
You can use subscription-manager to register.

Dependencies resolved.
===============================================================
 Package               Arch   Version         Repository  Size
===============================================================
Removing:
 subscription-manager  x86_64 1.30.2-2.el10   @anaconda  3.7 M
 subscription-manager-rhsm-certificates
                       noarch 20220623-6.el10 @anaconda   27 k
Removing dependent packages:
 insights-client       noarch 3.2.8-2.el10    @AppStream 1.4 M
Removing unused dependencies:
 libdnf-plugin-subscription-manager
                       x86_64 1.30.2-2.el10   @anaconda   44 k
 python3-cloud-what    x86_64 1.30.2-2.el10   @anaconda  156 k
 python3-decorator     noarch 5.1.1-12.el10   @anaconda   77 k
 python3-iniparse      noarch 0.5-10.el10     @anaconda  124 k
 python3-inotify       noarch 0.9.6-36.el10   @anaconda  302 k
 python3-librepo       x86_64 1.18.0-3.el10   @anaconda  187 k
 python3-subscription-manager-rhsm
                       x86_64 1.30.2-2.el10   @anaconda  548 k

Transaction Summary
===============================================================
Remove  10 Packages

Freed space: 6.6 M
Is this ok [y/N]:

2 comments:

Felipe Borges said...

Hey! I work in GNOME Settings Daemon and we have fixed the sleep-on-server issue. It should be available soon as the fix makes its way to the compose.

The "server with a gui" usecase is something that is often not considered in GNOME upstream, but I want to focus on making that work by solving issues like this one you pointed out. Please, let me know if you have any other tips/recommendations.

Stephen Smoogen said...

Thanks for the update.