
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.