Forum

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 ?



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



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 ?

Édité par nic80 Le 08/11/2018 à 08h18

Bonsoir,


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.

Bonjour,



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 ?



en root, il faut taper la commande "urpmi sddm" ( pour procéder à l' installation), puis lancer "drakdm" pour choisir ce gestionnaire de connexion.

Édité par nic80 Le 08/11/2018 à 20h21

Voici les commandes à lancer en tant que root :



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



Puis :


Ç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...

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 !!!!

Bonjour,



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...

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 ?



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

Édité par stroibe974 Le 09/11/2018 à 06h38

Bonjour,

Sinon un



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:



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




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



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)

Édité par nic80 Le 09/11/2018 à 07h58

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.



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


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

Édité par rainer Le 09/11/2018 à 17h11

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

Bonjour,



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 !

Édité par nic80 Le 09/11/2018 à 20h29

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...

Bonsoir,
Eh non c'est ne pas fini !! Nic80 avait raison :



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.

Bonjour,

@stroibe974:


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/

Édité par nic80 Le 10/11/2018 à 15h40

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é !

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.



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