• # Calimero !

    Posté par . En réponse au journal Comment acquérir un poil de barbe en plus : mettre à jour une vieille Archlinux. Évalué à 10. Dernière modification le 06 septembre 2022 à 21:10.

    L'auteur semble n'avoir vécu que la confrontation avec un paquet dont il n'avait pas la signature (à obtenir en mettant à jour archlinux-keyring comme mentionné).
    Pour que les lecteurs ne se laissent pas endoctriner ovinement par des théologies mal avisées du style suivant

    Réinstaller Arch, c'est être faible.

    Voilà quelques points croustillants que le lecteur peut tenter de reproduire en devoir à la maison (ou à défaut, en prod) :
    - mettre à jour d'abord pacman, parce que le passage récent à la compression zstd nécessite un pacman qui en connaît l'existence, on est sur de l'utilisateur qui essaie d'anticiper, en principe ça part d'une bonne idée
    - le "nouveau" pacman installé ne se lance donc pas, parce que pas la bonne version de la lib c++ n'est pas (encore) installée.
    - donc on ne peut pas réinstaller l'ancien package avec pacman -U, mais on peut encore contourner en le décompressant manuellement (commande à retrouver sous ce petit coup de stress) puis en l'installant manu militari avec sudo cp ./* /
    - pour une solution possible, voir le paragraphe suivant (autres solutions possibles laissées en exercice)

    Le top de ma connaissance, c'est quand le pacman de la machine lui-même ne reconnaît pas le format de son propre successeur compressé en zstd.
    - donc, avec un autre ordi à côté, farfouiller dans Arch Linux Archive, choper les URL des paquets intermédiaires de pacman, jusqu'à en retrouver une qui n'est pas encore en zstd mais qui connaît ce format. La marge est très faible tant la transition a été rapide.
    - et se retaper, pour chaque version de pacman candidate, la manip maintenant éprouvée de wget et sudo cp ./* /
    - et pour chaque version de pacman candidate, déterminer et se procurer par les mêmes opérations les bonnes versions de toutes les libs dont il dépend (lib c, libs c++, libarchive, sans doute d'autres oubliées depuis liées au chiffrement)
    - opérations qui vont immanquablement aboutir à un wget non fonctionnel parce que ses libs c++ à lui ne sont plus là (et wget n'est évidemment pas le seul outil non fonctionnel dans cette situation, plus rien ne tourne à part le bash du prompt actuel qu'il ne faut surtout pas fermer)
    - entre autres solutions qui impliquent de s'être sorti du mauvais pas précédent (créativité laissée en exercice), on peut filouter pour que le noyau garde en RAM plusieurs versions des libc c++ simultanément parce que dépendances d'un outil quelquonque qu'on s'arrange pour qu'il tourne, et ainsi parvenir à ne pas se tuer (wget & Cie) dans le pied pendant qu'on fait les 400 coups
    - à la suite de quoi on y arrive non sans avoir perdu la raison au passage (et pas que) et sans même s'être demandé si des fois il n'y aurait pas eu plus simple.

    Je pense que, arrivé à ce point ou bien avant, celui qui ne réinstalle pas s'est fait léser à la conception sur l'attribution des rations de bon sens. Notez que réparer son install en rebootant sur clé USB est ici apparenté à une réinstall parce que... ben on a éteint la machine, amour-propre ruiné, comme un funambule tombé de sa corde qui pendouille sur sa ficelle de sécurité.
    Ou bien, une fois la persévérance (/acharnement) couronnée de succès après une ou 2 nuits blanche l'écume aux lèvres, il réinstalle quand même parce que apprendre c'est (très) bien, mais à un moment il faut savoir (削除) arrêter une guerre (削除ここまで) limiter les conneries dans lesquelles on vit.