Le blog de Seb

PassionGNU/Linux, la passion du Libre...

https://download.tuxfamily.org/passionlinux/site/banner.png

Mar 02, 2020

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.

Feb 25, 2020

Upgrade vers Mageia 7 raté, j'en profite pour changer.

Comme je vous l'ai dit hier, le passage à la version 7 de Mageia a encore raté. je comprends le succès des rollings quand je vois que Mageia n'arrive pas à passer d'une version à une autre sans lacunes, entre elle et les Ubuntu avec le plein de PPA qui n'arrivent pas non plus, ça donne une pas si bonne image de ce qu'est la montée de version sur une fixed.

Un truc pouvant faire un semblant d'explication du ratage, est peut être dû à la personne ayant tenté avant moi. J'explique, il a vu dans sa barre des taches, l’icône des updates, au lieu qu'elle soit comme habituellement en rouge ou orange selon la gravité des updates, elle était bleu, il a cliqué, validé la demande et laissé faire, sauf qu'au milieu il y a eu un "message" qu'il n'a pas noté... D'où certainement la merde que j'ai eu avec URPMI et le passage en force avec DNF... Ce qui m'étonne c'est qu'il est sous GNOME et que je ne pensais pas que cette icône s'affichait dans cet environnement.

N'ayant pas plus d'affinité avec cette distribution et sa communauté francophone, j'ai proposé à la personne de changer. J'avais le choix entre openSUSE Leap, Debian 10, Ubuntu 18.04, j'ai aussitôt décliné l'openSUSE car la 15.2 va pas tarder à sortir --sa bêta est déjà -- et que j'ai pas envie de passer encore pour faire des sauts de versions, par contre j'ai vraiment hésité entre la Debian et la Ubuntu car chacune a ses plus et ses moins.

Le truc c'est que je suis sur Debian et donc si ça merde, je pourrais le savoir bien plus vite et colmater, donc va pour Debian. J'ai donc utilisé la deuxième machine (un portable) de la personne qui elle était resté sous Mageia 6 --ayant vu la merde lors de son passage sur son PC desktop, il n'a pas tenté le diable-- pour charger l'ISO netinstal de Debian 10 vu qu'il est fibré, ensuite j'ai lancé l'installation. Dans la foulée et à sa demande, j'ai fais de même avec le portable.

Feb 24, 2020

Mageia 6 en fin de cycle – le moment de mettre à niveau vers Mageia 7

Il me reste --malheureusement-- encore des PC sous Mageia dans mon entourage, des PC qui bien sur n'ont pas réussit à charger la nouvelle version par l’icône normalement faite pour l’occasion d'une nouvelle version.

Mageia 6 en fin de cycle – le moment de mettre à niveau vers Mageia 7 Publié le 2 décembre 2019 par Papoteur

Vous le savez, Mageia 7 est sortie cet été, suivie de peu par Mageia 7.1. C’est le moment de dire adieu à Mageia 6 car on ne publie plus aucune mise à jour y compris pour la sécurité.

Comme toujours, avant de procéder à une mise à niveau, pensez à sauvegarder vos données et tous vos documents. Vous avez plusieurs solutions pour installer Mageia 7.1 :

  • Réaliser une installation nouvelle soit par l’installation classique soit par un media « Live ». Dans ce cas vous conservez vos données dans la partition /home si cette dernière est installée dans une partition séparée, comme c’est généralement le cas — mais vérifiez-le ! La partition / (racine) sera formatée lors de l’installation.
  • Réaliser une mise à jour depuis la ligne de commande : suivre la procédure indiquée dans nos notes de version [1].
  • Réaliser une mise à jour à partir de l’applet de la barre des tâches. Cette option avait été désactivée jusqu’à une date récente car des conflits empêchaient que la mise à niveau se termine correctement, mais ceci a été résolu, et vous pouvez mettre à niveau directement votre système sous Mageia 6.

Quelle que soit la méthode que vous choisirez, il est vivement conseillé de procéder à cette mise à niveau car Mageia 6 n’est plus maintenue et ne reçoit plus de mises à jour de sécurité.

Sauf que voila, rien ne marche, le passage d'une version à une autre merde encore, c'est pas la première fois ni la dernière fois avec cette distribution. J'ai eu des soucis d'impossibilités de faire le passage avec URPMI, je suis donc tourné vers DNF qui lui à part gueuler, a bien voulu faire le taf. Au reboot, un écran noir sans aucune possibilité. À la limite, ça pourrait ressembler à la vidéo d'Adrien mais avec aucunes lignes.

Feb 13, 2020

Apt-RPM n'est pas Apt de Debian/Ubuntu.

Billet qui fait suite à cette vidéo et ses commentaires.

Je sais pas ce que vous en pensez mais moi ça m'étonne toujours autant quand on parle de Apt-RPM comme d'un projet vivace, juste parce que les distributions qui ont l'ignorance de l'utiliser fassent encore des mises-à-jour. En l’occurrence, les updates actuels après vérification ne sont que des recompilions pour inclure des libs ou un Gcc plus récents. En tout cas juste en allant voir les sources du paquet APT sur Pclinuxos, je vois ça dans le changelog:

%changelog
* Mon Feb 10 2020 tex - 0.5.15lorg3.95-14pclos2020
- rebuild against glibc 2.31

* Wed Jan 29 2020 tex - 0.5.15lorg3.95-13pclos2020
- rebuild against updates

* Thu Jan 24 2019 tex - 0.5.15lorg3.96-12pclos2019
- redirect security patch

* Wed Dec 06 2017 Zen Subz <techars21 at gmail dot com> - 0.5.15lorg3.96-11pclos2017
- Rebuild with gcc7

* Wed Apr 27 2016 bb <bb> 0.5.15lorg3.96-10pclos2016
- drop cpu optimization

* Mon Apr 18 2016 bb <bb> 0.5.15lorg3.96-9pclos2016
- rebuild for updates

* Fri Apr 17 2015 bb <bb> 0.5.15lorg3.95-8pclos2015
- use revert patches 210 & 220 from vine

* Thu Apr 16 2015 bb <bb> 0.5.15lorg3.95-7pclos2015
- drop grub from rpmpriorities since we are moving to grub2
- update to git 522

* Wed Nov 13 2013 pinoc <vogtpet at gmail.com>  0.5.15lorg3.95-6pclos2013
- add gcc-4.7 patch

* Mon Sep 26 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-5pclos2011
- Split out sources.list into separate rpm package

* Sun Aug 14 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-4pclos2011
- sources list for 64 bit
- rebuild against libreadline6

* Fri Jun 10 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-3pclos2011
- rework package so same name as old versions

Sans parler que le projet lui-même a comme dernière version stable une 0.5.15 datant de 2006, les distributions Altlinux et Pclinuxos se basent quand à elles sur la version testing de 2008... N'y a t'il pas eu de progrès et d'améliorations de RPM depuis? C'est un peu la même chose pour URPMI mais au moins lui est bien entretenue --du moins ils essayent--.

Dans ces deux distributions que sont PClinuxoc et Altlinux, il y a aussi le cas de Synaptic, c'est sûr que même sous Debian il n'évolue plus beaucoup, en même temps, on ne peut pas ajouter beaucoup plus à cette interface. Mais là où ça en devient drôle c'est sous les distributions RPM citées, on se retrouve avec une version 0.57.11 datant de 2005, oui vous ne rêvez pas, toutes les améliorations subies depuis 2005 jusqu'à nos jours ne sont pas inclues. Mais même pour RPM, il a eu de nombreuses améliorations et bien Synaptic sur ces distributions n'en profitera pas. Pour rappel, Synaptic sous Debian/Ubuntu en est à sa version 0.90.

%changelog
* Thu Feb 13 2020 tex - 0.57.11.1-4pclos2020
- add patch to 142 to try to fix crash

* Mon Feb 10 2020 tex - 0.57.11.1-3pclos2020
- rebuild against glibc 2.31
- add build req intltool

* Wed Jan 29 2020 tex - 0.57.11.1-2pclos2020
- rebuild against updates

* Sun Dec 17 2017 Zen Subz <techars21 at gmail dot com> - 0.57.11.1-1pclos2017
- Patch to fix the spelling error in rguserdialog.cc
- Updated build with source v0.57.11.1 from snapshot.debian.org

* Fri Dec 08 2017 Zen Subz <techars21 at gmail dot com> - 0.57.9-1pclos2017
- Updated build with source v0.57.9 from snapshot.debian.org
- Add -continue option to wget package download script
- Refresh patches with new ones

* Thu Dec 07 2017 Zen Subz <techars21 at gmail dot com> - 0.57.3-5pclos2017
- Replace gtk-go-up/gtk-info icons with more commonly available ones
- Use the original source from snapshot.debian.org

* Wed Dec 06 2017 Zen Subz <techars21 at gmail dot com> - 0.57.3-4pclos2017
- Add gcc-7 patch and fix FTBFS (#1424532) from Fedora
- Add patch from Alt Linux to fix null-history
- Add extra patches by Ratt Salad
- Add patch to fix icons on the main-window
- Updated build for PCLinuxOS with rebuilt libapt

* Thu Jan 19 2017 bb <bb> 0.57.3-3pclos2017
- revert gksu changes

Autant qu'en 2005/2006, je veux bien croire qu'on ne jouissait pas de gestionnaire de paquets --en ligne de commande ou pas du reste-- à la hauteur en RPM, face à un Apt, je pense notamment à URPMI, YUM; mais de nos jours, tout de même, il y a le pachyderme DNF, l'ancêtre toujours aussi hasbeen d'Urpmi, le rapide Zypper --et oui ça fait mal à beaucoup de monde, mais c'est bien openSUSE qui a le gestionnaire de paquets le plus rapide en RPM--, ... Bref, même si certains sont lents, au niveau des fonctionnalités, de la sécurité, ils sont bien au dessus de ce Apt-RPM.

Voila, si vous voulez exprimer votre point de vue, venez sur le forum.