Forum

Reprise du message précédent

Merci Nic80 pour toute ton aide

J'ai fait toutes les vérifications, je suis bien en Mageia9.

Le nom de mon ordinateur est localhost pruneblue, j'ai besoin de changer?

Comme j'ai un écran noir où il devrait avoir le gestionnaire de connexions et que ctrl+alt+F3 fonctionne, j'ai fait init 3 puis startx.

J'obtiens des messages d'erreurs:
Xauth: file/home/prunbleue/.serverauth.1978 does not exist.

_XSERVTransSocketUNIXCreateListener:...
SocketUNIXCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running (EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running (EE)
(EE) Server terminated with error(1). Closinf log file.
Invalid MIT-MAGIC-COOKIE-1 key
Xinit: giving up
Xini:unable to connect to X server: Interrupted system call

Ça vous parle?

Bonjour,

Visiblement même si aucun écran de connexion n' est affiché, visiblement il doit probablement rester un fichier .Xauthority quelque part probablement.

Par nom d' hôte localhost pruneblue, c' est ce que renvoi la commande hostnamectl pour la rubrique "static hostname", je suis supris qu'il y ait un espace ( ce que je ne recommanderais pas) ? Si static hostname renvoi uniquement localhost, alors oui il faudrait le changer.

Pour chercher les fichiers .Xauthority orphelins, on peut faire un ( en root): updatedb, puis lancer la commande locate .Xauthority

Dans ce cas il faudrait supprimer ( ou renommer pour éviter une erreur) ceux qui se trouvent dans /home/quelquechose.

En principe init 3 arrête le serveur X, et startx peut le redémarrer dans certains cas.

edit: le init 3 a bien été fait en root et le startx en utilisateur normal ?

Édité par nic80 Le 11/01/2024 à 19h18

Oui, j'ai fait init 3 en root et j'ai redémarré pour faire startx en normal.

J'ai mal écrit le nom de mon ordinateur C'est prunebleue@localhost en fait.

La commande hostnamectl renvoie localhost.localdomain.

Effectivement, j'ai plusieurs fichiers Xauthority dans des dossiers dans/home en plus d'un dans /root.

Est-ce qu'il vaut mieux les supprimer ou les renommer?
Et selon le cas, il faut utiliser quoi comme commande?

Bonjour,

Attention, si on utilise la commande init 3, on force l'arrêt de la partie graphique. Il ne faut pas donc pas redémarrer l' ordinateur (sinon cela ne sert à rien).

En fait quand on rentre la commande init 3, cela change le niveau d'éxécution, la grande chose visible, ç' est que l' on désactive la partie graphique et l' on passe exclusivement en console/texte. Au contraire le niveau d'execution 5 démarre la partie graphique qui permet d' afficher la partie connexion en mode graphique (fenêtre de connexion). Le mode 5 (ou graphical.target de nos jours avec systemd) est en général le mode par défaut. Ç' est poir cela qu' en de problème avec le serveur graphique on peut se retrouver devant un écran noir.
En redémarrant le pc, on relance le niveau 5 et donc l'interface graphique se qui peut conduire au message serveur déjà démarré.

Ici, quand on passe en init 3 on force l'arrêt de la partie graphique. Le fait de se reconnecter en utilisateur normal et de lancer la commande startx force le serveur graphique a redémarrer et ç' est à ce moment que l' on peut voir les messages d'erreur interessant.

Pour le nom du pc, localhost.localdomain est le nom par défaut qu' il est préférable de changer.

Concernant les fichiers .Xauthority, il est possible de les renommer en utilisant la commande mv (pour move). Si on veut renommer le fichier /home/prunebleue/.Xauthority en /home/prunebleue/.Xauthority.old, on utilisera donc la commande "mv /home/prunebleue/.Xauthority
/home/prunebleue/.Xauthority.old"

On fait comment pour revenir en mode normal quand on est en root? Je ne l'ai jamais fait

Bonjour,

En fait je procéderais comme ceci:

- combinaison ctrl+alt+f2
- connexion en utilisateur normal
- utilisation de la commande "su -" pour passer root
- lancement de la commande "init 3"
- combinaison ctrl+d ( la commande "logout" permet de faire la même chose) pour fermer la session root ( on revient donc à l' utilisateur normal)
- lancer la commande startx

Si on est connecté en root drectement, on doit pouvoir faire un "su prunebleue" - qui ne nécessite pas de rentrer de mot de passe ( root étant super utilisateur) pour se connecter avec l' utilisateur prunebleue ( mais je déconseillerais, ceci pour avoir un environnement "propre" au moment du lancement de la commande startx)

edit: si on passe root pour uniquement renommer les fichiers .Xauthority, pour revenir en utilisateur normal on peut redémarrer le pc ( les fichiers .Xauthority ne sont pas recrées tant que le serveur graphique n' est pas démarré) ou utiliser la commande logout.

Édité par nic80 Le 11/01/2024 à 22h58

J'ai fait init 3 puis startx et j'ai pu accéder à ma session en mode graphique.

Je n'ai pas eu de message d'erreur mais quand j'ai redémarré, je suis revenue à un écran noir au lieu du gestionnaire de connexion.

Si je comprends bien, je peux renommer les fichiers .Xauthority en old directement quand je suis en mode graphique?

Bonjour,

En utilisant la commande startx, on pourrait valider que le prpblème se situe au niveai du gestionnaire de connexion et non au niveau du serveur graphique).

Donc visiblement le problème n' est pas du au fichier .Xauthority (il est préférvale de ne pas les supprimer quand le serveur graphique tourne).

Ici on pourrait essayer de reinstaller le gestionnaire de connexion (si sddm, la commande pourrait être "urpmi --reinstall sddm" ,n' étant pas à côté d'un pc je ne peut pas garantir que ç' est la bonne).

J'ai tenté "urpmi --reinstall sddm". La commande a marché mais quand j'ai redémarré, j'ai eu ce message d'erreur

Citation :

[   7.778292] nouveau 0000:01:00.0: fb: trapped read at 0000513bd0 on channel  -1 [1fed0000 unknown] engine 06 [BAR] client 08 [PFIFO_READ] subclient 00 [FB] reason 0000002 [PAGE_NOT_PRESENT]

J'ai refait init 3 puis startx pour voir et j'arrive toujours sur le bureau.

Bizarrement, j'ai l'applet pour mettre à jour Mageia qui apparaît alors que je suis déjà en Mageia 9.

Bonjour,

Ici cela ressemble à un plantage du pilote graphique Nouveau (qui ne peut être celui qui peut être utilisé avec la carte graphique). Ce qui est surpenant, ç' est que cela ne plante pas sur le bureau. Est ce bien Plasma qui est lancé ?
Pour la migration, cela est probablement parce qu' il reste un fichier de status de migration (il doit pouvoir être supprimé, mais je n' ai pas le chemin en tête).

Je fais comment pour vérifier que c'est Plasma qui est lancé?

Bonjour,

Je pense que le Mageia Welcome permet de savoir quel environnement est lancé.

Sinon, il doit être possible d' installer l' outil screenfetch, puis de le lancer depuis une console.

Si installé depuis le ccm, il faut s' assurer que le choix des applications soit reglés sur tous et non uniquement sur applications graphiques.

Quand je vais dans Bienvenue sur Mageia, mon bureau est bien KDE Plasma.

Bonjour,

Si bureau Plasma s' affiche, alors le problème est probablement du à SDDM.

Il faudrait voir ce que donne la commande en root ( peut être que cela indiquera pourquoi SDDM ne se lance pas) :

"systemctl status sddm"


Pour le fichier à renommer/supprimer, il semble que cela soit /var/lib/urpmi/stale_upgrade_in_progress . Pour faire disparaitre le message de mise à jour, il faut renommer celui ci ( "mv /var/lib/urpmi/stale_upgrade_in_progress /var/lib/urpmi/stale_upgrade_in_progress.a_supprimer") ou le supprimer ("rm /var/lib/urpmi/stale_upgrade_in_progress") avec l' utilisateur root.

La suppression du fichier ne devrait se voir qu' au relancement de mgaapplet ( donc potentiellement au redémarrage suivant du pc).

edit: visiblement il est possible de lancer sddm-greeter ( ce que l'on voit au démarrage) en mode test ( dans les fait en programme normal visiblement). Si le systemctl status sddm ne donne aucune information, on peut essayer de lancer sddm-greeter en mode test depuis une konsole pour voir d' éventuels messages d' erreur. La commande pour ça semble être "sddm-greeter --test-mode --theme=/usr/share/sddm/themes/mga-coffee/" . Attention, rien n' est effectif ( cliquer sur identification, éteindre, redémarrer n' aura aucune action), pour le quitter il faut cliquer sur la croix en haut à droite de la fenêtre.

Édité par nic80 Le 14/01/2024 à 23h48

J'ai lancé la commande systemctl status sddm et voici ce que j'obtiens:

Citation :

sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; preset: enabled)
Active: inactive (dead) since Tue 2024-01-16 19:35:48 CET; 5min ago
Duration: 1d 21h 3min 6.942s
Docs: man:sddm(1)
man:sddm.conf(5)
Process: 1546 ExecStart=/usr/bin/sddm (code=exited, status=0/SUCCESS)
Main PID: 1546 (code=exited, status=0/SUCCESS)
CPU: 585ms

janv. 14 22:32:40 localhost.localdomain systemd[1]: Started sddm.service.
janv. 14 22:32:57 localhost.localdomain sddm-helper[1808]: pam_unix(sddm-greeter:session): session opened for>
janv. 16 19:35:47 localhost.localdomain systemd[1]: Stopping sddm.service...
janv. 16 19:35:47 localhost.localdomain sddm[1546]: Signal received: SIGTERM
janv. 16 19:35:48 localhost.localdomain sddm[1546]: QProcess: Destroyed while process ("/usr/libexec/sddm-hel>
janv. 16 19:35:48 localhost.localdomain systemd[1]: sddm.service: Deactivated successfully.
janv. 16 19:35:48 localhost.localdomain systemd[1]: Stopped sddm.service.

Pour le sddm-greeter, j'ai ceci:

Citation :

19:48:36.886] (EE) GREETER: Socket error: "QLocalSocket::connectToServer : Nom invalide"
[19:48:36.887] (WW) GREETER: QFont::fromString: Invalid description '(empty)'
[19:48:36.897] (II) GREETER: Loading file:///usr/share/sddm/themes/mga-coffee//Main.qml...
[19:48:51.947] (WW) GREETER: QIODevice::write (QLocalSocket): device not open
[19:49:02.185] (WW) GREETER: QIODevice::write (QLocalSocket): device not open

Bonjour,

Malheureusement, je ne vois de choses pertinentes ( sauf peut être le nom de la machine qui gagnerait à être changé.

Ici je suppose que la machine est restée allumée et qu' un init 3 a du être fait à 19h35.

pour le sddm greeter, je constate les mêmes erreurs. Cela ne permet pas de conclure à un problème sur le sddm greeter..

Que pourrait on explorer sur le non affichage de sddm et donc son greeter... les logs systèmes ( "journalctl -b 0 | grep -i sddm") ?