Ça a commencé tard sur IRC, par un dialogue comme :
<SecGuy> ahhh systemd
<SecGuy> ce bonheur.
<Glandos> j'ai un petit conseil technique à ce sujet, je devrais le mettre sur linuxfr ça va aller dans ton sens ;)
Moi, grosso modo, j'aime bien systemd. J'aime pas tout, mais c'est mieux qu'avant. Sauf que parfois, la critique nº1 revient me frapper assez fort : comment comprendre un truc qui marche pas, quand tout est déclenché à la demande, en parallèle, enchevêtré.
Ce problème, c'est le suivant : la session graphique démarre, puis s'arrête avec des erreurs de type « J'ai pas trouvé l'écran », voire « J'ai pas trouvé la carte graphique, j'y vais quand même pas en framebuffer ». Je l'ai eu il y a très longtemps sur mon ordinateur qui me sert de mediacenter. C'est un Ubuntu modifié pour lancer le moins de truc possible, et ça lance Kodi à l'aide d'un xinit […] /usr/bin/kodi.
Et le même problème est arrivé sur mon ordinateur fraîchement mis-à-jour, avec son APU AMD : là, c'est lightdm qui est configuré en auto-login qui parfois ne se lançait pas, parfois si, parfois redémarrait une fois ou deux. Et toujours les mêmes journaux « Blablabla écran ou carte graphique ».
Mais comment faire ? Franchement, j'en suis pas à mon coup d'essai de bidouilles sur systemd. Et j'adore ça en plus. Allez, on retrousse ses manches, et c'est parti.
Il suffit de pas grand chose en fait. D'une part, dans le service concerné :
[Unit]
Wants=dev-dri-card0.device
After=dev-dri-card0.deviceÇa, c'est le fichier /etc/systemd/system/lightdm.service.d/override.conf qu'il est possible de facilement éditer à l'aide de la commande systemctl edit lightdm.service. Mais vous avez compris qu'il est possible de rajouter les directives Wants et After de la section [Unit] n'importe où.
Qu'est-ce que ça fait ? Ça dit simplement que lightdm a besoin du périphérique /dev/dri/card0 (directive Wants), et qu'il doit se lancer après que ce périphérique soit disponible.
Ça a l'air simple, mais il manque un truc. Par défaut, udev ne notifie pas tous les périphériques, et donc dev-dri-card0.device n'existe pas. Il faut donc dire à udev de le faire :
SUBSYSTEM=="drm", TAG+="systemd"
Dans le fichier /etc/udev/rules.d/90-dri-card0.rules. Et voilà, votre service ne se lancera que quand votre carte graphique sera prête. C'est fantastique, non ?
…
…
Oui, bon, c'est méga-obscur. C'est beau, mais c'est impossible à deviner tout seul, voilà pourquoi j'ai fait ce journal.
# Modèle
Posté par claudex . Évalué à 7.
Tu as quoi comme carte graphique pour avoir ce genre de problème ?
(même si je comprends la logique, je trouve toujours que devoir spécifier "Wants" et "After" est quand même particulier dans une unit)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9. Dernière modification le 07 avril 2021 à 07:56.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Modèle
Posté par Glandos . Évalué à 6.
Allez, extrait de Xorg.0.log
Et on notera le journal de
lightdmqui lui correspond :Mais du coup, je suis curieux, je ne connaissais pas gpu-manager.service. Il semblerait que ce soit une spécificité de Ubuntu. Et que contient ce paquet ?
ACTION=="add", SUBSYSTEM=="drm", DEVPATH=="*/drm/card*", RUN+="/sbin/u-d-c-print-pci-ids"ah bah on y est presque.Donc j'ai l'impression que Ubuntu a fait la même chose que moi, qui suis sous Debian. Évidemment, c'est plus robuste, plus solide, que mon bricolage du dimanche.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Modèle
Posté par Glandos . Évalué à 3.
Bon, je vous dois des excuses (c'est plus un vous de groupe, parce qu'il y a plusieurs commentaires là-dessus) : j'ai allègrement mélangé les deux cas :
Mais bizarrement, j'ai eu le même cas sur les deux machines. Et depuis que j'ai introduis ça, ça roule peinard.
[^] # Re: Modèle
Posté par Glandos . Évalué à 2.
Oui et non. J'avoue que c'est bien pratique de pouvoir dire « Lance-toi après
mysql.service postgresql.service» (After) alors que seul l'un des deux existe. Bon, mais c'est une parenthèse, on ne va pas s'éterniser ;)Mon CPU, c'est
AMD Ryzen 7 PRO 4750G with Radeon Graphicsdonc c'est la carte graphique qui est dedans. Il est à noter que mon mediacenter utilise unAMD E-450 APU with Radeon(tm) HD Graphicset donc… c'est pareil, avec quelques générations de retard.# Quelle distro ?
Posté par Ririsoft . Évalué à 3.
Quelle distro utilises-tu ? La configuration udev peut varier d'une distro à l'autre. Pour ma part je n'ai jamais eu ce problème sous Debian Buster et Archlinux avec la config systemd suivante :
cat /etc/systemd/system/kodi.service
[Unit]
Description = kodi-standalone using xinit
After=getty.target multi-user.target network.target
Conflicts=getty@tty1.service
[Service]
User = kodi
Group = kodi
PAMName = login
TTYPath=/dev/tty1
ExecStart = /usr/bin/xinit /usr/bin/dbus-launch --exit-with-session /usr/bin/kodi-standalone -- -nolisten tcp -keeptty vt1
Restart = on-abnormal
StandardInput=tty
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
TemporaryFileSystem=/var /media
BindPaths=/var/lib/kodi /var/run
BindReadOnlyPaths=/media/video
[Install]
WantedBy = multi-user.target
Avec les permissions suivantes pour le group kodi:
kodi : kodi cdrom audio video plugdev netdev
# Gestion d'erreurs en carton
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 07 avril 2021 à 10:48.
Ça me choque toujours ce genre de comportement. Un écran PEUT être et donc SERA déconnecté un jour ou l'autre. Il y a un bouton on/off dessus, le câble HDMI n'est pas soudé…
Un bon serveur graphique DOIT s'attendre à ne pas trouver d'écran et… attendre que l'utilisateur en branche un.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion d'erreurs en carton
Posté par claudex . Évalué à 4.
Sur les portables par contre…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestion d'erreurs en carton
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
L'écran du portable peut tomber en panne et l'utilisateur peut vouloir brancher un second écran pour reprendre sa session et sauvegarder ses documents ouverts.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion d'erreurs en carton
Posté par wismerhill . Évalué à 1.
Certes, mais l'écran en question sera toujours connecté (donc probablement détecté, s'il n'est pas complètement mort). Et puis, si tu branche un écran externe, il y a un écran de connecté ;-)
[^] # Re: Gestion d'erreurs en carton
Posté par abriotde . Évalué à 1.
Mais ce n est pas l écran qu il ne trouve pas, c est l accès à la carte graphique. Et on branche pas la carte graphique à chaud. C est la carte graphique qui se charge d envoyer le signal écran ou pas, elle peut envoyer elle attends rien de l écran.
[^] # Re: Gestion d'erreurs en carton
Posté par wismerhill . Évalué à 3.
Donc, comme déjà écrit par d'autres, le problème n'est pas l'écran mais la carte graphique.
[^] # Re: Gestion d'erreurs en carton
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il existe des cartes graphiques externes :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion d'erreurs en carton
Posté par barmic 🦦 . Évalué à 2.
Sauf en cas de faux contact
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Gestion d'erreurs en carton
Posté par Glandos . Évalué à 2.
Oui, comme dit plus haut, l'erreur de Xorg de type « screen not found », c'est la conséquence : la carte graphique n'est pas prête.
Dans mon cas, les écrans sont toujours connectés, et sont bien disponibles au démarrage.
D'ailleurs, petite digression, mais je suis passé à GBM pour Kodi avec un « simple »
/usr/bin/kodi-standalone --windowing=gbm.En gros : plus de X11, ni de Wayland, mais utilisation directe de la carte graphique. Évidemment, il n'y a qu'une seule application possible. Ça démarre plus vite, ça utilise moins de dépendances, bref, c'est plus low-tech.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Gestion d'erreurs en carton
Posté par Cᴬᴾᵀ Samavor . Évalué à 10.
"no screens found" est un très vieux message d'erreur de X11, ça n'a rien a voir avec la présence physique ou non d'un écran (monitor), c'est un "écran" X11
Et c'est une erreur secondaire, le script d'init finira toujours dessus en cas d’erreur (pas de server pas de display, pas de display pas de screen, pas de screen pas de screen), si elle apparait, faut remonter plus haut dans les logs pour trouver la vraie cause.
# Une raison probable
Posté par Glandos . Évalué à 3.
Toute cette discussion m'a fait chercher un peu plus en profondeur.
Et j'ai trouvé ceci : https://bugzilla.freedesktop.org/show_bug.cgi?id=105968 C'est exactement le processeur de mon mediacenter, et effectivement, le module est lent à l'initialisation. Donc il faut « l'attendre ».
Bizarrement, il se trouve que j'ai le même problème avec mon ordinateur de bureau qui est également un APU, mais nécessitant le module amdgpu au lieu de radeon. Mais le journal système montre une chose similaire :
1,3 seconde pour initialiser le pilote. C'est … beaucoup trop.
Et c'est fort probable que mes « soucis » viennent de là.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.