Connexion

Forum

Système et matériels » Cartes graphiques et webcams [Réglé] problème d'affichage sur mageia 6 écran noir pendant plusieurs minutes, puis fenêtre inactif

nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 08/11/2018 à 07h48

Reprise du message précédent

Bonjour,

Au lieu de startgnome, je voulais indiqué startx ( cela pour essayer de contourner le problème de blocage de systemd-login qui est probablement à l' origine du freeze ( qui semble être causé par la disparition du clavier et de la souris).

Dans les logs du xorg.0 il est fait mention du noyau 4.14.78-server ( le fait d' avoir un noyau "serveur" est un choix volontaire ?) si l' on essaye de voir avec un noyau prédédent (desktop) si disponible ( afin de vérifier que la disparition n' est pas du à une version de noyau spécifique ), que se passe t' il ?

Citation :
Est-ce que je peux monter cette partition en supprimant tous les fichiers de configuration


Si le blocage apparait y compris sur un nouvel utilisateur crée, alors je ne pense pas que cela vienne des fichiers de configuration présents dans /home/user

Citation :
ou pris le même utilisateur pour /home lors de l'installation


Avec le même id que lors des installations précédentes ?


edit: Je viens de faire un test dans ma machine virtuelle, dés que j' ai sélectionné gdm en gestionnaire de connexion, j' ai perdu l' accès à mon clavier et ma souris virtuels, dés que j' ai sélectionné sddm en tant que gestionnaire de connexion ( ce qui a forcé le redémarrage du service dm), je les ai récupérés. Peut être faudrait il essayé de faire l' installation de sddm ( en plus de gdm et xdm) et faire un test avec celui ci ? Edité par nic80 Le 08/11/2018 à 08h18
   
rainer Membre non connecté

Rang

Avatar

Inscrit le : 13/11/2016 à 19h12

Messages: 74

Le 08/11/2018 à 19h38
Bonsoir,
Citation :
Avec le même id que lors des installations précédentes ?


Eh oui

J'ai désinstallé le noyau-server pour installer un noyau-desktop pour moins de 4GO de ram, c'est mon cas. Tout c'est bien passé, nouveau noyau, rebuilt de nvidia 304 redemarrage et... Erreur fatal, plus rien ne marche même plus IceWM .

Pardon mais pour installer sddm comment on fait ? je n'ai aucune idée.
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 08/11/2018 à 20h21
Bonjour,

Citation :
Erreur fatal


C' est dire qu' il y a plantage au démarrage (kernel panic), que gdm ne se lance plus ou que même la session Icewm renvoie une erreur ?

Citation :
pour installer sddm comment on fait ?


en root, il faut taper la commande "urpmi sddm" ( pour procéder à l' installation), puis lancer "drakdm" pour choisir ce gestionnaire de connexion. Edité par nic80 Le 08/11/2018 à 20h21
   
stroibe974 Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 13/08/2018 à 16h22

Localisation : Réunion

Messages: 982

Le 08/11/2018 à 20h27
rainer :

Pardon mais pour installer sddm comment on fait ? je n'ai aucune idée.


Voici les commandes à lancer en tant que root :

Code :

urpmi sddm


Cela devrait installer SDDM, ou te dire qu'il est déjà installé.
Ensuite, toujours en root, je lancerais :

Code :

systemctl enable sddm.service


Puis :
Code :

systemctl start sddm.service


Ça devrait faire apparaître l'écran (graphique) de connexion de l'utilisateur.
Sinon, il faudra taper la commande « reboot » et espérer qu'au prochain démarrage SDDM se lance... ou à défaut, nous dire les messages d'erreur s'il y en a... :désolé1:


Mageia 7 (64bits) - Plasma - Intel Core i7-8700K @ 3.70Ghz - 16Go RAM
frenchmageiauser_9c2c8
   
rainer Membre non connecté

Rang

Avatar

Inscrit le : 13/11/2016 à 19h12

Messages: 74

Le 08/11/2018 à 23h21
merci beaucoup,
je vous écrie avec mageia 6 bureau Gnome !!!! Effectivement activer le service sddm a tout débloqué. Juste une petite question : à chaque démarrage j'ai le message :" builiding nvidia304 driver" et ensuite "installing nvidia driver" . C'est long, est -ce bien normal ? Une fois installé ça devrait y rester , non ?

Du coup le bureau Gnome marche aussi avec mon "nom -utilisateur-mageia5" et j'ai accès à tout les dossiers de /home

encore un grand merci !!!!
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 08/11/2018 à 23h54
Bonjour,

Citation :
j'ai le message :" builiding nvidia304 driver" et ensuite "installing nvidia driver" . C'est long, est -ce bien normal ? Une fois installé ça devrait y rester , non ?


En principe le module est compilé par dkms une seule fois pour un noyau... Donc a moins de changer de noyau à chaque démarrage ( et de ne l' avoir jamais utilisé !), il n' a pas de raison de l' avoir à chaque démarrage ( sauf si la compilation ou l' installation échoue (par exemple si le paquet kernel-desktop-devel (ou kernel-server-devel ! ;-) ) n' est pas installé, même si j' ai un doute que cela soit possible ( puisque kernel-desktop-devel est une dépendance de dkms-nvidia).

Pour s' en assurer, un "uname -r" permet d' avoir la version du noyau installé, et normalement un "rpm -qa | grep kernel-desktop-devel" devrait retourner quelque chose... Si ce n' est pas le cas, c' est que le paquet kernel-desktop-devel n' est pas installé et donc qu' il faut l' installer par un "urpmi kernel-desktop-devel-$(uname -r)" .

Note: j' ai mis kernel-desktop ( puisque je suppose que c' est celui qui est installé) mais si c' est kernel-server qui est installé, il faut faire la substitution nécessaire...
   
stroibe974 Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 13/08/2018 à 16h22

Localisation : Réunion

Messages: 982

Le 09/11/2018 à 06h23
rainer :
merci beaucoup,
je vous écrie avec mageia 6 bureau Gnome !!!! Effectivement activer le service sddm a tout débloqué.


Bonjour rainer !
Je suis content d'apprendre que passer par systemctl enable sddm.service a permis de débloquer le problème.
Ceci dit, j'ai quand-même une petite réserve : apparemment cette commande va empêcher drakdm de faire son travail à l'avenir (ou alors j'ai peut-être trouvé un bug dans drakdm !).

Explication détaillée (surtout pour ceux qui pourront tester dans une machine virtuelle) :
Avant de proposer cette manipulation, j'ai fait quelques tests avec une machine dans VirtualBox : une mageia 6.1 bureaux Cinnamon et IceWM + deux DM installés : LightDM (préférence de Cinnamon) et XDM (préférence de IceWM je suppose).
J'ai installé SDDM, puis activé avec systemctl enable suivi de systemctl start sddm.service

Aux redémarrages suivants, j'avais bien SDDM comme gestionnaire de connexion. Mais à ce stade, si j'ai envie de revenir à LightDM, ou d'utiliser XDM, passer par le Centre de Contrôle Mageia >> Démarrage >> Configurer le gestionnaire de connexion (donc passer par drakdm) n'a plus d'effet : que je choisisse et valide LigthDM ou XDM n'est pas pris en compte, et au redémarrage j'ai toujours SDDM !

Pour « redonner la main » à drakdm, il a fallu que je lance la commande systemctl disable sddm.service. Si je lance drakdm ensuite et que je choisis LightDM, au redémarrage je retrouve bien LightDM. Si je refais la manip inverse dans drakdm, je retrouve également SDDM.

Donc a priori, rainer pourrait lancer la commande disable sans risque... Tant qu'il n'a pas envie de changer de gestionnaire de connexion (DM) il n'y a pas de problème. Mais en l'état actuel, si un jour il a envie de le faire, et d'utiliser drakdm pour le faire (ce qui est quand-même bien mieux que de sortir la console pour taper une commande), il risque de constater que le choix fait dans drakdm ne modifie pas le DM.

Est-ce que vous constatez le même (dys-)fonctionnement ? Est-ce un bug de drakdm ou bien est-ce la conséquence normale de la commande systemclt enable sddm.service ?

rainer :

Juste une petite question : à chaque démarrage j'ai le message :" builiding nvidia304 driver" et ensuite "installing nvidia driver" . C'est long, est -ce bien normal ? Une fois installé ça devrait y rester , non ?


Je dis pareil que nic80 sur cette question. :]

Je pense que s'il recommence à chaque fois à compiler le module, c'est sans doute parce qu'il n'a pas pu aller correctement jusqu'au bout la 1ere fois (démarrage trop long que tu as peut-être interrompu en croyant que la machine était plantée).

Moi, je passerais par le gestionnaire de logiciels pour installer un autre noyau (par exemple le kernel-desktop-4.9.56-1.mga6 qui est le dernier disponible pour la branche 4.9, et son kernel-desktop-devel-4.9.56-1.mga6 correspondant).
Au redémarrage, à l'écran de Grub (« Mageia Boot Menu »), aller dans « Options avancées pour Mageia » et choisir ce nouveau kernel 4.9.56. Normalement, tu devrais constater la compilation du module pour ce nouveau noyau, jamais utilisé.
Lorsque tu es connecté à ton bureau Gnome, ouvre un terminale et tape (en simple utilisateur) « uname -r » pour vérifier que tu es bien en train d'utiliser le noyau 4.9.56. Relance le Gestionnaire de logiciels, mets le filtre sur « installés » et cherche « kernel » pour afficher tes noyaux installés. Supprime le paquet kernel-desktop-4.14.78-1.mga6 et le paquet kernel-desktop-devel-4.14.78-1.mga6 correspondant (ici, tu peux aussi supprimer les paquets qui indiquent à la fois « kernel » et « server »).

Quand ces paquets sont désinstallés, tu peux réinstaller le noyau 4.14.78 et le kernel-devel qui porte le même numéro.

Edit : à ce stade, un petit passage par le CCM >> Démarrage >> Configurer le démarrage du système (pour rafraîchir Grub, par sécurité) est peut-être une bonne idée, juste au cas où.
Au redémarrage de la machine, retourne dans « Options avancées pour Mageia » et choisis le noyau 4.14.78. Il devrait refaire la compilation du module avec dkms. Lorsque tu es sous Gnome, vérifie le noyau utilisé. Redémarre et regarde si dkms est encore en train de compiler le module : normalement, il ne devrait pas...
C'est un peu windowsien comme méthode (désinstaller, puis réinstaller), mais parfois c'est plus facile que de chercher à débogguer :gene: Edité par stroibe974 Le 09/11/2018 à 06h38


Mageia 7 (64bits) - Plasma - Intel Core i7-8700K @ 3.70Ghz - 16Go RAM
frenchmageiauser_9c2c8
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 09/11/2018 à 07h55
Bonjour,

Sinon un

Code BASH :
dkms status


indique comme l' action l' indique le status de chaque module ( nom du module, version du module, version du noyau pour lequel le status affiché, et son status)

Un exemple d' affichage retourné par dkms status:

Citation :
$/sbin/dkms status
rtbth, 3.9.6, 4.18.16-desktop-2.mga7, x86_64: installed


on peut aussi lancer les constructions et l' installation sans avoir a redémarrer, les actions build ( probablement qu' en plus on peut voir s' il y a une erreur lors de la compilation) et install.

Pour la construction (désolé, je ne connais pas le nom du module qui est installé par dkms-nvidia304 (nvidia304 ?) pour le noyau en cours d' exécution

Code BASH :
#dkms build -m nom_du_module -v version_du_module



Pour l' installation (pour le noyau en cours d' éxecution)

Code BASH :
#dkms install -m nom_du_module -v version_du_module


Cela n' empêche pas un reboot pour vérifier si le module est reconstruit encore une fois.

Par contre, s' il y a tentative d' installation à chaque redémarrage, c' est que probablement il n' est pas construit/installé ( et donc que le serveur X fonctionne sans actuellement)
Edité par nic80 Le 09/11/2018 à 07h58
   
rainer Membre non connecté

Rang

Avatar

Inscrit le : 13/11/2016 à 19h12

Messages: 74

Le 09/11/2018 à 17h10
Bonjour,
J'ai fait comme a dit stroibe974 pour le kernel-devel, mais en fait j'étais avec le kernel 4.18.12 desktop. Du coup j'ai installé le 4.14.78 avec le devel et tout va bien; Si je reviens sur 4.18.12 il recompile le nvidia driver alors que le devel 4.18.12 et bien installé. Bref le problème est resolu.

Citation :
Je suis content d'apprendre que passer par systemctl enable sddm.service a permis de débloquer le problème.


J'ai fait comme a dit Nic80 "urpmi sddm" et ensuite "drakdm" et je pouvais choisir entre sddm gdm et xdm

Citation :
Par contre, s' il y a tentative d' installation à chaque redémarrage, c' est que probablement il n' est pas construit/installé ( et donc que le serveur X fonctionne sans actuellement)

Si si le driver nvidia 304.137 était bien installé, mais le problème vient plutôt du kernel 4.18.12 Edité par rainer Le 09/11/2018 à 17h11
   
stroibe974 Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 13/08/2018 à 16h22

Localisation : Réunion

Messages: 982

Le 09/11/2018 à 18h29
rainer :

Si si le driver nvidia 304.137 était bien installé, mais le problème vient plutôt du kernel 4.18.12


Tu as un kernel de la branche 4.18 installé sur ta Mageia 6 ?...
On a donc un aventurier parmi nous ! :hehe:

:resolu:


Mageia 7 (64bits) - Plasma - Intel Core i7-8700K @ 3.70Ghz - 16Go RAM
frenchmageiauser_9c2c8
   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 09/11/2018 à 20h22
Bonjour,

Citation :
On a donc un aventurier parmi nous !


Pas tant que ça.... La preuve quand je veux désinstaller le 4.14.78-desktop ( ce que je n' ai évidemment pas fait) ! Le fait que j' ai un kernel-server est probablement du au fait que j' ai installé (et désinstallé) le 4.14.78-server auparavant...



Ou quand je veux installer le 4.14.78-serveur...



Et non, je n' ai pas les dépots backport ou testing ! ;-) Edité par nic80 Le 09/11/2018 à 20h29
   
stroibe974 Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 13/08/2018 à 16h22

Localisation : Réunion

Messages: 982

Le 09/11/2018 à 20h32
nic80 :
Bonjour,

Citation :
On a donc un aventurier parmi nous !


Pas tant que ça.... La preuve quand je veux désinstaller le 4.14.78-desktop ( ce que je n' ai évidemment pas fait) ! Le fait que j' ai un kernel-server est probablement du au fait que j' ai installé (et désinstallé) le 4.14.78-server auparavant...


Je disais ça parce que la branche 4.18 du noyau n'est pas immédiatement accessible quand on utilise Mageia 6 : pour avoir cette branche, il faut activer les dépôts backports...


Mageia 7 (64bits) - Plasma - Intel Core i7-8700K @ 3.70Ghz - 16Go RAM
frenchmageiauser_9c2c8
   
rainer Membre non connecté

Rang

Avatar

Inscrit le : 13/11/2016 à 19h12

Messages: 74

Le 09/11/2018 à 23h26
Bonsoir,
Eh non c'est ne pas fini !! Nic80 avait raison :

Citation :
Par contre, s' il y a tentative d' installation à chaque redémarrage, c' est que probablement il n' est pas construit/installé ( et donc que le serveur X fonctionne sans actuellement)


Si tout marchait (je parle bien au passé) c'est je était avec le pilote xorg : nouveau Quand je repars dans drakx11 pour configurer l'affichage, je sélectionne la carte nvidia GeForce 6100-7950, OK et là il ma demande si je veux utiliser le pilote propriétaire. Si je reponds "Oui" j'ai de nouveau les problèmes décrit dans mon premier message.

Au démarrage juste après Grub2 j'ai 4x le même message : "DDC responded but no EDID for VGA-1 Ensuite il continue jusqu'à la page connexion. Si je suis avec le pilote "nouveau" je me connecte sans problème, si je suis avec le pilote propriétaire j'ai de nouveau l'écran noir avec quelques dossiers, une souris qui bouge , mais qui ne fait rien. pas de barre en haut , ni en bas et vu la taille des icônes une très basse résolution.

Demain est un autre jour, je vais suivre les instructions de nic80 pour vous donner des infos plus précis.

   
nic80 Membre non connecté

Rang

Avatar

Inscrit le : 06/08/2018 à 23h52

Messages: 1412

Le 10/11/2018 à 15h39
Bonjour,

@stroibe974:
Citation :
Est-ce que vous constatez le même (dys-)fonctionnement ? Est-ce un bug de drakdm ou bien est-ce la conséquence normale de la commande systemclt enable sddm.service ?


Après un rapide test, il me semble avoir constaté la même chose. Après petite recherche, voila mon explication:

Le systemctl enable sddm.service crée le lien symbolique /etc/systemd/system/display-manager.service vers le nouveau service sddm.service ( /usr/lib/systemd/system/sddm.service)

Or drakdm modifie la valeur présente dans /etc/sysconfig/desktop
Et je suppose que dans un fonctionnement normal le display-manager.service doit se baser sur le lien qui se trouve dans /usr/lib/systemd/system/display-manager.service qui est un lien symbolique vers le service predm.service qui lance /etc/X11/prefdm ( qui lit la valeur dans /etc/sysconfig/desktop)

Si systemd pour lancer ses services regarde d' abord dans /etc/systemd/system/ alors l' action de drakdm est rendue inopérante...
C' est ce que j' ai vu dans une Mageia 6 ( je n' ai pas regardé dans Cauldron, mais je crois avoir lu que le mode de fonctionnement pourrait être différent)
Lors du systemctl disable sddm.service, le lien /etc/systemd/system/display-manager.service doit être supprimé et il ne reste donc plus que celui dans /usr/lib/systemd/system/

Edité par nic80 Le 10/11/2018 à 15h40
   
rainer Membre non connecté

Rang

Avatar

Inscrit le : 13/11/2016 à 19h12

Messages: 74

Le 10/11/2018 à 19h32
Bonjour,
J'ai réinstallé mageia6 sans mis à jour (ça va plus vite) avec une autre partition /home et un nouveau nom utilisateur. Ça faillie marcher mais au bout de 2 cliques, les icônes deviennent flous et la souris ne fait plus rien. J'étais avec le kernel 4.9.56 et nvidia 304.135. Du coup j'ai installé kernel 4.14.78 avec le devel et nvidia 304.137. je ne suis pas un aventurier mais en sélectionnant le kernel 4.14.78 il me met comme dépendance obligatoire le kernel 4.18.12 pourquoi ? J'ai donc supprimé le kernel 4.18.12 avec son devel et voila mon bureau plasma qui démarre. Mais ça dure pas les icônes deviennent flous et ça plante. À force de bidouiller nvidia settings sur IceWm je n'ai plus rien après la connexion , ni avec plasma ni avec icewm session

la commande dkms status me donne bien le dkms nvidia 304.137 installé !
   
stroibe974 Membre non connecté

Rang

Avatar

Modérateur

Inscrit le : 13/08/2018 à 16h22

Localisation : Réunion

Messages: 982

Le 10/11/2018 à 20h10
rainer :

J'ai réinstallé mageia6 sans mis à jour (ça va plus vite)


Je suis tout à fait d'accord et je fais toujours les installations sans internet dans un premier temps.
Cela dit, si tu as installé à partir de « Mageia-6-x86_64-DVD.iso », c'est un environnement KDE Plasma assez instable qu'il y a au départ. Une fois le système installé et redémarré, il faut configurer les dépôts en ligne et lancer les mises à jour.
Après ces mises à jour de sécurité, Plasma retrouve un comportement beaucoup plus stable.

rainer :

je ne suis pas un aventurier mais en sélectionnant le kernel 4.14.78 il me met comme dépendance obligatoire le kernel 4.18.12 pourquoi ?


Tu es vraiment sûr que tu n'as pas activé backports dans tes dépôts de logiciels ?


Mageia 7 (64bits) - Plasma - Intel Core i7-8700K @ 3.70Ghz - 16Go RAM
frenchmageiauser_9c2c8
   
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie