Seb's blog

Upgrade Mageia 7, explication pour les rageux.

Je n'aurai pas imaginé encore une fois que de parler de Mageia allait déclencher une guerre de religion, vraiment, c'est bien la seule distribution avec qui, si je critique, j'ai autant de soucis, d'insultes, de gars sans vie qui viennent me menacer et j'en passe... Je passe car les menaces, les insultes, c'est mon quotidien de conducteur de bus allant dans des zones à risques ou reconnues comme telles. En gros pour que ça m'en touche une en bougeant l'autre, faudra vraiment monter de niveau. Comme d'habitude, je garde tous les mails pour justifier une action par la suite en cas où, du reste pas très intelligent de se faire passer pour Mageia dans vos mails d'insultes.

Pourtant j'ai critiqué tout un tas de distributions, notamment Manjaro, Archlinux, Gentoo, Debian (et oui), openSUSE, Mint, Sabayon, Ubuntu... Et c'est avec l'unique Mageia que j'ai droit aux cas sociaux sans vie, n'ayant comme défouloir que leurs écrans. La masturbation serait une bonne manière de vous vider bande de petits puceaux...

Donc je vais revenir au pourquoi un énième billet sur cet upgrade de Mageia 6 vers la 7, c'est simple, Frédéric en a fait un billet (Le talon d’Achille des distributions GNU/Linux fixed release, les montées en version ?) et a démontré que lui ça passait bien. Deux choses qui peuvent l'expliquer, Fred le fait dans une machine virtuelle (virtualisation), on le sait dans le monde matériel, il peut se passer tout un tas de truc qui ne se passera jamais dans une virtualisation car dans cette dernière on idéalise un monde matériel parfait et bien reconnue, donc pas de soucis matériels, pas de pilotes Nvidia et autres joyeusetés qui peuvent ternir une installation. La deuxième chose et pas la moindre, il sort d'une installation sans aucune personnalisation, c'est une installation par défaut out-of-the-box comme diraient les américains, ça a son importance comme la possible installation de paquets moins populaires et donc moins testés, qui pourront foutre la merde dans une mise-à-jour et plus en cas de saut de version.

Si je reprends mon installation de Debian, j'ai environ + de 4000 paquets, j'ai deux environnements (ma femme est GNOME et moi KDE), j'ai de nombreux serveurs dont encore un mail, un FTP, un Web pour tester, en plus d'autres services qu'on pourrait assimiler à des serveurs comme MiniDLNA ou bien MPD. Bref, le tout c'est qu'il y a plus de 4000 raisons pour que ça merde alors qu'une installation de base en a dans les 1000-1500 paquets. Chez moi et chez les particuliers de mon entourage qui me font confiance et qui mon malheureusement décrété comme étant l'informaticien de la famille ou bien informaticien tout court --ce rôle ingrat qui oblige toujours de passer plusieurs heures pour réparer les conneries de personnes qui de toute façon ne feront pas l’effort de comprendre puisque la réparation est gratuite--, ça passe les doigts dans le nez sans faire le moindre effort, honnêtement je ne prends pas autant de soin que Fred dans sa vidéo, je fais du apt update && apt dist-upgrade après avoir changé les sources. J'ai par exemple en Janvier, fait un saut de version de Jessie vers Stretch puis Buster pour un portable d'un normand que je ne vois que rarement quand il redescend dans ma région, qui s'est totalement bien passé comme prévu.

Juste en aparté, encore une fois, je comprends son idée qui dit que les rollings seraient bien plus adaptées que des fixeds, mais on sera toujours en accord sur nos désaccords, en l’occurrence, au regard des personnes que j'ai en face de moi, c'est même pas la peine de penser mettre une rolling. En gros dans un monde parfait, oui Fred aurait probablement raison, quoique vu les merdes que j'ai du faire face avec des Windows 10, mais dans mon monde réel, j'ai deux types d'utilisateurs qui sont incompatibles avec ce genre de système. Le premier type d'utilisateurs qui ne représente même pas 10% est celui de ceux qui sont assez débrouillards, ils ne sont pas capable d'installer une distribution linux ou un Windows mais vont mettre à jour en suivant scrupuleusement les recommandations si la méthode est graphique et seulement dans ce cas là, ils ne sont pas capable --et ne veulent pas le faire-- d'installer un programme par eux même et ce même si la méthode est graphique. L'autre type d'utilisateurs que j'ai surtout affaire est celui des j'en foutistes, ils ne feront rien, jamais rien, on aura beau leur expliquer, leur donner des raisons de faire au moins les updates, mais non... Je peux les comprendre, certains ont eu des comportements malsains de leurs anciens OS à la fenêtre et non plus envie de s'exposer à des emmerdes. Je pourrais citer un troisième genre, un mixte entre les deux, que j'ai puisque c'est quelqu'un de très proche, qui fait les mises-à-jour qu'une fois par an. Alors, non, je ne me vois pas mettre des rollings ou même des semi-rollings dans mon entourage, car il y a une grosse part de risque que je prends pour me faciliter la vie: j'automatise au max les upgrades sans aucune intervention humaine et ça se passe très bien du moins sous Debian.

Si je prends une rolling ou une semi-rolling, je ne pense pas pouvoir le faire, du moins, je ne serai pas aussi tranquille. Je parle vraiment d'une méthode de mise-à-jour totalement automatisée et indépendante d'une quelconque personne, aucun besoin d'intervention humaine, c'est de A à Z totalement géré en sous couche et totalement invisible pour la personne. Le seul truc que j'ai demandé et que la personne doit faire, c'est qu'au moins une fois par semaine de laisser la machine fonctionner dans la nuit. J'ai mis en place une heure à laquelle le tout doit se faire, normalement à partir de 2h. Il me semble en avoir déjà parlé dans le billet "Il faut sauver le soldat Asus".

Maintenant, une fois que j'ai ciblé un peu l'histoire, on va pouvoir passer vraiment à la procédure que j'ai appliqué sur la dite machine. Il n'y a pas 500 possibilités, 2-3 tout au plus, une première avec le DVD (que je ne compte pas mais j’expliquerai plus tard), une autre avec le MGA-applet qui est la seule graphique, une avec l'historique Urpmi, une autre avec le DNF ajouté vite fait dans Mageia...

Vu que la personne ayant pour propriété la machine avec la Mageia dessus, avait fait la méthode totalement automatique et graphique du mga-applet, pardon mgaonline, a eu pour résultat une distribution non utilisable car plus accessible graphiquement (ça restait sur une session tty et pas d’accès à GDM), j'ai dû improviser. J'ai bien sûr remarqué que c'était dû à un upgrade qui s'est mal passé car on était dans un entre les deux, avec des paquets un peu des deux (de la 6 et de la 7), par la suite il m'a parlé d'un message d'erreur qui avait mit fin au saut de version qu'il n'a pas eu l'idée de poser sur papier ni de comprendre. J'avais le choix ensuite de prendre une méthode qui me plaisait un peu mieux, donc on peut retirer la façon DVD car et je cite:

En outre, il est possible que Mageia 6 ait reçu une mise à jour d’une version de logiciel plus récente que celle disponible sur l’ISO. Lorsque cela se produit, la mise à jour peut échouer. Comme il est impossible, au moment où les ISOs sont testées, de prévoir quels paquets de Mageia 6 peuvent être mis à jour dans l’avenir, les mises à niveau hors ligne (c’est-à-dire mises à niveau tentées sans configurer les dépôts en ligne) ne sont pas pris en charge.

Ce qui veut dire en langue simpliste, que si un paquet de Mageia 6 recevait une mise-à-jour après la sortie de l'ISO de la 7, ça pourrait alors ne pas réussir... J'ai rigolé la première en lisant ça car je ne voyais pas le rapport de cause en effet. Si le gestionnaire est bon, il peut très bien faire l'upgrade sinon ça voudrait dire que sur une distribution et plus encore une rolling, dès qu'on a oublié de faire une mise-à-jour et au vu des changements rapides qu'il peut avoir en une semaine (parfois un programme dans une rolling a plusieurs version d'affilé en une semaine), raterait les mises-à-jour suivantes de ce même paquets... Que dire, j'ai des Debian que je ne peux mettre à jour qu'une fois par an ou tous les deux ans et ça se passe très bien avec un saut de version en prime...

Il ne m'en reste que deux, celle qui était la même que pour une Mandriva, donc Urpmi et la nouvelle mit comme ça pour faire plaisir à ceux qui pensent que Mageia devrait être une clone de Fedora, DNF.

Oui je vais faire un aparté, je suis en train d'insinuer que DNF sous Mageia est mit comme ça sans être totalement fonctionnel, car c'est le cas, j'ai eu plusieurs fois affaire à lui et effectivement il arrive fréquemment que le bonhomme sous Mageia n'arrive pas à faire ce qu'on lui demande (généralement une simple mise à jour de logiciel) alors que Urpmi ne bronche pas et le fait sans fioritures. J'en ai parlé en décembre 2018 et mars 2019. Je disais notamment en 2018 ceci:

... un autre gestionnaire de paquets du nom de DNF, celui de Fedora, en fait Mageia se tend à devenir une Fedora bis en moins qualitatif... Gestionnaire de paquets qui donne des comportements étranges sur cette Mageia, qui échoue à certaine mise-à-jour alors que URPMI lui y arrive...

En 2019, toujours la même chose:

En terme d'application on est dans le correcte, ni trop ni assez, juste la bonne limite pour permettre de couvrir tous les besoins d'une utilisation standard. On pourra en rajouter facilement avec au choix --et je pense que c'est une erreur de garder les deux-- URPMI et DNF. Comme je le dis, c'est pour moi une partie qui blesse, je pense que ce n'est pas une solution de garder les deux, il faut faire un choix, soit on garde l’ancêtre qui fait de la résistance et qui a le mérite de toujours savoir se sortir des mauvais coups; soit on prend le challenger, le petit nouveau, mais d'une part, il apporte peu d'amélioration en terme de vitesse si ce n'est pire, d'autre part ses sorties je les trouve autant si ce n'est plus, incompréhensibles ou peu pratiques, et en dernier lieu, j'ai réussi à le mettre mal dans une simple opération de mise à jour, alors que URPMI, lui a réussi. C'est pas la première fois que j'arrive simplement à mettre à mal DNF, sur une Mageia 6 et une Fedora 28 puis 29, j'avais facilement réussi à lui rendre la vie impossible. Pourquoi Mageia s’entête à toujours reprendre ce que Fedora/Redhat fait, alors qu'il y avait bien mieux? Zypp et Zypper de chez openSUSE sont de vraies perles que ce soit en terme de vitesse ou de réussite, je n'ai jamais eu une simple mise-à-jour qui part en sucette ou qui échoue ou encore comme je l'ai vu sur Fedora 28 et Mageia 6, impossible à faire...

Fin de l'aparté, J'ai donc tenté avec Urpmi:

Désactiver dnf makecache (cette étape peut être omise si dnf n'est pas installé)

systemctl mask dnf-makecache.service --runtime --now
systemctl stop dnf-makecache.timer && systemctl mask dnf-makecache.timer && systemctl daemon-reload

Supprimer toutes les sources existantes des médias sur votre système en exécutant cette commande :

urpmi.removemedia -a

Ajoutez les sources en ligne de Mageia 7 :
En utilisant la méthode de LA LISTE DES MIROIRS (ce qui sélectionnera automatiquement un miroir en fonction de votre situation géographique):

urpmi.addmedia --distrib --mirrorlist 'http://mirrors.mageia.org/api/mageia.7.$ARCH.list'

(urpmi sait ce qu’il faut substituer à $ARCH)
Utiliser un miroir de médias spécifique

urpmi.addmedia --distrib <mirror_url>

Vous pouvez récupérer la variable mirror_url en utilisant l’application web des miroirs Mageia [1].
Enfin, commencer la mise à niveau :

urpmi --auto-update --auto --force

Il est préférable d’exécuter la commande ci-dessus deux fois, parce que certains paquetages peuvent être téléchargés sans être installés le premier coup.

Sauf que ça rate, il demande une librairie qui ne peut être installé, ce que je force mais non rien à foutre. Je me dis que perdu pour perdu on va essayer DNF:

  1. Assurez-vous d'avoir toutes les mises à jour de Mageia 6 dnf upgrade

  2. Installez le greffon dnf system-upgrade : dnf install 'dnf-command(system-upgrade)'

  3. Exécuter la phase de téléchargement : dnf system-upgrade --releasever 7 download --allowerasing

  4. Si la simulation et les mises à niveau proposées se présentent correctement, déclencher la mise à niveau : dnf system-upgrade reboot

En résultat, j'ai eu pratiquement la même chose que quand je suis arrivé pour rattraper l'upgrade mais en pire, plus d'écran, plus de ligne, plus de clavier, plus rien...

En conclusion, pour ne pas faire croire que les fixeds ne sont pas capable de monter de versions et pour finir sur une note plus intelligente que "l'autre fait son neuneu en utilisant des commandes qui ne sont pas officielles", je dirais simplement que tout est sanguin, on l'a dans le sang ou pas, c'est acquis ou non depuis sa création, il y a les distributions pensées dès le début pour passer de version en version et les autres qui se sont mises à le faire plus tard, sans jamais vraiment être autre chose qu'un coup de chance quand ça réussit (Mandriva, Mageia)... Depuis la Ubuntu 6.06 jusqu'à la version 18.04, je n'ai eu que deux soucis qui m'ont forcé à réinstaller, une fois avec le passage de 10.04 vers 12.04 et l'autre de 12.04 vers 14.04 (problème de pilotes qui m'ont intégralement tout bloqué). Avec Debian, depuis la Etch (version 4) je dois noter qu'un seul soucis, quoique j'ai réinstallé pour faire un truc plus propre mais sinon ça marchait bien, qui était dû au passage de Upstart à Systemd lors du changement de la Debian Wheezy (7) à Jessie (8). Je ne dirai pas que les distributions fixeds sont de la merde dans ce genre de sauts, ni que ce soit leurs talons d’Achille mais que ça dépend du sérieux de la dite distribution et de son pedigree.

Commencer la discussion: Venez écrire un commentaire dans le forum