Tuer le temps en mettant à jour Archlinux
Petite recette si vous vous ennuyez un samedi : comment casser puis réparer son système Archinux en seulement quelques étapes !
1. Ne pas mettre à jour assez fréquemment 
Il est plutôt conseillé de mettre à jour fréquemment son système (notamment pour des raisons de sécurité).
Mais quand on rencontre des déboires lors d’une mise à jour on laisse plus facilement traîner la prochaine par peur de tout casser et de devoir passer du temps à réparer.
C’est contre-productif puisque laisser trop de temps passer amplifie les chances d’avoir une mise à jour qui tourne mal.
2. Lire archlinux.org et voir que Pacman a changé un peu la structure des dépôts 📰
C’est une bonne chose de lire les dernières actualités qui y sont listées : ça permet de se tenir informé des changements les plus critiques. Et sont parfois répertoriées des actions manuelles à réaliser pour que tout se déroule au mieux.
Ici il s’agissait simplement de dépôts Pacman qui étaient renommés / fusionnés.
3. Penser que c’est une bonne idée de commencer par un pacman -Sy pacman 👨💻
C’est une commande qui permet de synchroniser les dépôts et de ne mettre à jour qu’un seul paquet (ici pacman), je voulais le faire pour éviter tout soucis avec le renommage des dépôts.
Jusque là je croyais que c’était une bonne pratique pour simplifier les grosses mises à jour en traitant certains paquets séparément.
Il s’avère que non (hors cas particulier tel archlinux-keyring), la mise à jour partielle n’étant pas supportée par Pacman.
4. Pacman est mis à jour mais dépend d’une lib crypto3 qui n’est pas installée, donc ne répond plus de rien 🤦
Et là, c’est le drame.
Le paquet pacman est bien mis à jour mais sa dépendance à openssl est restée inchangée. C’est pourtant la version 1 qui est installée sur le système et la version 3 qui est requise par Pacman.
En bref, Pacman n’est plus utilisable et ne permet alors pas de continuer la mise à jour.
Je n’explique pas précisément pourquoi la dépendance n’a pas été mise à jour, mais le problème aurait été bien plus embêtant si ça avait été le cas (la dépendance aurait alors été cassée pour tous les programmes qui l’utilisent, à l’exception de Pacman).
Peut-être s’agissait-il d’une dépendance indirecte (dépendance de curl dont dépend pacman) et que le système n’a pas jugé qu’elle devait être mise à jour puisque déjà installée.
5. Télécharger le paquet à la main, extraire le .so et tenter de le mettre à la main dans /usr/lib le temps de fixer 
S’agissant d’une lib manquante, je me dis que je peux patcher le système un peu salement le temps de procéder à la mise à jour.
Je n’aurais qu’à télécharger depuis un miroir la version 3 du paquet openssl, extraire le .so (bibliothèque dynamique) de libcrypto et le placer dans un répertoire système.
6. Se tromper lors de la copie, écraser la lib crypto1 
Erreur d’auto-complétion : je tape cp libcrypto.so.3 /usr/lib/libcrypto.so plutôt que cp libcrypto.so.3 /usr/lib/, ce qui a pour effet de copier mon fichier vers /usr/lib/libcrypto.so qui est un lien symbolique vers libcrypto.so.1 (la version 1 de la lib) et donc d’écraser ce fichier.
J’avais alors perdu toute référence à la version 1.
7. Télécharger le paquet de l’ancienne version, extraire le .so, le remettre en place 👷
Je recommence alors la même manip' avec le paquet openssl version 1.
J’ai eu la chance (parce que la lib était déjà chargée en mémoire j’imagine) que les outils utilisés pour télécharger le paquet ne cassent pas en raison d’une incompatibilité de version.
En tout cas après cela tout était revenu dans l’ordre, mon hack pour disposer de la version 3 toujours en place, il ne me restait plus qu’à mettre à jour.
8. Pacman répond de nouveau, tenter une mise à jour globale : erreur parce que crypto3 est déjà présent 
Et oui, Pacman refusait d’écraser un fichier existant. Je ne pouvais donc pas lancer la mise à jour en ayant ce fichier libcrypto.so.3 dans /usr/lib.
Mais je ne pouvais pas lancer Pacman si cette lib n’était pas trouvée.
9. Déplacer crypto3 dans un autre répertoire, ajuster LD_LIBRARY_PATH, lancer Pacman, ça fonctionne 🎉
Bien heureusement, les bibliothèques peuvent être placées dans d’autres répertoires, c’est même par là que j’aurais dû commencer.
La variable d’environnement LD_LIBRARY_PATH permet notamment d’ajouter un répertoire à la volée, bien pratique pour ce cas d’usage.
10. Redémarrer après la mise à jour système pour voir si tout est bon… ça ne boot plus 
Comme les bibliothèques restent présentes en mémoire, je préfère toujours redémarrer après une telle mise à jour pour m’assurer que tout va bien. Je ne voudrais pas redémarrer mon PC le lendemain ou plusieurs jours plus tard et me trouver face à une erreur dont j’aurais oublié tout le contexte.
J’ai eu raison de le faire ici puisque le système ne démarrait plus. Il s’arrêtait au tout début du démarrage, avant même de me demander le mot de passe de déchiffrement du disque.
11. Remarquer que le programme de démarrage ne trouve pas la lib crypto3 💡
La mise à jour contenait aussi une mise à jour du noyau Linux, qui nécessite de régénérer les images. Cela fonctionne avec un hook lors de la mise à jour qui permet que cette action de génération soit lancée à la fin.
Je me souviens avoir vu passer les logs de la génération dans la sortie de Pacman, mais je ne sais plus lors de quelle étape c’était (la mise à jour conflictuelle ou la suivante ?).
12. Booter sur un live usb, chroot sur le système, régénération des images avec mkinitcpio 🤞
Dans tous les cas, l’image était fautive et il me fallait tenter de la régénérer à nouveau. Comme je ne pouvais pas démarrer sur mon système, j’ai utilisé une live usb (un système démarrage par clé usb) qui traînait dans le coin.
J’ai alors pu me chroot (me positionner sur le disque comme si j’utilisais l’Archlinux installée sur l’ordinateur) dans les répertoires système et lancer la régénération à l’aide de la commande mkinitcpio.
Je pouvais alors redémarrer pour voir si cela avait corrigé le souci.
13. Ça marche 
Je n’étais pas très serein jusque là, j’avais peur que le problème soit plus profond et qu’une dépendance ait été cassée lors de mes péripéties.
Très content, je pouvais alors reprendre une activité normale.
S’il fallait retenir une chose, c’est de penser à faire des mises à jour régulières. Ça limite les conditions qui mènent à ce genre de problèmes, et surtout ça installe les patchs de sécurité qui pourraient exister pour les programmes installés.
L’image d’illustration est un montage entre le logo Archlinux et une planche de KC Green.
