Forum

Bonjour
je viens de faire les MaJ 6.1 => 7.1 en utilisant l'usb réseau, vu que j'ai lu que la 6 n'était plus suivie à partir de la fin du mois.

Sur le portable, j'ai choisi des installation "propres" en reformatant les partitions / des deux DD (j'ai deux Mga, une sur chaque disque), pas de pb à part un erreur où j'ai formaté le /home aussi, une histoire embrouillée où je ne sais plus ce que j'ai fait exactement, j'étais trop confiant vu que ça c'était bien déroulé pour l'autre DD. En général, quand ça plante, c'est qu'on fait des erreurs, donc il faut rester vigilant

Sur le PC avec la même méthode usb réseau mais en réelle mise à jour ce coup ci, vu que je n'ai pas envie de tout réinstaller et reparamétrer (même en conservant des fichiers config c'est long et hasardeux), j'ai galéré avec l'usb UEFI au tout début avant de comprendre qu'il fallait choisir l'usb simple, car je n'ai pas de partition /boot/EFI

J'ai choisi un miroir ftp de Jussieu, mais à la fin avec les mises à jours récentes ça tournait en rond, voir image plus bas, j'ai bien cru que c'était foutu, mais vu que c'était un MaJ et que le reste était déjà configuré, j'ai tenté un reboot et ça passe. On verra à l'usage, pour l'instant j'ai quelques longueurs dans la séquence de boot. Ceci dit c'est un peu flippant. Il est étrange qu'il n'y ai pas une option pour passer à la suite de l'installe quand il y a des erreurs de ce genre. Donc, là c'était quand même un peu à la sauvage.


Du coup j'ai changé de miroir pour voir si des rpm manquants allait apparaître en MaJ complémentaire, mais rien pour l'instant.

Il me reste à tester quelques trucs, genre imprimante et scanner, ça devrait bien se passer.

Hier soir j'ai vu que la gestion des écrans multiples semblait plus fonctionnelle, mais en fait il y a un bug qui fait qu'en enlèvant le cable hdmi qui était relié à la TV, je ne pouvait plus récupérer le moniteur du portable. Auparavant ça rebasculait sur ce moniteur. J'ai eu beau alterner les Fn+écrans, l'affichage ne revenait pas. On verra à l'usage.

A part ça, pour l'instant, je n'ai pas vu beaucoup de différences, sinon que ça boot super rapidement finalement.

Super donc, j'ai des ordis fonctionnels, merci les développeurs !!!
Bruno

Édité par lcb1 Le 20/09/2019 à 20h51

merci pour ce retour

C'est la moindre des choses, j'ai oulbié de préciser que je tourne sous plasma
Dans l'ensemble, une différence sensible c'est la rapidité.

Je suppose que tu resteras sur Mga7 (et ne reviendrait pas à mga6), dans ce cas, je te propose :
urpme python2-urllib3-1.24.3-1.mga6.noarch
puis de nouveau :
urpmi python2-urllib3
urpmi --auto-update

Ok merci, mais l'urpme me dit que ce paquetage est inconnu.
Ce qui est étrange puisque je le trouve avec rpmdrake !
En tous cas je désinstalle ça et installe la nouvelle version comme tu le suggère


Il y avait d'autres paquetages qui faisaient problème avant celui-là, genre gdb-doc, le truc est surtout que ça empêchait la suite de l'install, ce qui est quand même un gros bug à mon avis.

Bonjour,
Ce serait bien d'avoir un rapport de bug de ces installations qui se passent mal. Selon la méthode employée, on peut retrouver l'historique, par exemple dans /root/drakx ou avec le journal pour les mises à jour en ligne de commande.

Ok, en voilà deux, le gdb-doc bloquait la suite, tout comme le python en question.

J'ai essayé de contourner le problème en relançant après annulation (à vrai dire je ne me souviens pas trop des séquences d'avertissement, à la fin on tripatouille comme on peut) , pour le gdb ça a fonctionné, pas pour le python, comme déjà expliqué.

C'était donc au moment des mises à jours finales

gdb_doc.txt

Python.txt

En essayant de désinstaller la version en conflit et installer l'autre version (comme conseillé par jybz) mais avec rpmdrake, j'ai eu ce message
Python_2.txt

Le pb vient de python versus python2

Pour continuer:

J'ai fait donc urpmi --auto_update qui a désinstallé quelques trucs et mis à jour pas mal d'autres trucs, pas de conflits

Deux questions :
1 ) Si l'auto-update a trouvé plein de paquetages à mettre à jour, pourquoi il n'y avait pas de maj via rpm drake ?
Ca veut dire que le rpm drake ne fonctionne pas, ou c'est à cause des conflits précédents ?

2) Il y a une liste impressionnante d'orphelins, des centaines , je les vire avec urpme --auto-ophans ou pas ? C'est safe ? A une époque on nous déconseillait de procéder à cette commande

Merci

Édité par lcb1 Le 21/09/2019 à 14h25

La différence entre rpmdrake et la mise à jour en ligne de commande est le fait que rpmdrake ne va regarder les nouveaux paquetages que dans les dépôts marqués "Mis-à-jour", à savoir Updates. Il n'actualise pas la liste de fichiers dans Core-Release par exemple.
Si tu ne veux pas d'embêtements, garde les orphelins, sauf si c'est une collection de mga6.
pour obtenir cette liste,

Ok super merci je pige, j'aurais du le savoir depuis le temps
Pour les orphans, c'est un mix, on verra j'ai la liste mais ça risque d'être trop long, à moins qu'il y ait une commande urpme pour virer uniquement les mga6 avec un grep kekchose
Bon week-end

Édité par lcb1 Le 21/09/2019 à 17h42

Si le problème de python2-urllib3 persiste, David me dit qu'il y a une mise à jour python2-urllib3-1.24.3-1.mga7.noarch dans les testings. Peut-être résoud-elle le pb.

Bonjour,



Quelque chose comme ça ( je n' ai pas testé) ?

Pour Python, c'est bon

Mic80 a oublié le kekchose en question

Non, le "ça" contient le lien vers https://www.mageialinux-online.org/forum/topic-26458+nettoyage-des-packages-mga6.php
@nic80 : il semble que les liens sur des mots courts passent souvent inaperçus. Perso, je les laisse explicites.