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.

Mögliche Migrationspfade für »Elevate« (Stand: Juni 2026, Bildquelle: https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html)

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Wenn Sie hier einen Kommentar absenden, erklären Sie sich mit der folgenden Datenschutzerklärung einverstanden.