Forum

Reprise du message précédent

merci pour la réponse, mais j'ai enlevé les deux dossiers qui posaient problèmes du disque dur;
donc, je n'ai plus le journal rempli de message de gnome-tracker sur la mageia sur le ssd;
et il n'y en a jamais eu sur la mageia7 sur sda3!
néanmoins, le noyau 5.6.x ne marche pas, ni sur mageia, ni sur fedora, ni sur opensuse!
et je n'ai pas lancé la mise à jour de la mageia7 sur sda3 cette nuit, car en fait, actuellement, sur les 5 partitions systèmes que j'ai (3 mageia, 1 fedora et 1 suse) c'est la seule qui soit saine!
et j'ai peur que, bien qu'elle soit meilleure que les deux autres, qu'elle succombe aussi à cette nouvelle série de noyau 5.6.x;
entre autre différence notable entre les deux (celle issue de la live béta2 sur sda3) et celles installées avec le dvd complet (sda1 et sdb4) c'est au niveau du numlock au login : sur celle sur sda3, ça marche, sur les deux autres il y a un problème: sur sdb4 c'est gdm (gnome pur) et aucune solution ne marche et sur sda1 c'est du sddm qui est dans les choux, il clignote, mais on réussi à se logger (LxQt ou IceWm only!)

donc, c'est pas les mêmes versions exactes de gnome et de gdm sur mageia7 que ça soit celle installée avec la live béta en mars 2019 et celle installée avec le dvd complet de la 7.1 téléchargé en décembre 2019!

autre indice :
cet ordinateur ayant perdu la carte graphique en juillet dernier, j'ai alors installée sur un HP pavillon de secours la mageia7 gnome live béta que j'avais sous la main;
elle a marché parfaitement jusqu'en octobre, où, la foudre m'a tout grillé : box, ligne internet, et l'ordi!
donc je suis revenu sur celui là, avec l'écran directement sur la carte mère.
entre autre, j'avais installé "codeblocks" sans problème et ça marchait très bien;
récemment, j'ai voulu me remettre à codeblocks, et bien l'installation sur mageia7.1 sur sdb4 a posé problème!
je soupçonne donc cette iso mageia7.1 d'avoir un problème!

Bonjour,

Si le 5.6 ne fonctionne pas avec les autres distributions également, je pense que le problème vient peut-être de là ?

Édité par Visiteur Le 15/05/2020 à 14h45

nos messages se sont croisés;
bon je suis bien sous wayland:
avant de faire la modif du fichier custom.conf, j'ai tenté de lancer une session xorg au login; c'est pire, car même avec le noyau 5.5.15, ça marche pas, ça fige et j'ai du faire un reset (pas de ttyx!)

voilà le résultat : session lancée avec le 5.5.15, sous wayland;
puis j'ai fermé la session pour passer en Xorg et plantage.

jb-2.txt

Bon je ne sais pas trop alors. Mais je vois quelques lignes étranges dans le journal

Tu dis que tu n'as plus de carte graphique mais je vois plein de lignes avec nouveau et quelques unes avec NVidia.
Encore là


J'ai deux erreurs ici que je ne comprends pas mais qui semble revenir souvent dans les journaux d'erreur de GNOME 3.32 que l'on trouve sur internet


Ici il semble y avoir un problème avec ton profil de couleur. Il faudrait que tu regardes le fichier désigné


Et là on perd tout


Difficile de dire ce qui provoque réellmeent le problème. Tes différents systèmes sont-ils tous indépendants ou partages-tu le /home ou le swap ?

Lorsque tu n'arrives pas à te logguer avec gdm (ou que ça frise), as tu essayé un startx dans tty3 ?

Je ne pense pas qu'il y ai de problème avec l'iso 7.1. Je n'ai recontré aucune erreur chez moi.

Bonjour,
Pour moi, il y a un gros problème de gestion de la carte par le pilote nouveau.

J'ai le même genre d'erreur sur une vieille carte NVIDIA qui n'a plus de pilote NVIDIA proprio. J'avais fait les rapports de bugs adéquats, sans que ça bouge. Le pilote nouveau n'est pas suffisamment à la hauteur.
Il aurait besoin vraiment d'un sérieux lifting, mais je ne sais pas par où prendre le problème.

Bonjour,

Je suppose que les lignes avec Nvidia, correspondent au support HDMI du chipset embarqué.

" HDA NVidia Front Mic as /devices/pci0000:00/0000:00:09.0/sound/card0/input9"

Il y'a également un chipset audio Realtek .

" snd_hda_codec_realtek hdaudioC0D0: ALC1200: SKU not ready".

Effectivement, les erreurs suivantes, comme l'indique Yuusha sont redondantes sur le net :

mai 15 09:56:42 ficus5 gnome-shell[1323]: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: No matching EGL configs
mai 15 09:56:42 ficus5 org.gnome.Shell.desktop[1323]: glamor: No eglstream capable devices found

A la lecture de beaucoup de posts, je pense que ton chipset graphique deviens un peu "juste" pour faire tourner Gnome sur Wayland.

Édité par Visiteur Le 15/05/2020 à 15h21

finalement j'ai osé la mise à jour sur sda3; ça a duré plus de 2h!
et ça marche!
[marcel@ficus4 ~]$ uname -a
Linux ficus4 5.6.8-desktop-1.mga7 #1 SMP Thu Apr 30 06:12:53 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

c'est une bonne nouvelle et inquiétante à la fois.
car ça me confirme dans le fait que l'iso 7.1 que j'ai utilisée pour installer est douteuse, car c'est une drôle de coïncidence que les deux bureaux gnome et plasma soit foireux tous les deux.

donc, j'ai plus confiance dans ces partitions;
en fait si je liste les problèmes (indépendament du celui du noyau) avec gnome
- pas de numlock au démarrage
- le magéia welcome ne s'affiche pas
- MSEC ne tourne pas non plus, j'ai été surpris de le voir tourner, comme toujours sur celle sur sda3
- problème de tracker qui m'a obligé de supprimer deux dossiers musique
4 problèmes inexistant sur sda3

que faire ?
- la solution avec fsarchiver me semble douteuse; j'ai déjà réussi un transfert d'une partition sur une autre sur le ssd, mais du hdd vers le ssd, ça a foiré;
- rester sur sda3 ? c'est le plus simple mais alors j'ai un ssd pour rien;
- réinstaller sur sdb4 avec la live béta 2 de l'année dernière et après me taper une énorme mise à jour?

je reviens là dessus, car je n'ai pas de réponse de ldlc concernant la carte graphique commandée, donc, comme c'est le pont, ça risque d'être pour plus tard;
pour l'instant, ça tourne avec la mageia7 sur sda3!
donc le noyau n'est pas seul en cause; ni même gnome, car celui là fonctionne bien;
par contre, les trois sur le ssd, aucune ne fonctionnent avec un noyau 5.6.x;
- l'opensuse est toute récente installée en janvier, la première installation il y avait un 5.5.x qui marche, et dès la première maj, avec un 5.6.x rien ne s'affiche;
- la fedora est ancienne, installée une 27 il y a plus de 2 ans, et elle a subit toute les montées de versions, elle est avec gnome sans extensions, et le 5.5.17 fonctionne et le 5.6.x est dans les choux;
- la mageia7.1, gnome installée fin décembre à partir du dvd, idem, le noyau 5.5.15 fonctionne et les 5.6.x (il y en a deux) ne fonctionne pas;
le point commun de celles qui ne marchent pas, c'est le ssd!
car elles ont toutes un bureau gnome, certes de version différentes.
est ce le ssd qui donnerait des signes de fatigue ? il n'est pas si vieux, je ne l'utilise que depuis janvier 2018!
mais alors pourquoi spécifiquement avec ces noyaux?

Salut,

Les nouveautés du 5.6 sont là :

https://kernelnewbies.org/Linux_5.6

https://www.phoronix.com/scan.php?page=news_item&px=2020-Linux-Kernel-SATA-Temps

Il y'a quelques apports avec le btrfs dans le premier lien, des améliorations du support hardware dans le second, pour une meilleure lecture des températures.

Une simple recherche Google et on voit qu'il y'a divers problèmes....

Édité par Visiteur Le 20/05/2020 à 12h21

salut
on pourrait continuer ici la conversation sur centOS et opensuse pour ne plus polluer le fil sur LO.

tu dis que chez opensuse leap, il y a une version tous les 12 mois, c'est ce que j'appelle courte vie; c'est guère plus long que fedora avec 9mois en moyenne;
au départ, j'avais installé une leap 42.3 sur une partition de 100 gio normalement prévues pour des datas; par simple curiosité de voir fonctionner le btrfs; celle là, je l'ai bien utilisée pendant quelques temps;
quand est sortie la 15.0, je l'ai donc installée sur le ssd sur 60 gio; mais je ne l'ai pas beaucoup utilisée;
entre temps cette machine a été délaissée au profit de la machine de secours;
quand je l'ai remise en marche en décembre, après 2 mois sans internet, j'ai d'abord mis à jour la mageia7 actuelle, les deux autres mageia étaient en 6, les mises à niveaux ont foirées les deux, donc j'ai du réinstaller; et la montée d'opensuse 15.0 -> 15.1 a foirée aussi, donc, j'ai décider d'essayer la tumbelweed ; la fedora était en 29, et les montées vers 30 et 31 ont été OK.
voilà jusqu'à présent, j'ai bricolé avec comme base arrière stable une mageia; mais actuellement, comme base arrière stable, je crois qu'il faut chercher autre chose, mageia devient un peu aventureuse!

Tu pourrais déjà vérifier ton disque avec

avec x la lettre de ton disque. Ou sinon tu peux utiliser l'outil Disques de GNOME. Si le disque est bon c'est que ce n'est pas ça.

Pour CentOS Stream je l'ai juste testé en VirtualBox mais je l'aime bien. Ça permet d'avoir un système stable mais un peu plus à jour. Cependant ça reste pour une utilisation professionnelle. Pour de la bureautique c'est un peu limité. Dans ce cas une Debian ou une Mint LTS serait peut-être plus utilisable. Si tu veux rester dans le monde des RPM c'est un peu plus compliqué. La seule distribution répondant au critère de ne pas monter de version trop souvent tout en étant pas non plus à la ramasse est Mageia. Sinon il faut aller chercher dans des distributions plus exotiques.

À la base Mageia est censé elle aussi avoir une nouvelle version tous les 12 à 18 mois. Mais le manque de main d’œuvre retarde un peu les choses. 18 mois c'est pas mal je trouve.

déjà, je n'ai pas cette commande "smartctl" et je ne sais pas quel paquet il faut installer;
par contre, gnome disque me dit que le disque est sain!

en fait, ce qui a fait que j'ai abandonné la debian, il y a deux raisons : elle cohabite mal dans un multiboot, à chaque changement de versions du noyaux, elle me mettait le bazar dans le grub; heureusement que j'ai deux MBR (un sur chaque disques) sinon ça aurait été ingérable! mais bon ça n'arrivais pas souvent;
mais ce qui a été déterminant, ce fut lors d'une mise à jour, que j'ai lancée trop vite après avoir booté, sans être allé lire les news chez debian .... il y avait une alerte en disant de ne surtout pas faire la mise à jour car il y avait une grosse faille de sécurité dans l'outil lui-même; m----e elle était déjà partie, et il m'a semblé que le coup n'était plus guère rattrapable;
sinon, elle marchait assez bien, et comme je l'avais d'abord installé en VM, ensuite quand celle en dur avait été OK, je m'étais amusé à passer celle en VM de stable en testing et l'opération avait été réussi, assez facilement:
je m'étais dis, peut être une bonne solution serait un double boot debian stable / testing, mais ça doit dépendre du moment, du degré de mâturation de la testing!

Il m'arrive d'être critique envers Mageia...Il faut le reconnaitre.
Pourtant, aujourd'hui, je te répond à partir d'une 7.1 Gnome, si il faut ouvrir des rapports de bug, je le fais, j'ai meme fait quelques paquets " à l'époque".
Mageia à un petit quelque chose qui fait que l'on reviens toujours la taquiner.
Aventureuse?
Je ne crois pas...Comme je te l'écrivais, le Kernel 5.6 a l'air de provoquer quelques problèmes. Le mainteneur l'applique car le 5.6 est référencé comme stable.
Je suis d'avis que les montées en versions nombreuses du noyau, ne facilite pas les choses pour les autres mainteneurs en cas de problème.
Le canal LTS me parais plus approprié, mais ça ce n'est que mon avis personnel.

Concernant la commande SMART, il te faut le paquet : smartmontools

https://madb.mageia.org/package/show/name/smartmontools/arch/x86_64

Concernant le multiboot, c'est rarement de tout repos.... Debian, soit c'est stable ou c'est testing...J'aime bien stable et la tranquilité d'esprit qu'elle apporte.

Concernant openSUSE, honnetement, les montées annuelles sont d'une tranquilité absolue...Tu as juste à coller ta clé usb, lancer la mise a jour, tu reviens après le diner, et hop c'est prêt !!

merci pour smartmontools
j'ai essayé "#smartctl -a /dev/sdb" mais ça affiche des tas d'informations que je ne sais pas interpréter;
dans le "man smartctl" j'ai trouvé celle là :
"#smartctl -q errorsonly -H -l selftest /dev/sdb"
qui ne dit rien ce qui est bon signe!

donc, ça exclu que les problèmes des distros sur le ssd vienne d'un soucis hardware du disque;

par ailleurs, dans les liens sur ce noyaux 5.6.x, j'ai vu qu'il y avait eu du changement dans le "trim" des ssd avec "btrfs"; mais il n'y a que la tumbleweed qui est sur btrfs, la fedora et la mageia sont sur ext4;

concernant les montées d'opensuse, j'en ai essayé qu'une seule, de 15.0 à 15.1 en ligne de commande avec "zypper" comme je fais avec la fedora avec "dnf", mais ça a foiré! ma machine ne boote pas sur les clé usb et donc je suis obligé de graver un dvd chaque fois que je dois réinstaller; donc les mises à niveau en ligne de commande c'est plus pratique.

remarque concernant le réseau :
j'ai téléchargé cette nuit une simple boot image de la centOS-8.1-1911 qui fait environ 600mio, il a fallut 13h de téléchargement!
si ça ne s'améliore pas, question débit, il va être impossible de faire une montée de fedora vers 32, ou de mettre à jour la tumbleweed (environ 1500 paquets), ça va mettre plusieurs jours!

Salut !!

Je n'ai jamais eu ce genre de problème chez openSUSE, un problème de dépots tiers?

Concernant le débit, je n'ai pas suivi, c'est un problème suite a mise a jour du noyau?

Après, il est quand même étrange que toutes les distributions installées sur ton système posent problème lorsqu'elles arrivent au noyau 5.6.

Édité par Visiteur Le 21/05/2020 à 12h20