Journal Un peu d'ordre dans un monde parallèle

Posté par  . Licence CC By‑SA.
Étiquettes :
59
6
avr.
2021

Ç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  . Évalué à 7 (+4/-0).

    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

    • [^] # Re: Modèle

      Posté par  . Évalué à 9 (+7/-0). Dernière modification le 07/04/21 à 07:56.

      Personnellement, je ne comprends même pas la logique. Et cela manque de contexte : il aurait fallu donner les extraits des logs concernés (xsession-errors, ceux de lightdm et ceux de gpu-manager).

      Le service ligthdm est en principe lancé après gpu-manager.service, donc après la reconnaissance de la carte graphique et le chargement de son pilote.
      Le bidouillage proposé me semble par conséquent totalement inutile.

      J'ai l'impression que tu cherches à contourner un bogue de lightdm, ou du pilote de la carte graphique, avec de la « magie » systemd.

      • [^] # Re: Modèle

        Posté par  . Évalué à 6 (+4/-0).

        Allez, extrait de Xorg.0.log

        [     9.810] (II) LoadModule: "amdgpu"
        [     9.810] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
        [     9.810] (II) Module amdgpu: vendor="X.Org Foundation"
        [     9.810]    compiled for 1.20.9, module version = 19.1.0
        [     9.810]    Module class: X.Org Video Driver
        [     9.810]    ABI class: X.Org Video Driver, version 24.1
        [     9.810] (II) AMDGPU: Driver for AMD Radeon:
                All GPUs supported by the amdgpu kernel driver
        [     9.810] (II) AMDGPU(0): [KMS] drm report modesetting isn't supported.
        [     9.810] (EE) Screen 0 deleted because of no matching config section.
        [     9.810] (II) UnloadModule: "amdgpu"
        [     9.810] (EE) Device(s) detected, but none match those in the config file.
        [     9.810] (EE) 
        Fatal server error:
        [     9.810] (EE) no screens found(EE) 
        [     9.810] (EE) 
        Please consult the The X.Org Foundation support 
                 at http://wiki.x.org
         for help. 
        [     9.810] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
        [     9.810] (EE) 
        [     9.810] (EE) Server terminated with error (1). Closing log file.
        

        Et on notera le journal de lightdm qui lui correspond :

        mars 31 20:14:55.632636 complexe systemd[1]: Starting Light Display Manager...
        mars 31 20:14:55.676260 complexe lightdm[935]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
        mars 31 20:14:55.693385 complexe systemd[1]: Started Light Display Manager.
        mars 31 20:14:55.784277 complexe systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE
        mars 31 20:14:55.784310 complexe systemd[1]: lightdm.service: Failed with result 'exit-code'.
        mars 31 20:14:56.135192 complexe systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1.
        mars 31 20:14:56.135515 complexe systemd[1]: Stopped Light Display Manager.
        mars 31 20:14:56.162423 complexe systemd[1]: Starting Light Display Manager...
        mars 31 20:14:56.175760 complexe lightdm[1007]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
        mars 31 20:14:56.181153 complexe systemd[1]: Started Light Display Manager.
        mars 31 20:14:57.066149 complexe lightdm[1042]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
        mars 31 20:14:57.071287 complexe lightdm[1042]: pam_unix(lightdm-autologin:session): session opened for user glandos(uid=1000) by (uid=0)
        

        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 ?

        • Une règle udev ACTION=="add", SUBSYSTEM=="drm", DEVPATH=="*/drm/card*", RUN+="/sbin/u-d-c-print-pci-ids" ah bah on y est presque.
        • Le binaire gpu-manager
        • Le service systemd qui déclare devoir se lancer avant la session graphique

        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.

        • [^] # Re: Modèle

          Posté par  . Évalué à 5 (+3/-0).

          Il me semblait que tu parlais d'Ubuntu dans ton journal…
          De toute façon, me sous Debian, lightdm est lancé bien après la reconnaissance de la carte graphique et le chargement du pilote. Le truc fourni par Ubuntu n'est là que pour faciliter le changement ou la mise à jour du matériel/pilote.

          D'après les logs de XOrg c'est un problème assez courant avec le pilote amdgpu et le KMS (y compris sous Ubuntu) :

          AMDGPU(0): [KMS] drm report modesetting isn't supported.
          
          

          Je me demande donc si ta manipulation corrige de manière perenne le problème.
          Il faudrait faire une recherche sur cela avec le modèle exact de ta carte graphique.

          Ce type de problème est parfois résolu en installant le paquet (non libre) firmware-amd-graphics (pas sûr du nom du paquet).

          • [^] # Re: Modèle

            Posté par  . Évalué à 3 (+1/-0).

            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 :

            • mediacenter sous Ubuntu largement modifié
            • Ordinateur personnel sous Debian/unstable (depuis plus de 10 ans)

            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  . Évalué à 2 (+0/-0).

      (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)

      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 ;)

      Tu as quoi comme carte graphique pour avoir ce genre de problème ?

      Mon CPU, c'est AMD Ryzen 7 PRO 4750G with Radeon Graphics donc c'est la carte graphique qui est dedans. Il est à noter que mon mediacenter utilise un AMD E-450 APU with Radeon(tm) HD Graphics et donc… c'est pareil, avec quelques générations de retard.

  • # Quelle distro ?

    Posté par  . Évalué à 3 (+2/-0).

    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  (site Web personnel) . Évalué à 10 (+11/-2). Dernière modification le 07/04/21 à 10:48.

    la session graphique démarre, puis s'arrête avec des erreurs de type « J'ai pas trouvé l'écran »

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

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Gestion d'erreurs en carton

      Posté par  . Évalué à 4 (+2/-1).

      Il y a un bouton on/off dessus, le câble HDMI n'est pas soudé…

      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  (site Web personnel) . Évalué à 10 (+9/-1).

        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.

        Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: Gestion d'erreurs en carton

          Posté par  . Évalué à 1 (+0/-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  . Évalué à 1 (+0/-0).

            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  . Évalué à 2 (+0/-0).

            Sauf en cas de faux contact

          • [^] # Re: Gestion d'erreurs en carton

            Posté par  . Évalué à 2 (+0/-0).

            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.

    • [^] # Re: Gestion d'erreurs en carton

      Posté par  . Évalué à 6 (+4/-0).

      Est-ce que tu as déjà réellement vu ce type d'erreur ?
      Qu'il y ait un avertissement concernant l'écran dans les logs, oui. Une erreur bloquante sûrement pas.

    • [^] # Re: Gestion d'erreurs en carton

      Posté par  . Évalué à 10 (+10/-0).

      "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  . Évalué à 3 (+1/-0).

    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 :

    avril 10 09:05:59.095569 complexe kernel: [drm] amdgpu kernel modesetting enabled.
    […]
    avril 10 09:05:59.096457 complexe kernel: [drm] VCN decode is enabled in VM mode
    avril 10 09:05:59.096467 complexe kernel: [drm] VCN encode is enabled in VM mode
    avril 10 09:05:59.096475 complexe kernel: [drm] JPEG decode is enabled in VM mode
    avril 10 09:05:59.096482 complexe kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
    avril 10 09:05:59.096490 complexe kernel: amdgpu 0000:05:00.0: amdgpu: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
    avril 10 09:05:59.096572 complexe kernel: amdgpu 0000:05:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
    avril 10 09:05:59.096653 complexe kernel: amdgpu 0000:05:00.0: amdgpu: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
    avril 10 09:05:59.096729 complexe kernel: [drm] Detected VRAM RAM=512M, BAR=512M
    avril 10 09:05:59.096739 complexe kernel: [drm] RAM width 128bits DDR4
    avril 10 09:05:59.096747 complexe kernel: [TTM] Zone  kernel: Available graphics memory: 7872994 KiB
    avril 10 09:05:59.096756 complexe kernel: [TTM] Zone   dma32: Available graphics memory: 2097152 KiB
    avril 10 09:05:59.096764 complexe kernel: [TTM] Initializing pool allocator
    avril 10 09:05:59.096774 complexe kernel: [TTM] Initializing DMA pool allocator
    avril 10 09:05:59.096782 complexe kernel: [drm] amdgpu: 512M of VRAM memory ready
    avril 10 09:05:59.096789 complexe kernel: [drm] amdgpu: 3072M of GTT memory ready.
    avril 10 09:05:59.096802 complexe kernel: [drm] GART: num cpu pages 262144, num gpu pages 262144
    avril 10 09:05:59.096810 complexe kernel: [drm] PCIE GART of 1024M enabled (table at 0x000000F400900000).
    avril 10 09:05:59.099394 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_asd.bin
    avril 10 09:05:59.099516 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_ta.bin
    avril 10 09:05:59.099596 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_pfp.bin
    avril 10 09:05:59.099672 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_me.bin
    avril 10 09:05:59.099751 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_ce.bin
    avril 10 09:05:59.099835 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_rlc.bin
    avril 10 09:05:59.099917 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_mec.bin
    avril 10 09:05:59.103523 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_mec2.bin
    avril 10 09:05:59.103762 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_dmcub.bin
    avril 10 09:05:59.103849 complexe kernel: [drm] Loading DMUB firmware via PSP: version=0x00000000
    avril 10 09:05:59.103858 complexe kernel: amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/renoir_vcn.bin
    avril 10 09:05:59.103939 complexe kernel: [drm] Found VCN firmware Version ENC: 1.7 DEC: 4 VEP: 0 Revision: 17
    avril 10 09:05:59.103950 complexe kernel: [drm] PSP loading VCN firmware
    avril 10 09:05:59.799473 complexe kernel: [drm] reserve 0x400000 from 0xf41f800000 for PSP TMR
    avril 10 09:06:00.039529 complexe kernel: amdgpu 0000:05:00.0: amdgpu: RAS: optional ras ta ucode is not available
    avril 10 09:06:00.067429 complexe kernel: amdgpu 0000:05:00.0: amdgpu: RAP: optional rap ta ucode is not available
    avril 10 09:06:00.067843 complexe kernel: amdgpu 0000:05:00.0: amdgpu: SMU is initialized successfully!
    avril 10 09:06:00.068088 complexe kernel: [drm] kiq ring mec 2 pipe 1 q 0
    avril 10 09:06:00.068131 complexe kernel: [drm] Display Core initialized with v3.2.104!
    avril 10 09:06:00.083470 complexe kernel: [drm] DMUB hardware initialized: version=0x01000000
    avril 10 09:06:00.107460 complexe kernel: snd_hda_intel 0000:05:00.1: bound 0000:05:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
    avril 10 09:06:00.175437 complexe kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
    avril 10 09:06:00.175635 complexe kernel: [drm] JPEG decode initialized successfully.
    avril 10 09:06:00.175702 complexe kernel: kfd kfd: Allocated 3969056 bytes on gart
    avril 10 09:06:00.175943 complexe kernel: Virtual CRAT table created for GPU
    avril 10 09:06:00.175980 complexe kernel: amdgpu: Topology: Add dGPU node [0x1636:0x1002]
    avril 10 09:06:00.176002 complexe kernel: kfd kfd: added device 1002:1636
    avril 10 09:06:00.176151 complexe kernel: amdgpu 0000:05:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 18, active_cu_number 28
    avril 10 09:06:00.176260 complexe kernel: EDAC amd64: F17h_M60h detected (node 0).
    avril 10 09:06:00.179489 complexe kernel: EDAC amd64: Node 0: DRAM ECC disabled.
    avril 10 09:06:00.179596 complexe kernel: [drm] fb mappable at 0x410CE0000
    avril 10 09:06:00.179612 complexe kernel: [drm] vram apper at 0x410000000
    avril 10 09:06:00.179625 complexe kernel: [drm] size 9216000
    avril 10 09:06:00.179636 complexe kernel: [drm] fb depth is 24
    avril 10 09:06:00.179646 complexe kernel: [drm]    pitch is 7680
    avril 10 09:06:00.179656 complexe kernel: fbcon: amdgpudrmfb (fb0) is primary device
    […]
    avril 10 09:06:00.321033 complexe kernel: [drm] Initialized amdgpu 3.40.0 20150101 for 0000:05:00.0 on minor 0
    

    1,3 seconde pour initialiser le pilote. C'est … beaucoup trop.

    Et c'est fort probable que mes « soucis » viennent de là.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.