Rocky Linux 9 auf 10 anheben

Rocky Linux unterstützt derzeit nicht offiziell Upgrades auf neue Major-Versionen, und ELevate ist für Rocky Linux 9 bislang nicht verfügbar. Dieses Tutorial zeigt Schritt für Schritt die notwendigen Arbeiten, um ein System manuell von Rocky Linux 9 auf 10 anzuheben.

· 9 Minuten zu lesen
Rocky Linux 9 auf 10 anheben
🇬🇧
This article is also available in English.

Anders als RedHat Enterprise Linux, AlmaLinux OS und Oracle Linux unterstützt Rocky Linux bislang In-Place-Upgrades auf die nächsthöhere Major-Version nicht offiziell.

Den Ausweg bietet hier eigentlich das ELevate-Projekt von AlmaLinux, welches RedHats Leapp um Daten für das Major-Upgrade weiterer EL-Distributionen ergänzt. Leider ist bislang jedoch noch kein leapp-data-rocky-Paket für Rocky 9 verfügbar.

Ein manuelles Upgrade durchzuführen ist aufwändiger, aber alles andere als Hexenwerk, und sollte somit für einen fortgeschritten Systemadministrator kein Hindernis darstellen. Dieses Tutorial basiert auf meinen persönlichen Erfahrungen beim manuellen Upgrade zahlreicher Systeme von Rocky Linux 9.6 auf 10.0.

Mindestanforderungen

Instruction Set Architecture prüfen

So wie Rocky Linux 9 die ISA-Baseline für x86-Systeme von x86-64-v1 auf x86-64-v2 angehoben hat, hebt Rocky Linux 10 diese, wie sein Upstream-Pendant RedHat Enterprise Linux 10, auf x86-64-v3 an.

Unter den Intel-Prozessoren wird dies von den Desktop- und Server-Prozessoren ab der Haswell-Microarchitektur unterstützt – also Xeon E3/E5/E7 ab v3, Core i3/i5/i7 ab Serie 4xxx, Pentium ab G32xx/G33xx/G34xx und Celeron ab G18xx.
Intel-Mobilprozessoren unterstützen dieses ISA-Level ab der Gracemont-Mikroarchitektur.

Die Desktop- und Server-Prozessoren von AMD unterstützen dieses ISA-Level seit der Excavator-Mikroarchitektur, die Mobilprozessoren ab der Excavator+-Mikroarchitektur.

In virtuellen Maschinen ist sicherzustellen, dass alle für das Erreichen des jeweiligen ISA-Levels notwendigen Prozessor-Instruktionen/-Features in die VM weitergereicht werden, je nach Hypervisor entweder durch Auswahl des korrekten virtuellen Prozessormodells, das Weiterreichen des Modells der Host-CPU bzw. das manuelle Aktivieren der Features für den Gast, oder durch die Auswahl der richtigen Version des Gast-Betriebssystems.

Überprüfen lässt sich das aktuell verfügbare ISA-Level mit diesem praktischen awk-Script von Frank Cox:

#!/usr/bin/awk -f

BEGIN {
    while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
    if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
    if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
    if (level == 2 && /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3
    if (level == 3 && /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
    if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
    exit 1
}

Arbeitsspeicher prüfen

EL10 benötigt offiziell mindestens 2 GiB RAM. Aus Erfahrung sind diese jedoch nur während einer regulären, grafischen Installation notwendig, sowie für ein Upgrade mittels Leapp/ELevate.

Sowohl für das hier beschriebene manuelle Upgrade, als auch für den späteren Betrieb, reicht bei auch sonst moderaten Anforderungen der laufenden Dienste 1 GiB RAM normalerweise aus. Voraussetzung sollte sein, dass alle speicherintensiven Anwendungen bzw. Dienste für das Upgrade beendet/deaktiviert werden.

Festplattenplatz prüfen

Für das Upgrade muss ausreichend Speicherplatz auf den System-Dateisystemen bereitstehen. Wie hoch diese Anforderungen konkret sind, hängt natürlich stark von den installierten Software-Paketen ab.

Für einen aus einem Minimalsystem installierten Server ohne grafische Oberfläche sollten 5 GiB freier Speicher auf dem /-Dateisystem in den meisten Fällen ausreichen.
Ich habe auch einige einfache VMs mit unter 2 GiB ohne Vergrößerung geupgradet, allerdings Systeme ohne das mittlerweile riesige linux-firmware-Paket, da dieses für den Betrieb meiner VMs nicht benötigt wird.

Die Speicherplatz-Anforderungen an das /boot-Dateisystem sind bei EL10 gegenüber EL9 unverändert.
D.h. 1 GiB bei den Standardeinstellungen oder 512 MiB bei Verwendung von installonly_limit=3 sind absolut ausreichend. Bei UEFI-Systemen haben sich auch die Anforderungen an /boot/efi nicht geändert.

Dateisystem-Typen prüfen

Die für lokale Dateisysteme offiziell unterstützten Typen sind bei EL10 weiterhin XFS und ext4.

Kommen andere lokale Dateisysteme zum Einsatz, muss die Kompatibilität geprüft werden. Nicht mehr unterstützte Dateisysteme müssen ggf. zuvor migriert, oder doch eine Neuinstallation in Betracht gezogen werden.
Für Dateisysteme, die vorhanden, jedoch nicht offiziell unterstützt werden (bspw. btrfs), kann je nach Anforderung an das System auch ein Betrieb ohne offizielle Unterstützung in Erwägung gezogen werden.

Vorbereitungsarbeiten

Backup/Snapshot anlegen

Da es sich um ein nicht offiziell unterstütztes Vorgehen handelt, ist ein vollständiges Backup des Systems und/oder Snapshot der Maschine besonders wichtig, um im Notfall zum Ausgangszustand zurückkehren zu können.

Dienste ggf. deaktivieren

Auch kann es empfehlenswert sein, Dienste, auf welche Dritte zugreifen, während des Upgrades zu deaktivieren und erst nach dem Upgrade wieder zu aktivieren.
Dies ist insbesondere dann sinnvoll, falls über diese Dienste Datenänderungen vorgenommen werden können, welche bei der Rückkehr zu einem Snapshot bzw. Restore eines Backups mit zurückgesetzt würden.

$ systemctl disable --now <...>

Rocky 9 auf den aktuellen Stand bringen

Zunächst wird sichergestellt, dass Rocky 9 aktuell ist. Falls wichige Systemupdates wie bspw. kernel, systemd oder glibc eingespielt werden mussten, ist in jedem Fall das System neuzustarten.

$ dnf upgrade --refresh
[...]

$ reboot

Rocky-10-Release installieren

Die Release-, Repo- und GPG-Key-Pakete von Rocky 10 müssen wir herunterladen und lokal installieren. Eine Installation zumindest des GPG-Key-Pakets direkt aus dem Repo ist nicht möglich, da die Pakete mit den GPG-Keys von Rocky 10 signiert sind, welcher uns ohne dieses Paket noch fehlt.

$ dnf download --releasever=10 rocky-{release,repos,gpg-keys}
[...]

$ dnf install rocky-{release,repos,gpg-keys}-10.*.el10.noarch.rpm

Sofern die .repo-Dateien in /etc/yum.repos.d/ verändert wurden (bspw. durch Aktivierung des CRB-Repositorys), werden diese bei der oben beschriebenen Aktualisierung von rocky-repos als .repo.rpmnew-Dateien angelegt (Meldung bei o.g. dnf install untersuchen!) und müssen noch behandelt werden.

Am einfachsten geschieht dies interaktiv mittels rpmconf aus EPEL:

$ rpmconf -o rocky-repos
[...]

Alternativ kann dies aber auch manuell durch Untersuchen der Unterschiede und Umbenennen der .repo.rpmnew-Dateien erfolgen:

$ diff /etc/yum.repos.d/rocky.repo.rpmnew /etc/yum.repos.d/rocky.repo
[...]

$ mv /etc/yum.repos.d/rocky.repo.rpmnew /etc/yum.repos.d/rocky.repo

Umgang mit Drittanbieter-Repositorys

Falls bei der o.s. Installation des neuen Rocky-Releases Drittanbieter-Repositorys kollidieren (bspw. remi-release), können diese entweder für das Upgrade entfernt und anschließend wieder installiert werden, oder sie werden mit aktualisiert (Remi für EL10: https://rpms.remirepo.net/enterprise/remi-release-10.rpm), was aber zu weiteren Problemen führen kann (bspw. Verwendung der Variable $releasever_major in den .repo-Dateien, die während des Upgrades auf $releasever geändert werden müsste).

Andere Repositorys wie epel-release sollten deinstalliert werden, und können nach dem Upgrade wieder installiert werden. Ebenso kollidierende Pakete.

$ dnf remove epel-release
[...]

Ungetrackte Artefakte entfernen

Falls vorhanden, müssen kollidierende und womöglich vom Paketmanagement nicht getrackte Dateien und Verzeichnisse entfernt werden.

Ein typischer Kandidat für derartige Artefakte soll /usr/share/redhat-logos/ sein:

$ rm -Rf /usr/share/redhat-logos/

Dies war bei meinen Systemen jedoch nicht notwendig.

Upgrade durchführen

DNF bereinigen und Distro-Sync starten

Zunächst sollte der DNF-Cache vollständig gelöscht werden (Repository-Daten, Pakete etc.), und anschließend wird das eigentliche Distro-Upgrade ausgeführt.

Beim Distro-Upgrade erlauben wir das Entfernen von Paketen aus Abhängigkeitsgründen, deaktivieren aber das Entfernen von vermeintlich nicht mehr benötigten Paketen.

DeltaRPMs werden ebenfalls deaktiviert, sofern aktiv, da sie über Major-Versionen hinweg nicht angeboten werden. Die Einsparungen dadurch haben sich ohnehin in den meisten Fällen als vernachlässigbar erwiesen, sodass verschiedene Distributionen sie wieder abgeschafft haben.

$ dnf clean all
[...]

$ dnf distro-sync --releasever=10 --allowerasing --noautoremove --setopt=deltarpm=false
[...]

Dabei sollten alle wegen Abhängigkeiten entfernte Pakete dokumentiert werden (Sektion Removing dependent packages), damit diese bei Bedarf später wieder installiert werden können.
Die meisten davon stammen i.d.R. aus den zuvor deaktivierten Drittanbieter-Repositorys und müssen aus Abhängigkeitsgründen vorübergehend entfernt werden, da sie dadurch nicht mehr automatisch auf die jeweilige EL10-Version angehoben werden können.

Ebenfalls sind auch eventuell nicht erfüllte Abhängigkeiten oder Dateikonflikte aufzulösen.

KDump ggf. deaktivieren

Ist KDump unter EL9 installiert aber nicht aktiv, aktiviert EL10 dieses ggf. automatisch wieder mit jeder Installation eines neuen Kernels.

Ist dies nicht gewünscht, muss in /etc/kdump.conf der Parameter auto_reset_crashkernel auf no gesetzt und anschließend Grub neu konfiguriert werden:

$ nano /etc/kdump.conf
[...]

$ grubby --update-kernel=ALL --remove-args='crashkernel=2G-64G:256M,64G-:512M'
[...]

Legacy-Netzwerkkonfiguration konvertieren

Konnte NetworkManager unter EL9 dank des Moduls ifcfg-rh die ifcfg-Dateien der veralteten network-scripts noch lesen, werden diese von EL10 jedoch nicht mehr unterstützt.

Falls noch aktive Netzwerkkonfigurationen in /etc/sysconfig/network-scripts/ vorhanden sind, müssen diese in .nmconnection-Dateien zu konvertiert und in /etc/NetworkManager/system-connections/ abgelegt werden.

Als einfache Vorlage hier ein Beispiel für das Interface eth0 mit statischer IPv4- und dynamischer IPv6-Konfiguration, zu speichern in einer Datei eth0.nmconnection:

[connection]
id=eth0
interface-name=eth0
type=ethernet
autoconnect=true

[ipv4]
method=manual
address1=10.0.0.11/24
gateway=10.20.0.1
dns=10.0.0.53;10.0.0.1
#dns-search=schoen-technisch.de

[ipv6]
method=auto
addr-gen-mode=eui64

Alle .nmconnection-Dateien müssen mit den Dateirechten 0600 versehen werden, sonst ignoriert NetworkManager diese, unabhängig davon, ob sie bspw. Zugangsdaten enthalten oder nicht:

$ chmod 0600 /etc/NetworkManager/system-connections/eth0.nmconnection

Bei Bedarf initramfs für neuen Kernel erzeugen

War eine Legacy-Netzwerkkonfiguration wie oben beschrieben vorhanden und diese auch Teil des initramfs, wurde dieses für den neuen Kernel wegen Nichtverfügbarkeit des Dracut-Moduls network-legacy u.U. nicht erzeugt, sodass das System mit dem neuen EL10-Kernel nicht bootfähig wäre (das Booten mit einem EL9-Kernel sollte für den Notfall jedoch weiterhin möglich sein).

In diesem Fall ist das initramfs für den neuen Kernel ohne network-legacy zu erzeugen.
Dieses Problem betraf bei mir insbesondere Systeme, die ursprünglich als EL7 (bspw. CentOS 7) oder älter installiert und immer wieder angehoben wurden.

Folgender Befehl erzeugt unter Deaktivierung von network-legacy alle fehlenden initramfs:

$ dracut --omit network-legacy --regenerate-all
[...]

Alle bereits vorhandenen initramfs bleiben unangetastet, da wir kein --force angegeben haben.

In Rocky 10 booten

Jetzt kann das System neugestartet werden.

$ reboot

Nach dem Neustart sollte uns Rocky 10 begrüßen.

Aufräumarbeiten

SELinux und RPM-Datenbank

Nach dem Upgrade muss im System noch aufgeräumt werden. Zuerst sollten die SELinux-Labels der Dateisysteme neu gesetzt und die RPM-Datenbank neu aufgebaut werden:

$ restorecon -R /

$ rpm --rebuilddb

Repositorys reaktivieren

Jetzt sind alle eventuell zuvor deaktivierten Repositorys wieder zu aktivieren/installieren (in diesem Fall CRB und EPEL), und anschließend ein dnf upgrade auszuführen, um auch die durch diese Repositorys bereitgestellten Pakete zu aktualisieren:

$ dnf config-manager --set-enabled crb
[...]

$ dnf install epel-release
[...]

$ dnf upgrade
[...]

Entfernte Pakete reinstallieren

Falls bei dem oben durchgeführten dnf distro-sync Pakete entfernt werden mussten, können diese nun wieder installiert werden:

$ dnf install <...>

DNF-Modules konvertieren

Sofern auf dem alten System Pakete aus dem AppStream über DNF-Modules installiert wurden, stehen diese Streams unter EL10 wahrscheinlich nicht mehr zur Verfügung. Diese werden diese nun beim Auflisten i.d.R. unter dem Label @modulefailsafe geführt:

$ dnf module list
[...]
@modulefailsafe
Name      Stream       Profiles                  Summary
mariadb   10.11 [e]    client, galera, server    MariaDB Module
[...]

Derartige Modules sind aus /etc/dnf/modules.d/ durch Löschen oder Umbenennen der zugehörigen Dateien zu entfernen und die enthaltenen Pakete neu zu installieren. Sofern EL10 die Pakete bereitstellt, können diese im Anschluss an das Entfernen des Modules diese auf ihr EL10-Pendant aktualisiert werden:

$ dnf upgrade
[...]
==========================================================================
 Package                Architecture  Version            Repository  Size
==========================================================================
Upgrading:
 mariadb                x86_64        3:10.11.11-1.el10  appstream   1.6 M
 mariadb-backup         x86_64        3:10.11.11-1.el10  appstream   6.6 M
 mariadb-common         noarch        3:10.11.11-1.el10  appstream    35 k
 mariadb-errmsg         noarch        3:10.11.11-1.el10  appstream   261 k
 mariadb-gssapi-server  x86_64        3:10.11.11-1.el10  appstream    16 k
 mariadb-server         x86_64        3:10.11.11-1.el10  appstream   9.9 M
 mariadb-server-utils   x86_64        3:10.11.11-1.el10  appstream   260 k
Installing weak dependencies:
 mariadb-client-utils   x86_64        3:10.11.11-1.el10  appstream    39 k

Transaction Summary
==========================================================================
Install  1 Package
Upgrade  7 Packages

Total download size: 19 M
Is this ok [y/N]:

Klappt dies nicht, sind die dem Modul zugehörigen Pakete mittels dnf remove zu deinstallieren und anschließend mittels dnf install aus dem regulären AppStream wieder zu installieren.

Veraltete Pakete und nicht erfüllte Abhängigkeiten

Nun sollte nach nicht erfüllten Paketabhängigkeiten sowie veralteten Paketen gesucht werden:

$ dnf repoquery --unsatisfied
[...]

$ dnf list obsoleted
[...]

Jetzt ist es Zeit, sich um alle sonstigen verbliebenen EL9-Paketen zu kümmern. Diese tragen auch bei Dritt-Repos i.d.R. ein el9 im Release-Teil des Versionsstrings, nach dem wir greppen können.

$ dnf list | grep 'el9'
[...]

Alle aufgelistete Pakete müssen geprüft werden, ob es sich um veraltete Pakete handelt, die dann noch entfernt oder ersetzt werden sollten.

Bei Paketen, die mehrfach installiert sein können (bspw. kernel- und kernel-*-Pakete), muss bei der Deinstallation die Version mit angegeben werden. Hier ist ggf. ist die Ausgabe von rpm -qa sinnvoller:

$ rpm -qa | grep 'el9' | grep '^kernel'
kernel-modules-core-5.14.0-570.23.1.el9_6.x86_64
kernel-core-5.14.0-570.23.1.el9_6.x86_64
kernel-modules-5.14.0-570.23.1.el9_6.x86_64
kernel-5.14.0-570.23.1.el9_6.x86_64
kernel-core-5.14.0-570.25.1.el9_6.x86_64
kernel-modules-core-5.14.0-570.25.1.el9_6.x86_64
kernel-modules-5.14.0-570.25.1.el9_6.x86_64
kernel-5.14.0-570.25.1.el9_6.x86_64

$ dnf remove kernel{,-core,-modules,-modules-core}-{5.14.0-570.23.1.el9_6,5.14.0-570.25.1.el9_6}.x86_64
[...]

Abschluss des Upgrades

Neustart und Fehlermeldungen prüfen

Nun wird noch ein letztes Mal das System neugestartet, um sicherzustellen, dass wirklich alles läuft:

$ reboot

Direkt danach untersuchen wir noch, ob der Kernel beim Systemstart Fehler (Priorität 3 und kritischer) geloggt hat, die behandelt werden sollten:

$ journalctl -p 3 -xb
[...]

Es kann auch nicht schaden, Warnmeldungen (Priorität 4) mit einzubeziehen.

Dienste reaktivieren

Zum Schluss reaktivieren und starten wir noch alle Dienste, die für das Upgrade ggf. deaktiviert wurden.

$ systemctl enable --now <...>

Läuft alles wie erwartet, kann die Maschine wieder in Betrieb gehen.