Notes on common issues with CentOS Stream 10
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]: