AlmaLinux OS 9 und 10 mit nativen Nvidia Open GPU-Treibern
AlmaLinux OS 9 und 10 enthalten jetzt Pakete, die native Unterstützung für Nvidias Open GPU-Treiber ermöglichen – mit Secure Boot.
AlmaLinux OS 9 und 10 enthalten jetzt Pakete, die native Unterstützung für Nvidias Open GPU-Treiber ermöglichen – mit Secure Boot.
Wenn Sie meinen vorigen Blogbeitrag über Hetzner-Cloud-Benchmarks gelesen haben, ist Ihnen vielleicht aufgefallen, dass ich Alma Linux 10 in einer Hetzner-Cloud-Instanz ausgeführt habe, um dort Geekbench-Tests auszuführen. Das war nicht so einfach: Hetzner bietet Alma Linux 10 noch nicht als Installations-Image an. (Update 3.7.2025: mittlerweile schon, sowohl AlmaLinux 10 als auch Rocky Linux 10)
Also habe ich eine neue Instanz zuerst mit Alma Linux 9 eingerichtet und danach mit Elevate ein Update auf Version 10 durchgeführt. Das ist erstaunlich unkompliziert gelungen, obwohl Version-10-Updates eigentlich noch im Beta-Test sind.
Update 10.7.2025: Version-10-Updates werden jetzt offiziell unterstützt (Quelle)
RHEL und alle Klone durchlaufen über reguläre Updates alle Minor-Releases. Wenn Sie also Alma Linux 9.0 installiert haben, erhalten Sie durch die regelmäßige Installation von Updates nach und nach die Versionen 9.1, 9.2 usw. Ein Update auf die nächste Major-Version ist aber nicht vorgesehen.
Mit LEAPP hat Red Hat ein Framework geschaffen, um Major-Version-Updates für RHEL durchzuführen. LEAPP wurde sehr allgemeingültig konzipiert und kümmert sich um Pre-Upgrade-Kontrollen, Paketabhängigkeiten, den Workflow zwischen verschiedenen Stadien des Upgrades usw.
Elevate ist eine Community-Erweiterung zu LEAPP, die über das eigentliche Upgrade hinaus in manchen Fällen auch einen Wechsel der Paketquellen zwischen Alma Linux, CentOS, Oracle Linux und RockyLinux durchführen kann. Sie können mit Elevate beispielsweise zuerst von CentOS 7 zu RockyLinux 8 migrieren und dann weiter zu Rocky Linux 9 upgraden.
Bevor Sie Elevate anwenden, müssen Sie ein vollständiges Backup durchführen und Ihren Rechner bzw. Ihre virtuelle Maschine neu starten:
dnf update
reboot
Danach richten Sie eine Paketquelle für Elevate ein und installieren das für Sie relevante Upgrade-Modul (für das Beispiel in diesem Artikel mit der Zieldistribution Alma Linux also leapp-data-almalinux
).
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
# für AlmaLinux
dnf install leapp-upgrade leapp-data-almalinux
# alternativ für Rocky Linux (etc.)
dnf install leapp-upgrade leapp-data-rocky
Als nächstes folgt ein Test, ob das gewünschte Upgrade (plus gegebenenfalls eine Migration zu einer anderen Distribution, hier nicht relevant) überhaupt möglich ist:
leapp preupgrade
leapp preupgrade
erzeugt zwei Dateien: Einen umfassenden Bericht, der alle möglichen Probleme aufzählt, und eine answer
-Datei, in die Sie gegebenenfalls Optionen eintragen müssen (z.B. mit leapp answer --section check_vdo.confirm=True
). In meinem Fall — Upgrade einer Minimalinstallation von Alma Linux 9 auf 10, hat leapp preupgrade
auf die folgenden Probleme hingewiesen, aber keine answer
-Einträge verlangt.
/etc/sysconfig/network-scripts
hc-utils
)cat /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Legacy network configuration found
Summary: Network configuration files in legacy "ifcfg" format are present ...
- /etc/sysconfig/network-scripts/ifcfg-eth0
Related links:
- How to migrate the connection from ifcfg to NetworkManager keyfile plugin?:
https://access.redhat.com/solutions/7083803
- nmcli(1) manual, describes "connection migrate" sub-command.:
https://networkmanager.dev/docs/api/latest/nmcli.html
...
Remediation: [hint] Convert the configuration into NetworkManager native "keyfile" format.
----------------------------------------
Risk Factor: high
Title: Detected custom leapp actors or files.
Summary: We have detected installed custom actors or files on the system.
These can be provided e.g. by third party vendors ... This is allowed
and appreciated. However Red Hat is not responsible for any issues caused
by these custom leapp actors ...
The list of custom leapp actors and files:
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/distro/almalinux/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
...
Den vollständigen Report können Sie sich hier durchlesen.
Wirklich kritisch war aus meiner Sicht nur die Netzwerkkonfiguration; die restlichen Hinweise und Empfehlungen habe ich ignoriert. Das Paket hc-utils
(Hetzner Cloud Utilities) ist nur für Funktionen relevant, die in meinem Fall ohnedies nicht genutzt werden (siehe hier).
Auch die veraltete Netzwerkkonfiguration stammt vom Hetzner-Image für Alma Linux 9. Eine Umstellung auf eine *.nmconnection
-Datei für den NetworkManager gelingt erstaunlich unkompliziert mit einem einzigen Kommando:
nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-eth0
Mit einem weiteren Reboot habe ich sichergestellt, dass die Umstellung auch funktioniert.
leapp upgrade
initiiert nun das Upgrade auf Alma Linux 10. Dabei werden seitenweise Logging-Ausgaben produziert (siehe den kompletten Output mit ca. 3150 Zeilen):
leapp upgrade
==> Processing phase `configuration_phase` ...
==> Processing phase `FactsCollection` ...
...
==> Processing phase `TargetTransactionFactsCollection`
Create custom repofile containing information about
repositories found in target OS installation ISO, if used.
Initializes a directory to be populated as a minimal environment
to run binaries from the target system.
AlmaLinux 10.0 - BaseOS 5.9 MB/s | 2.8 MB 00:00
AlmaLinux 10.0 - AppStream 11 MB/s | 5.6 MB 00:00
AlmaLinux 10.0 - CRB 5.0 MB/s | 2.2 MB 00:00
AlmaLinux 10.0 - HighAvailability 161 kB/s | 69 kB 00:00
AlmaLinux 10.0 - Extras 28 kB/s | 12 kB 00:00
AlmaLinux 10.0 - SAP 8.3 kB/s | 3.5 kB 00:00
AlmaLinux 10.0 - SAPHANA 35 kB/s | 15 kB 00:00
AlmaLinux 10.0 - RT 2.8 MB/s | 1.1 MB 00:00
AlmaLinux 10.0 - NFV 2.8 MB/s | 1.1 MB 00:00
Dependencies resolved.
...
Transaction Summary: Install 153 Packages
...
Complete!
==> Processing phase `TargetTransactionCheck`
...
Transaction Summary
Install 63 Packages
Upgrade 389 Packages
Remove 18 Packages
Downgrade 3 Packages
Transaction test succeeded.
Complete!
====> add_upgrade_boot_entry
Add new boot entry for Leapp provided initramfs.
A reboot is required to continue. Please reboot your system.
Debug output written to /var/log/leapp/leapp-upgrade.log
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system
2. Detected custom leapp actors or files.
3. Berkeley DB (libdb) has been detected on your system
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 1
LOW severity reports: 2
INFO severity reports: 1
Before continuing, review the full report below for details about discovered
problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
Reboot the system to continue with the upgrade. This might take a while
depending on the system configuration.
Make sure you have console access to view the actual upgrade process.
Jetzt wird es unheimlich: Mit reboot
starten Sie die nächste Phase des Upgrade-Prozesses, der im Blindflug erfolgt. Der Rechner bzw. die virtuelle Maschine wird während dieser Phase noch einmal neu gestartet. Wenn Sie nicht vor dem Rechner sitzen, sehen Sie weder, was passiert, noch haben Sie über eine SSH-Verbindung die Möglichkeit, einzugreifen.
reboot
Wenn alles gut geht, können Sie sich nach ein paar Minuten wieder einloggen. Bei mir hat es funktioniert:
ssh root@1.2.3.4
cat /etc/os-release
NAME="AlmaLinux"
VERSION="10.0 (Purple Lion)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:10::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
VENDOR_NAME="AlmaLinux"
VENDOR_URL="https://almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"
ALMALINUX_MANTISBT_PROJECT="AlmaLinux-10"
ALMALINUX_MANTISBT_PROJECT_VERSION="10.0"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.0"
SUPPORT_END=2035-06-01
Ich habe mit diesem Experiment erreicht, was ich haben wollte: eine funktionierende, minimale Alma-Linux-10-Installation in einer im Internet erreichbaren virtuellen Maschine. Ich kann damit experimentieren. Vermutlich wird Hetzner in ein paar Wochen Alma Linux 10 als reguläres Cloud-Installations-Image anbieten. Dann werde ich diese Installation vermutlich wieder abschalten.
In der Vergangenheit habe ich Elevate auch schon auf lokale virtuelle Maschinen mit (nicht besonders wichtigen) Testumgebungen angewendet, ebenfalls zu meiner Zufriedenheit.
Aber ich würde mich niemals trauen, für ein produktiv wichtiges System auf diese Weise ein Upgrade oder womöglich eine Migration auf eine andere Distribution durchzuführen — und schon gar nicht, wenn ich keinen physischen Zugriff auf die Installation habe. Es kann dabei so viel schief gehen! Es ist unklar, ob danach überhaupt eine Reparatur möglich ist, und wenn ja, wie lange diese dauern würde.
Vergessen Sie zuletzt nicht, dass das Upgrade von Alma Linux 9 auf Version 10 aktuell noch im Beta-Test ist. Bei meinem Minimalsystem hat es funktioniert, aber das ist keine Garantie, dass das bei Ihnen auch klappt!
Kurz und gut: Die Kombination aus LEAPP und Elevate bietet eine großartige Möglichkeit, Major Upgrades für RHEL und seine Klone durchzuführen. Das ist ideal für Entwicklungs- und Testsysteme. Aber wie bei jedem Linux-Distributions-Upgrade kann dabei viel schief gehen. Der sichere Weg für produktiv wichtige Installationen ist immer eine Neuinstallation! Sie können dann in aller Ruhe sämtliche Funktionen testen, zum Schluss die Daten migrieren und mit minimaler Downtime eine Umstellung durchführen.
Die zwei günstigsten Angebote in der Hetzner-Cloud sind Instanzen mit zwei CPU-Cores, 4 GB RAM und 40 GB Diskspace: Einmal mit virtuellen ARM-CPU-Cores (»CAX11«), einmal mit virtuellen x86-Cores (»CX22«). Der Preis ist identisch: 3,95 EUR/Monat inkl. USt (für D) plus ein Aufpreis von 0,50 EUR/Monat für eine IPv4-Adresse. Die naheliegende Frage ist: Welches Angebot gibt mehr Rechenleistung? Dieser Frage bin ich an einem verregneten Pfingstsonntag auf den Grund gegangen.
Ein »virtueller CPU-Core« heißt in diesem Zusammenhang, dass auf einem Server mehrere/viele virtuelle Maschinen laufen. Je nach Auslastung kann es sein, dass die für eine virtuelle Maschine vorgesehen CPU-Cores nicht vollständig verfügbar sind. Es gibt auch virtuelle Maschinen mit dezidierten Cores, die immer zur Verfügung stehen — aber die sind natürlich teurer.
Für meine Tests habe ich zwei Cloud-Instanzen mit Alma Linux 9 eingerichtet, einmal mit zwei ARM-CPU-Cores (CAX11), einmal mit zwei x86-CPU-Cores (CX11). Außer tar
und Geekbench habe ich keine weitere Software installiert. /proc/cpuinfo
lieferte die folgenden Ergebnisse:
cat /proc/cpuinfo # CX11 / x86
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel Xeon Processor (Skylake, IBRS, no TSX)
stepping : 4
microcode : 0x1
cpu MHz : 2099.984
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat pku ospke md_clear
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data retbleed gds bhi
bogomips : 4199.96
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 1
...
cat /proc/cpuinfo # CAX11 / ARM (Ampere)
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1
processor : 1
...
In beiden virtuellen Maschinen habe ich mit wget
Geekbench heruntergeladen, mit tar xzf
ausgepackt und dann dreimal ausgeführt. Die Ergebnisse:
CX11 / x86 / Alma Linux 9
Single Multi Core
------ -----------
698 1203
692 1207
642 1205
--------------------------
CAX11 / ARM / Alma Linux 9
Single Multi Core
------ -----------
1082 1979
1084 1982
1079 1965
Zuletzt wollte ich noch wissen, ob Alma Linux 10 bei gleicher Hardware mehr Speed liefert (schnellerer Kernel, bessere Optimierung/Kompilierung der Programme etc.). Diese Tests habe ich nur auf der ARM-Instanz durchgeführt.
CAX11 / ARM / Alma Linux 10
Single Multi Core
------ -----------
1078 1971
1069 1963
1077 1974
Zusammenfassung: Bei meinen Tests boten die CAX11-Instanzen bei gleichen Kosten fast 50% mehr Leistung. Alma Linux 9 versus 10 ergibt dagegen keinen messbaren Unterschied.
PS: Geekbench ist noch nicht im IPv6-Zeitalter angekommen. Ist ja auch wirklich eine ganz neue Technologie … Wenn Sie selbst Tests durchführen wollen, müssen Sie die Instanz mit einer IPv4-Adresse konfigurieren. Weder gelingt der Download (das lässt sich umgehen), noch kann ./geekbench6
danach die Ergebnisse hochladen.
Bitte überbewerten Sie die Ergebnisse nicht! Die Hetzner-Cloud-Seite gibt keinerlei Informationen darüber, auf welchem Server bzw. auf welcher CPU Ihre virtuellen Maschinen laufen werden. Hetzner hat mehrere Rechenzentren mit unzähligen Server, mit Glück oder Pech landet Ihre virtuelle Maschine auf einem anderen, besser oder schlechter ausgestatteten Server. Das hier präsentierte Ergebnis ist nur eine Momentaufnahme, kein professionell über Wochen durchgeführter Test!
Es erscheint mir unwahrscheinlich, dass zum Testzeitpunkt (Sonntag nachmittag) die Cloud-Server besonders stark ausgelastet waren, aber es ist natürlich denkbar, dass das Ergebnis durch die Aktivität anderer virtueller Maschinen beeinflusst wurde.
Geekbench ist definitiv nicht das Maß der Dinge für Server-Benchmarks. Aber Geekbench lässt sich leicht installieren und ausführen, außerdem sind die Ergebnisse mit Desktop-Hardware vergleichbar. Sagen wir so: Um die CPU-Performance zu vergleichen, sind die Tests aus meiner Sicht gut genug.
Zu guter Letzt habe ich ausschließlich die billigsten Cloud-Angebote verglichen (die bei meinen Anwendungen aber oft ausreichen). Es gibt viele weitere Varianten, z.B. »CPX11« (2 AMD-Cores, nur 2 GB RAM, 40 GB Disk).
Kurz und gut: Dieser Test besagt NICHT, dass ARM immer mehr Leistung als x86 bietet. Zum Zeitpunkt meiner Tests und bei den von mir gewählten Randbedingungen erscheint es aber so, also würden Sie bei preisgünstige Cloud-Instanzen mit ARM-CPUs aktuell mehr Leistung bekommen als bei Instanzen zum gleichen Preis mit x86-Hardware.
Die AlmaLinux OS Foundation hat die allgemeine Verfügbarkeit von AlmaLinux OS 10.0 mit dem Codenamen Purple Lion bekannt gegeben.