Forum

Bonjour
la mise à jour de mageia6 testing pose problème, donc je ne l'ai pas faite;

En fait, c'était une histoire de médias mal configurés.
Il n'y avait pas les non free ni les tainted en testing;
je les ait mis, la mise à jour est passée, et ça fonctionne avec plasma, donc avec le kernel 4.14.43

Remarque en passant, MarcAndré.
Tu sembles avoir trois jeux de dépôts, il y en a certainement en trop.

Papoteur
"Tu sembles avoir trois jeux de dépôts, il y en a certainement en trop. "

oui, c'est comme ça depuis le tout début, le copain qui m'a installé mageia 5 à l'époque les avait tous mis, et ça fait bientôt 3 ans;
et avec mageia6 j'ai fait pareil;

lesquels éliminer, y a-t-il un choix à faire ou c'est indifférent ?

Bon avec mageia 6, dans les médias, il y a trois séries : ftp, http, et liste de miroirs
chez moi, tous étaient actifs;
j'ai supprimés les derniers, soit liste de miroirs, et j'ai lancé une mise à jour en console

un fait bizarre c'est passé : il a installé "kernel-userspace-headers 4.14.44 et supprimer le 4.14.43 !?
mais il n'y avait pas le kernel 4.14.44; j'ai pensé que ça sentait le moisi cette histoire!

donc, j'ai remis comme avant, la liste des miroirs, et relancé une mise à jour...
il n'y avait rien à faire !

là je me suis dit, c'est le moment ou jamais de m'intéresser à dnf!

le problème avec dnf, c'est qu'avec dnfdragora, on peut configurer les médias, je pense pour la transaction courante, mais quand on sort et qu'on vérifie en console avec "dnf repolist --all", il n'y a désespérément que core et update actif!
les modifications ne sont pas répercutées dans les fichiers de conf!

donc en cherchant un peu, j'ai découvert le dossier "/etc/yum.repos.d";
c'est là que se trouve les configuration;
j'ai donc modifier les fichiers suivants :
-mageia-x86_64.repo
-mageia-nonfree-x86_64.repo
-mageia-tainted-x86_64.repo
la modif est simple, pour les repos à activer, il faut repérer le booléen "enabled" qui est à 0 et le passer à 1;
sous vim en root;

une fois fait, j'ai lancé "dnf -distro-sync"
qui a bien repéré l'erreur et ma retrogradé le "kernel-userspace-headers" à la version 4.14.43, qui correspond au kernel;

maintenant que j'ai réussi à configurer les médias pour dnf, je crois que je vais abandonner "urpmi", qui sur ce coup, a failli me mettre dans les choux!
est ce lié à ma modification des médias faite avant ?
mais il ne m'a pas réparé l'affaire une fois que j'ai remis ceux que j'avais enlevé.

Cela prouve (malheureusement) que DNF n'est pas encore totalement prêt pour Mageia. Il faut déjà connaître l'astuce de /etc/yum.repos.d pour ensuite savoir quoi et comment modifier, ce qui n'est pas un automatisme. .... Bref, encore du boulot pour les développeurs

Edit :
Je viens de tenter de suivre tes explications. J'ai bien dit "tenter" car j'ai bien mes divers fichiers *repo mais quand je tente de les éditer (sous root) avec nano, ces fichiers sont vides. Je ne trouve donc pas la valeur booléenne.

Edit 2 :
Normal que mes fichiers *repo soient vides ! J'ouvre dnfdragora pour voir les dépôts et ...... Rien ! Que dalle ! Aucun dépoôt actif sauf ceux de Opera, Skype-satble et Vivaldi (dont leurs fichiers *repo respectifs sont vides).

Je n'ai, pour le moment, pas trop osé activé les dépôts Mageia de crainte de créer un problème. .... Je testerai en machine virtuelle avant samedi ou dimanche.

Édité par teutates Le 26/05/2018 à 00h59

Bonjour,

Lorsque j'avais testé DNF dans une Cauldron, il ne me semble pas avoir eu besoin d'éditer directement les fichiers dans /etc/yum.repos.d. j'avais trouvé une commande pour le faire. Je serai cependant incapable de vous dire laquelle.

Je pense que cette édition de fichiers n'est pas utile puisqu'il siffit d'aller dans dnfdragora pour activer (ou désactiver) les dépôts. Mais vu l'heure,n'ayant pas envie de devoir rattraper une bétise faite par fatigue, je préfère attendre après une bonne nuit de sommeil pour les activer.

Salut à tous

voilà une copie du début du fichier /etc/yum.repos.d/mageia-x86_64.repo, tel que trouvé par défaut;
le booléen "enabled" est facile a trouver, c'est le dernier de chaque paragraphe

 tournesol  /  etc  yum.repos.d  cat mageia-x86_64.repo
[mageia-x86_64]
name=Mageia $releasever - x86_64
#baseurl=https://mirrors.kernel.org/mageia/distrib/$releasever/x86_64/media/core/release/
#metalink=https://mirrors.mageia.org/metalink?distrib=mageia-$releasever&arch=x86_64§ion=core&repo=release
mirrorlist=https://www.mageia.org/mirrorlist/?release=$releasever&arch=x86_64§ion=core&repo=release
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia
failovermethod=priority
enabled=1

[updates-x86_64]
name=Mageia $releasever - x86_64 - Updates
#baseurl=https://mirrors.kernel.org/mageia/distrib/$releasever/x86_64/media/core/updates/
#metalink=https://mirrors.mageia.org/metalink?distrib=mageia-$releasever&arch=x86_64§ion=core&repo=updates
mirrorlist=https://www.mageia.org/mirrorlist/?release=$releasever&arch=x86_64§ion=core&repo=updates
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia
failovermethod=priority
enabled=1

[updates_testing-x86_64]
name=Mageia $releasever - x86_64 - Test Updates
#baseurl=https://mirrors.kernel.org/mageia/distrib/$releasever/x86_64/media/core/updates_testing/
#metalink=https://mirrors.mageia.org/metalink?distrib=mageia-$releasever&arch=x86_64§ion=core&repo=updates_testing
mirrorlist=https://www.mageia.org/mirrorlist/?release=$releasever&arch=x86_64§ion=core&repo=updates_testing
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia
failovermethod=priority
enabled=1

Bien sûr que avant de bidouiller en console, j'avais essayer avec dnfdragora, c'est probablement à cette occasion que les fichiers dans /etc/yum.repos.d ne sont pas vides chez moi;
en fait il y a tous ces fichiers obtenu avec "ll"

 tournesol  /  etc  yum.repos.d  ll
total 60
-rw-r--r-- 1 root root 4890 juil. 6 2017 mageia-i586.repo
-rw-r--r-- 1 root root 5160 juil. 6 2017 mageia-nonfree-i586.repo
-rw-r--r-- 1 root root 5260 mai 25 23:29 mageia-nonfree-x86_64.repo
-rw-r--r-- 1 root root 2657 juil. 6 2017 mageia-nonfree-x86_64-source.repo
-rw-r--r-- 1 root root 5160 juil. 6 2017 mageia-tainted-i586.repo
-rw-r--r-- 1 root root 5260 mai 25 23:32 mageia-tainted-x86_64.repo
-rw-r--r-- 1 root root 2657 juil. 6 2017 mageia-tainted-x86_64-source.repo
-rw-r--r-- 1 root root 4990 mai 25 23:33 mageia-x86_64.repo
-rw-r--r-- 1 root root 2537 juil. 6 2017 mageia-x86_64-source.repo

et dans chacun, il y a toute une série de dépots, qui commencent par un commentaire, et finissent par le booléen "enabled", qu'il suffit de passer a 1 pour activer le dépot de façon durable;

le problème constaté, c'est que si l'on configure "nonfree" ou "tainted" ou "update testing" dans dnfdragora, ça n'est pas écrit dans les fichiers, et donc, si on utilise en console "dnf distro-sync" pour la mise à jour, les bons médias ne sont pas configurés;

Yuusha
Lorsque j'avais testé DNF dans une Cauldron, il ne me semble pas avoir eu besoin d'éditer directement les fichiers dans /etc/yum.repos.d. j'avais trouvé une commande pour le faire. Je serai cependant incapable de vous dire laquelle.

la commande, c'est peut être un truc du genre
dnf config-manager --set-enabled blabla
dont le problème principal est de savoir le "blabla" qu'il faut mettre

pour moi, c'est plus facile de remplacer un 0 par un 1, que de savoir chercher le blabla à taper!

C'est bien gentil tout ça mais ça répond pas au problème de cette mise à jour foireuse d'hier, avec urpmi après avoir supprimé la troisième série, la liste de dépots;

reprenons:
Papoteur me dit que j'ai trop de dépôts configurés;
je supprime la dernière série, en laissant ftp et http;
je fais urpmi --auto-update et il se passe un truc foireux, avec ce "kernel-userspace-headers" 4.14.44 qui ne correspond pas au kernel 4.14.43
je remet, avec le CCM, comme avant et refait une mise à jour, rien ne se passe

et avec dnf, après configuration des médias en modifiant directement les fichiers de conf dans /etc/yum.repos.d, la commande "dnf distro-sync" m'a remis les choses en ordre; je suis actuellement avec;

la première des conclusion, c'est que dnf est plus puissant, il lui manque juste un peu de configuration; en fait, faudrait pouvoir avec dnfdragora écrire de façon permanente les choix fait pour configurer les médias; ou alors ça existe, mais j'ai pas vu comment!

Mais, dans cette histoire, je ne sais toujours pas quels médias "en trop" je dois supprimer pour continuer avec "urpmi";

et je ne sais pas si cette maj bizarre d'hier soir est liée ou pas avec le problème de configuration des médias!

On avance un peu
avec les médias redondants comme au début, je viens de faire "urpmi --auto-upadte" et le kernel 4.14.44 est passé au complet, soit 6 paquetages et 67mo;
je l'ai faite, j'ai rebooté et ça marche;

peut être hier soir, c'était juste un mauvais timing;

et cela m'a fait creuser un peu dnf, c'est très bien;

reste un conseil, pour supprimer les médias en trop, ou je laisse ainsi?

Bonjour,

A mon avis les medias surabondants sont sans conséquence hormis peut-être consommer un peu plus de bande passante.

Ok merci lebarhon, donc je n'y touche plus;
de toute façon ça marche comme ça depuis le début avec mageia5; si c'est juste une histoire de bande passante, c'est pas grave;

autre problème avec cette mageia6 en testing, le boot est long;
comme elle est sur le hdd, je me suis pas inquiété à prioiri que ce soit plus long qu'avec l'autre qui est sur le ssd;
mais tout de même, c'est un peu trop long;
effectivement, il y a un "A start job is running ...." qui se termine par
"Fail to start LSB : Bring Up / Down networking"
qui rallonge bien le démarrage;
sur l'autre, j'ai vérifié, ça ne se produit pas, et ça boote très vite!

je vais allé voir dans "journalctl" et j'essaie de le mettre;

Voilà me semble-t-il l'origine du problème de lenteur au démarrage trouvé dans "journalctl -b"
mais qui n'empêche pas le réseau de fonctionner;
toutefois, il y a une chose troublante, c'est l'heure; dans ce journal, ce n'est pas l'heure locale, qui devrait être 23 au lieu de 22

mai 26 22:55:24 localhost.localdomain network[1100]: Activation de l'interface enp0s15 : [ OK ]
mai 26 22:55:24 localhost.localdomain systemd-sysctl[2199]: Couldn't write '0' to 'net/bridge/bridge-nf-call-arptables', ignoring: No such file or directory
mai 26 22:55:24 localhost.localdomain systemd-sysctl[2199]: Couldn't write '0' to 'net/bridge/bridge-nf-call-ip6tables', ignoring: No such file or directory
mai 26 22:55:24 localhost.localdomain systemd-sysctl[2199]: Couldn't write '0' to 'net/bridge/bridge-nf-call-iptables', ignoring: No such file or directory
mai 26 22:55:24 localhost.localdomain systemd[1]: network.service: Control process exited, code=exited status=1
mai 26 22:55:24 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
mai 26 22:55:24 localhost.localdomain systemd[1]: network.service: Unit entered failed state.
mai 26 22:55:24 localhost.localdomain systemd[1]: network.service: Failed with result 'exit-code'.

Bonjour,

Tu as combien d'interfaces réseau ?
Network Manager est-il es service ?
Informations pertinentes avec
#journalctl -a -b -u network

https://forums.mageia.org/en/viewtopic.php?t=6459