Mise à jour J'ai creusé un peu plus et j'ai trouvé la solution à ce problème pour l'ancien pilote fglrx : https://bitcointalk.org/index.php?topic=170470.60 Cependant, cela ne fonctionne pas avec les pilotes AMDGPU, qui ne sont pas livrés avec switchlibglx pré-packagé pour autant que je sache.
Mise à jour 2 - Trouvé cette solution possible mais cela n'a pas fonctionné. J'obtiens l'une ou l'autre des 2 choses suivantes : A, un écran noir lorsque je lance systemctl isolate graphical.target ou B, si je procède à l'inscription du conducteur sur la liste noire, l'incapacité à la mienne.
Mise à jour 3 Ouvert /var/log/Xorg.0.log dans un VT (la valeur par défaut de systemd étant temporairement fixée à multi-user.target tant que ce problème persiste) une erreur extrêmement bizarre "aucun écran trouvé". Je me demande si les pilotes AMDGPU n'essaient pas de forcer X à les utiliser au démarrage ; espérons que ce n'est pas le cas.
Mise à jour 4 Trouvé ces instructions dans les forums d'Arch Linux en recherchant le message exact concernant le fait de ne pas trouver d'affichage - maintenant, au lieu de sortir de manière anormale, le système se bloque simplement lorsque j'essaie de lancer startx. C'est une amélioration, mais cela ne fonctionne toujours pas.
Mise à jour 5 L'accrochage ci-dessus se produit pendant environ 5 minutes, puis il se termine par une erreur "Connexion refusée". Tiré vers le haut ~/.local/share/xorg/Xorg.0.log - il dit en fait "Server terminated successfully" malgré la sortie de startx qui dit que c'est ce qu'il faut consulter.
Mise à jour 6 Recherche sur Google site:bugs.launchpad.net "amdgpu" a augmenté ce rapport de bogue qui peut être liée à ce problème. J'ai essayé la solution de contournement, mais non, cela n'a pas fonctionné.
Mise à jour 7 La course à pied journalctl | grep gdm | grep EE | less a permis d'obtenir des informations très utiles pour résoudre ce problème :
(EE) open /dev/fb0: Permission deniedQu'est-ce que le pilote AMDGPU fait aux permissions sur le framebuffer ?
Mise à jour 8 Toujours pas de solution ; mise en place d'une prime.
Mise à jour 9 J'ai aussi essayé Wayland ; en fait, c'est ce que le média en direct propose par défaut. GNOME n'utilise pas Weston, donc weston.ini ne fonctionnera pas lorsqu'il s'agira de forcer l'utilisation de i915 et d'ignorer amdgpu.
La description originale commence ci-dessous.
Je viens de construire une plateforme de minage avec Ubuntu 18.04.1 (j'ai essayé la pré-version 18.10 mais pour une raison ou une autre, AMDGPU ne parvient pas à construire les modules DKMS dans ce cas, même en appliquant des solutions connues comme le spoofing de version, donc j'ai dû simplement rétrograder). La carte fonctionne très bien, minant ETH entre 24,2 et 24,3 MH/s même avec une seule Sapphire Nitro Radeon RX 480 (qui a un bien meilleur ventilateur que la carte de base et peut donc supporter un hashrate élevé lorsque la vitesse du ventilateur est poussée à fond).
Le système est également équipé d'un processeur Intel Core i5-8400 - qui dispose non seulement de six cœurs mais aussi d'une carte graphique intégrée - fonctionnant sur la carte mère MSI H310-F Pro. Avant que je ne configure les pilotes AMDGPU pour faire fonctionner cette carte, GNOME Shell fonctionnait parfaitement. Cependant, après avoir configuré le GPU discret pour l'exploitation minière, il n'y a soudainement plus que des VT - pas de GNOME, pas de GDM, pas de X, rien. Existe-t-il un moyen de forcer X à utiliser la puce graphique intégrée d'Intel sur le i5-8400 afin de pouvoir utiliser le bureau et miner en même temps ? Toute aide serait grandement appréciée.
