Mettre à jour AlmaLinux 8 avec Elevate
Historiquement, Red Hat Enterprise Linux et les distributions dérivées comme CentOS ne pouvaient pas être mises à jour « à chaud ». Le passage à une prochaine version majeure nécessitait une réinstallation complète du système.
Le projet Elevate vient combler cette lacune et permet de passer d'une version
majeure de RHEL vers la prochaine, à la façon d'un dist-upgrade sous Debian.
Concrètement, c'est l'outil Leapp qui permet d'effectuer l'opération de
mise à jour sous le capot. Voici un petit schéma qui vous résume toutes les
possibilités de mises à jour au choix :
Non, je ne vais pas vous présenter tous les paradigmes de mise à jour dans toutes les permutations possibles. Au lieu de cela, je vais prendre un cas de figure bien concret pour une petite démonstration pratique : la mise à jour de AlmaLinux 8.10 vers la version 9.6.
Notez ici qu'en temps normal, je passe toujours par une réinstallation complète de mes serveurs pour une mise à jour. La mise à jour avec Elevate me sert avant tout pour pouvoir installer AlmaLinux 9.6 sur un serveur dédié chez Scaleway. À l'heure actuelle, les serveurs Dedibox sont proposés sous Rocky Linux 8.10 et Oracle Linux 9.10.
Bug chez Scaleway
Rocky Linux 9.6 figure certes dans le menu de l'installateur, mais le script d'installation de l'hébergeur semble comporter un bug. L'installation reste bloquée au démarrage du serveur. J'ai signalé le problème à l'équipe de Scaleway.
En attendant que le problème soit corrigé, je me sers de l'astuce suivante pour installer un serveur dédié :
-
Installer Rocky Linux 8.10.
-
Migrer à chaud vers AlmaLinux 8.10.
-
Mettre à jour AlmaLinux 8.10 vers la version 9.6.
12 juin 2026 : ça fonctionne !
L'équipe de Scaleway a réparé l'installateur de Rocky Linux 9.6. J'ai testé, ça fonctionne.
Dans mon pays natal, on appelle ça faire le tour de la croix avec l'église1. C'est vrai qu'à première vue la procédure paraît un peu compliquée. Dans la pratique, c'est beaucoup plus simple que ça n'en a l'air. Le temps de taper quelques commandes et de boire deux cafés, et c'est fait.
Pour commencer, je me connecte à ma Dedibox fraîchement installée et migrée vers AlmaLinux :
Les paquets du projet Elevate sont disponibles dans un dépôt tiers :
On va récupérer le paquet qui correspond à notre version (EL8) :
Voici les paquets fournis par ce dépôt :
# dnf --disablerepo=* --enablerepo=elevate list available
Available Packages
leapp.noarch 0.19.0-3.el8 elevate
leapp-data-almalinux.noarch 0.9-1.el8.20250505 elevate
leapp-data-centos.noarch 0.9-1.el8.20250505 elevate
leapp-data-rocky.noarch 0.9-1.el8.20250505 elevate
leapp-deps.noarch 0.19.0-3.el8 elevate
leapp-upgrade-el8toel9.noarch 1:0.22.0-3.el8.elevate.1 elevate
leapp-upgrade-el8toel9-deps.noarch 1:0.22.0-3.el8.elevate.1 elevate
python3-leapp.noarch 0.19.0-3.el8 elevate
snactor.noarch 0.19.0-3.el8 elevate
J'installe les deux paquets qui m'intéressent :
Je lance un premier test préliminaire qui va effectuer une longue série de vérifications :
# leapp preupgrade
==> Processing phase `configuration_phase`
====> * ipu_workflow_config
IPU workflow config actor
==> Processing phase `FactsCollection`
====> * system_facts
Provides data about many facts from system.
====> * vendor_repositories_mapping
Scan the vendor repository mapping files and provide the data to other
actors.
====> * check_enabled_vendor_repos
Create a list of vendors whose repositories are present on the system
and enabled.
====> * vendor_repo_signature_scanner
Produce VendorSignatures messages for the vendor signature files ...
====> * storage_scanner
Provides data about storage settings.
...
Dans l'état actuel des choses, la procédure de vérification m'affiche deux
problèmes qu'elle considère comme prohibitifs (Inhibitors) :
============================================================
REPORT OVERVIEW
============================================================
Upgrade has been inhibited due to the following problems:
1. Firewalld Configuration AllowZoneDrifting Is Unsupported
2. Possible problems with remote login using root account
HIGH and MEDIUM severity reports:
1. Detected custom leapp actors or files.
2. GRUB2 core will be automatically updated during the upgrade
3. Remote root logins globally allowed using password
Reports summary:
Errors: 0
Inhibitors: 2
HIGH severity reports: 3
MEDIUM severity reports: 0
LOW severity reports: 2
INFO severity reports: 1
Pour régler le premier problème, c'est très simple. Il suffit de rectifier la configuration de SSH :
Dans la section Authentication, commentez le paramètre
PermitRootLogin :
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
Prendre en compte la nouvelle configuration ?
Ce n'est même pas la peine de redémarrer sshd pour prendre en compte la
nouvelle configuration, étant donné que leapp preupgrade va juste
vérifier le contenu du fichier de configuration.
Travailler en tant que root
Note pour les chipoteurs : oui, je travaille en tant que root via
une connexion distante par mot de passe. La sécurisation d'une connexion
distante est une autre question. Dans le contexte actuel, vous n'allez pas
demander un badge d'accès à l'ouvrier qui est en train de refaire les murs
de votre immeuble.
Mon deuxième problème peut également être réglé de manière triviale :
Modifiez la dernière option à la fin du fichier comme ceci :
Je relance le test préliminaire :
La dernière intervention a réglé les deux problèmes susceptibles de bloquer la mise à jour :
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. Detected custom leapp actors or files.
2. GRUB2 core will be automatically updated during the upgrade
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 0
LOW severity reports: 3
INFO severity reports: 2
Je lance la mise à jour :
# leapp upgrade
...
==> Processing phase `InterimPreparation`
====> * efi_interim_fix
Adjust EFI boot entry for first reboot
====> * remove_upgrade_artifacts
Removes artifacts left over by previous leapp runs
====> * common_leapp_dracut_modules
Influences the generation of the initram disk
====> * add_arm_bootloader_workaround
Workaround for ARM Upgrades from RHEL8 to RHEL9.5 onwards
====> * upgrade_initramfs_generator
Creates the upgrade initramfs
...
Je vais me préparer un premier café en attendant que les messages défilent sur l'écran. Au bout de l'opération, les choses se présentent plutôt pas mal :
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.
Ne vous tirez pas dans le pied
Avant de redémarrer, pensez éventuellement à restaurer la configuration
initiale du serveur SSH dans sshd_config. Ça vous évitera de vous tirer
dans le pied si vous n'avez que le seul compte root sur la machine.
Je croise les doigts et je redémarre :
C'est un peu long
Ne vous inquiétez pas si la machine ne réapparaît pas tout de suite sur votre radar. Une partie significative de la mise à jour s'effectue lors d'une série de redémarrages successifs sous le capot. Le moment est donc bien choisi pour aller vous faire un deuxième café.
Au bout de l'opération, je me reconnecte à mon serveur flambant neuf :
Et la version 10 ?
Note finale pour les chipoteurs qui frétillent sur leur chaise : la mise à jour vers la version 10 comporte son propre lot de surprises et fera l'objet d'un article dédié en temps et en heure. Dites-vous que RHEL 9.x et les clones dérivés sont officiellement supportés jusqu'en 2032. Y'a pas le feu au lac.
-
Mit der Kirche ums Kreuz gehen. ↩