Montée de version majeure Linux

Mettre à jour sa version majeure de Linux, c'est possible !

Il est possible de procéder à la mise à jour d'un système RedHat® Enterprise Linux et apparentés (AlmaLinux, Rocky, Oracle Linux...) grâce à l'outil leapp.

Leap vous permet de faire la mise à jour d'une version 7 vers une version 8 et d'une version 8 vers une version 9 (le passage direct d'une 7 vers une 9 n'est pas possible en une seule mise à jour).

Cet article reprend les commandes utilisées ainsi que quelques captures d'écran de la vidéo disponible sur notre chaîne Youtube @LHQG-fr

Cette vidéo montre la montée de version d’une machine sous Rocky Linux 8 pour passer en version 9.

Préparation

Je me suis connecté à une machine Rocky 8 (installation de base) avec mon compte personnel. Et je deviens root pour la suite des opérations car les privilèges systèmes et le domaine SELinux non confiné (unconfined_t) seront nécessaires pour leapp. 

La première chose à faire, avant de commencer, est de vérifier que vous possédez bien la dernière version de votre système :

dnf upgrade

Parfait ! votre système est à jour. Si ce n’est pas le cas, faites-le !!!! et redémarrez votre machine si nécessaire.

Espace disque

Afin de vous faire gagner du temps, anticipons un problème que vous pourriez rencontrer et qui est lié à un manque d'espace disque disponible pour faire la mise à jour :

RedHat® publie un article très intéressant sur le sujet. Vous y retrouverez un script qui vous donnera approximativement la volumétrie à prévoir.

Leapp peut nécessiter beaucoup d’espace disque selon la taille de votre machine chaque cas étant particulier.

Pour éviter les problèmes futurs, nous allons lui allouer de l’espace disque. 

Ici, je vais utiliser un volume logique dédié afin de pouvoir récupérer cet espace par la suite. Mais ce n'est qu'une possibilité parmi tant d'autres. A vous de choisir la solution qui vous convient.

Je dispose d'un peu d'espace dans mon volume groupe principal, je vais donc m'en servir.

Voici la liste des commandes que j'ai utilisées ensuite :

lvcreate -n /dev/VG_SYS/var_lib_leapp -L5G VG_SYS
mkfs.xfs /dev/VG_SYS/var_lib_leapp
udevadm settle
echo "/dev/VG_SYS/var_lib_leapp /var/lib/leapp xfs defaults 0 0" >> /etc/fstab
systemctl daemon-reload
mkdir /var/lib/leapp
mount /var/lib/leapp

Référentiels utilisés

Dans la plus par des cas, leapp s'occupera de configurer les référentiels de paquets (repos yum) à utiliser pour la version cible.

Nous ne rentrerons pas ici dans le détail, mais si vous utilisez RedHat® Enterprise Linux et RedHat® Satellite, il y aura des étapes préparatoires obligatoires à faire sur les content views. 

Installation de leapp

L’étape suivante est spécifique pour les OS non RedHat® mais apparentés (Rocky Linux, AlmaLinux), elle permet d’obtenir des fichiers de migration spécifiques à la distribution utilisée :

dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

Installez ensuite leapp et le paquet spécifique à votre distribution (ce dernier n'étant pas nécessaire sur les RedHat® Enterprise Linux) :  

dnf install -y leapp-upgrade leapp-data-rocky

Le(s) pré-upgrade(s)

Pré-upgrade(s) de test

L'étape suivante consiste à lancer (au moins) une première vérification grâce à la commande :

leapp preupgrade

Une fois le pré-upgrade terminé, un rapport est généré. Dans le résumé, on peut voir qu’il remonte deux inhibiteurs empêchant de faire la mise à jour :

Le mieux est de commencer par consulter le contenu du fichier de rapport qui a été généré dans « /var/log/leapp/leapp-report.txt ». Celui-ci fournit des informations complémentaires et remonte aussi d’autres points qui peuvent être intéressants à connaître ou à corriger (matériel non supporté par la version cible...). 

Résolution des inhibiteurs

Il va donc falloir faire les corrections nécessaires.  

Dans l'image ci-dessus, le premier inhibiteur concerne un paramètre devenu obsolète dans la configuration de firewalld et le second, l'accès distant en ssh pour "root" qui est autorisé (c'est maaaaal !!!!).

Voici une proposition de résolution de ces inhibiteurs.

Pour firewalld, passer la valeur du paramètre "AllowZoneDrifting" à "no" soit en éditant le ficher soit grâce à la commande suivante :

sed -i "s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/" /etc/firewalld/firewalld.conf

Comme je dispose d'un compte personnel pour me connecter à la machine et que je n'ai pas besoin de la connexion root en ssh, je modifie le fichier sshd_config en passant la valeur de "PermitRootLogin" à "no" ou sinon via la commande :

sed -i "s/^PermitRootLogin yes.*/PermitRootLogin no/" /etc/ssh/sshd_config

Si vous souhaitez impérativement conserver la connexion en ssh via "root", il est indiqué d'ajouter un commentaire supplémentaire au niveau de la ligne pour que cela reste en place :

PermitRootLogin yes    #rootlogin is required        <<<<====== add a comment in same line then it gets allowed

D'autres points étaient remontés dans le rapport. Un problème avec un driver du noyau pour ip_set qui n'est plus supporté, de même pour un type de processeur... Dans mon cas, ces points ne sont pas pertinents, je les ignore donc mais soyez vigilants de votre côté.

Renouvelez l'opération pour vérifier que vos modifications ont résolu les inhibiteurs et les erreurs. Procédez par itération si nécessaire.

Pré-upgrade de contrôle

Une fois les modifications faites, relancez un dernier pré-upgrade :

leapp preupgrade

Vous ne devez plus avoir d'inhibiteurs ni d'erreurs.

Dans la capture ci-dessous, on constate qu'il n'y a plus de problèmes majeurs. Les autres points remontés (high, medium, low et info) correspondent à ceux que j'ai délibérément ignorés (mais par sécurité, vérifiez de votre côté). A nouveau, chaque cas est unique.

L'upgrade

Maintenant que le pré-upgrade est correct et que vous disposez d'une sauvegarde fiable de votre système, lancez la mise à jour à proprement parler : 

leapp upgrade

Cas particulier Rocky Linux

Sur une Rocky Linux, pendant l'upgrade, on peut rencontrer un conflit avec le paquet rocky-logos :

Si vous rencontrez le même problème, vous pouvez supprimer le paquet rocky-logos car il n'est pas critique. Dans tous les cas, vous pourrez le réinstaller manuellement après l'upgrade :

dnf remove -y rocky-logos

Relancez l'upgrade.

Déroulement de l'upgrade

L'upgrade devrait se terminer sans erreur et fournir un résultat comme celui ci-dessous (si ce n'est pas le cas, corrigez à nouveau les erreurs rencontrées et recommencez) :  

La première partie de l'upgrade est terminée et leapp demande de redémarrer la machine comme indiqué.

reboot

La machine redémarre et procède à la mise à jour de la distribution, ici Rocky 9. 

Après le dernier redémarrage, vous pouvez vérifier que votre machine a bien été mise à jour, comme indiqué ci-dessous :

Nettoyage après l'upgrade

Afin d'avoir un système le plus propre possible, nous allons procéder au nettoyage de la machine. 

Nettoyage des paquets

Lors de la mise à jour, leapp ajoute des exclusions dans la configuration de dnf. Les commandes ci-dessous vous indiquent comment les visualiser et les supprimer (vous pouvez aussi éditer manuellement le fichier /etc/dnf/dnf.conf) :

cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
exclude=leapp,leap-upgrade-el8toel9,python3-leapp,snactor

dnf config-manager --save --setopt exclude=''

L'étape suivante consiste à vérifier si des paquets d'une ancienne version (7 ou 8) sont encore présents sur votre système. La seconde commande vous permet de les supprimer : 

rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
    
dnf remove $(rpm -qa | grep \.el[78] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')

Le travail étant terminé avec leapp, vous pouvez supprimer les paquets qui lui sont liés :

dnf remove leapp-deps-el9 leapp-repository-deps-el9

Espace disque

Commencez par supprimer les répertoires utilisés par leapp :

rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leap/*

J'avais précédemment créé un volume logique pour héberger le /var/lib/leapp. L'upgrade étant terminé, je n'en ai plus besoin ; je vais donc le supprimer pour libérer cet espace :  

umount /var/lib/leapp/
lvremove /dev/VG_SYS/var_lib_leapp
rmdir /var/lib/leapp

J'édite ensuite le fichier /etc/fstab pour supprimer la ligne correspondante :

et je n'oublie pas la commande :

systemctl daemon-reload

Mise à jour du chargeur de noyau

Mettez à jour les arguments de de la ligne de commande du noyau utilisé afin de ne pas rencontrer de souci lors d'une prochaine mise à jour de celui-ci :

BOOT_OPTIONS="$(tr -s "$IFS" '\n' </proc/cmdline | grep -ve '^BOOT_IMAGE=' -e '^initrd=' | tr '\n' ' ')"
echo $BOOT_OPTIONS > /etc/kernel/cmdline

Supprimez ensuite le noyau de secours existant ainsi que l'initramfs correspondant :

rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*

Réinstallez le noyau de secours et l'initramfs associé pour disposer des bonnes versions :

/usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"

Pour confirmer que ces deux étapes se sont bien déroulées, lancez les commandes suivantes  :

ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*
lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"

Et pour terminer cette étape, vérifier que l'entrée dans le menu grub pour le noyau de secours est correcte :

grubby --info $(ls /boot/vmlinuz-*rescue*)

Réactivation de SELinux

N'oubliez pas que Leapp a mis SELinux en mode permissif et qu'il faut donc le remettre en mode enforcing.

En premier lieu, vérifiez qu'il n'y a pas d'erreurs SELinux remontées en utilisant la commande ausearch :

ausearch -m AVC,USER_AVC -ts boot

Sinon, faites le nécessaire pour qu'elles ne soient plus présentes (les erreurs liées à leapp peuvent-être ignorées).

Modifiez ensuite le fichier de configuration /etc/selinux/config pour remplacer la valeur permissive de la clé SELINUX= par enforcing.

Redémarrez alors votre système et lancer ensuite la commande getenforce qui doit vous renvoyer la valeur Enforcing : 

getenforce
    
Enforcing

Conclusion

Vous venez de réussir la mise à jour d'une version RedHat® 8 (ou apparentée) vers 9 (ici une Rocky Linux). Félicitations !!!

Chaque cas reste spécifique ; cette procédure n'a pas vocation à être exhaustive mais à vous donner les clés et étapes nécessaires pour faire la mise à jour.