Fedora Server : un upgrade de 34 à 36 qui se passe mal !
26 novembre 2022
Cette nuit, le service php-fpm de mon serveur Apache s’est à nouveau planté sans que je parvienne à en comprendre la raison dans les logs. Je me suis donc trouvé dans l’obligation de redémarrer mon serveur Fedora Server. Étant sur la version 34, j’en ai profité pour passer à la version 36 en deux étapes. Et, à l’occasion de la 1ère étape, c’est-à-dire du passage à la version 35, après avoir attendu plus de 30 minutes, j’ai dû passer ma Dedibox mode Rescue. Ce mode permet de se connecter via un accès SSH de secours aux unités de stockage de votre serveur, après les avoir montées manuellement :
mkdir /tmp/sda1 mkdir /tmp/sda2 sudo mount /dev/sda1 /tmp/sda1 sudo mount /dev/sda2 /tmp/sda2
Désactivation de plymouth
A l’aveugle et sans trop de conviction, je me suis dit que le souci pouvait venir de plymouth. J’ai donc choisi de le désactiver en modifiant les paramètres noyau définis dans le gestionnaire d’amorçage grub. Sur mon serveur, le système est présent sur la partition /dev/sda2. J’ai donc dû éditer le fichier /tmp/sda2/boot/grub2/grub.cfg :
sudo nano /tmp/sda2/boot/grub2/grub.cfg
Et, au niveau de la ligne set kernelopts, j’ai dû ajouter rd.plymouth=0 et plymouth.enable=0 :
set kernelopts="root=UUID=a95814a2-40af-4859-8537-3351e53bd749 ro fsck.mode=force nomodeset resume=UUID=20c6910f-2f3a-4264-a298-5e047c76e1fa biosdevname=0 net.ifnames=0 rhgb quiet selinux=0 rd.plymouth=0 plymouth.enable=0"
SELinux ou Firewalld ?
Du fait de la mise à jour, je me suis dit que le problème pouvait aussi se situer au niveau de SELinux. J’ai donc voulu vérifié et j’ai édité le fichier /tmp/sda2/etc/selinux/config :
sudo nano /tmp/sda2/etc/selinux/config
La directive SELINUX était bien désactivée :
SELINUX=disabled
Pour le pare-feu firewalld, j’ai juste renommé le fichier firewalld.service :
cd /tmp/sda2/usr/lib/systemd/system mv firewalld.service firewalld.service.old
Reboot
Après toutes ces modifications apportées, j’ai redémarré le serveur en tapant :
sudo reboot
Une fois redémarré, j’ai retrouvé l’accès SSH habituel. Et j’ai désinstallé les paquets plymouth, firewalld pour éviter qu’un incident du même type ne se reproduise.
dnf remove plymouth firewalld1