Anmelden
Upgrade von Alma Linux 9 auf Version 10
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.
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.
Was ist LEAPP, was ist Elevate?
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.
Vorbereitungsarbeiten
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.
- High: veraltete Netzwerkkonfiguration in
/etc/sysconfig/network-scripts - High: unbekannte Systemdateien (»Aktoren«)
- High: unbekannte Pakete (
hc-utils) - Medium: Berkeley DB (libdb) ist installiert, wird in RHEL 10 nicht mehr unterstützt
- Low: unbekannten Paket-Repositories
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.
Migration der Netzwerkkonfiguration
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.
Das Upgrade
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
Anmerkungen und Einschränkungen
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.
Quellen/Links
- https://leapp.readthedocs.io/en/stable/
- https://almalinux.org/de/elevate/
- https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html
- https://wiki.almalinux.org/elevate/ELevate-NG-testing-guide.html#upgrading-almalinux-9-to-almalinux-10
- https://almalinux.org/blog/2025-04-01-elevate-updates/
- https://github.com/hetznercloud/hc-utils
Red Hat hat vorgeschlagen, dass Kunden, die über das bevorstehende Lebensende von CentOS 7 besorgt sind, möglicherweise über seinen Insights-Dienst auf Red Hat Enterprise Linux (RHEL) migrieren möchten. Der Support für CentOS Linux 7 endet am 30. Juni 2024. Eine Entscheidung, die Red Hat Ende 2020 getroffen hat. Jetzt ist die IBM-Tochter besorgt über das...
Linux-Betriebssysteme erfreuen sich seit langem großer Beliebtheit aufgrund ihrer Vielseitigkeit, Sicherheit und Open-Source-Natur. Innerhalb der Linux-Welt haben sich sogenannte LTS-Distributionen (Long-Term Support) als wichtige Säule etabliert. Diese Distributionen zeichnen sich durch langfristige Unterstützung und Stabilität aus, was in der schnelllebigen Welt der Technologie von großer Bedeutung ist. LTS-Distributionen: Grundlagen und Bedeutung LTS-Distributionen sind spezialisierte Varianten...
Wir sprechen über Red Hat und SUSE und die dazugehörigen Meldungen der letzten Tage und Wochen. Was die jüngsten Entscheidungen bedeuten und welche Reichweite das haben könnte. All das gibts im Podcast.
Im Hause Red Hat scheint man es nicht mehr so gerne zu sehen, dass alle binärkompatiblen Klone von der eigenen Arbeit kostenlos profitieren. Anders als bei CentOS Stream könnten sich Klone wie AlmaLinux oder RockyLinux künftig mit erschwerten Bedingungen konfrontiert sehen. Denn für CentOS Stream kündigen sich Änderungen an, die den Zugirff auf den RHEL-Quellcode...