[RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

nikus972 · 03-09-2020 05:49:11

Bonjour, ma femme c'est racheté un PC plus puissant que celui qu'elle avait depuis 6 ans (sous ubuntu puis debian depuis 3 ans bref)
Elle me dit "Mon cherie je veux bien que tu m'installes linux"
Ok c'est partie, pour info config PC Lenovo S145-15API - AMD Ryzen 5 3500U - Radeon Vega Mobile GFX et equipé d'un DD SSD

je vais chercher debian-live-10.5.0-amd64-gnome+nonfree.iso
Je test le systeme en live et TOUT marche (wifi, bluethoot, camera, etc)

Je lance l'install depuis la live et plantage à 21% une histoire de support graphique...
Au passage je format entièrement le DD on veux pas windows

je relance l'installation en paramétrant le Bios (pas de secure BOOT et je laisse l'UEFI) et en passant par l'installation en commande.
Tout va bien meme le wifi fonctionne, mais il me demande si j'ai les 2 fichiers suivant :
ath10k/pre-cal-pci-0000:02:00.bin
ath10k/cal-pci-0000:02:00.bin

Bien-sur je les ai pas, je répond non, la suite se passe et il termine l'installation.
Je redémarre, GRub se lance, je laisse les 3s, et il lance la routine, mais 2s plus tard ecran noir et curseur en haut à gauche qui clignote....

J'ai bien-sur fait CTRL ALT F2, je me suis mis en root puis fait les mises jours, mais rien ne fonctionne.

Je me suis intéressé à cette discution mais le sujet reste en suspend...

QUI a une idée, parce que ma femme va me démonter.

Dernière modification par nikus972 (07-09-2020 03:19:27)

smolski · 03-09-2020 07:15:17

Salut nikus972 et à l'utilisatrice du pc,

Il y a la probabilité qu'un pilote proprio s'acharne contre l'installation, peut-être la carte graphique ?
Tu as 2 solutions :
1 La rapido presto : Pour l'installation, utiliser l'iso dfLinux :
https://debian-facile.org/projets:iso-debian-facile
En live puis en install si ça colle.

Utiliser une installation minimale avec serveurX pour contrecarrer la carte graphique au cas où ce serait le problème et mettre le bouzin à jour pas à pas en lignes de commande dans la console, en demandant de l'aide sur ce forum en cas de difficulté majeur.
Le tuto :
https://debian-facile.org/doc:install:install_minimale

Force, vigueur et courage à tous deux

jarek · 03-09-2020 11:21:40

Les ryzen 3xxx s'accomodent très bien de bullseye.
Il n'y a pas longtemps je l'ai installé en version minimale (sources.list main seul) puis ajouté ce qu'il faut en recovery mode en et pas de problème.

Dernière modification par jarek (04-09-2020 08:52:16)

smolski · 03-09-2020 11:38:05

jarek a écrit :

Il n'y a pas longtemps je l'ai installé en version minimale

Ah c'est fort !
Dans le wiki, chaque membre df dispose d'une page perso à créer, elle permet de mettre des tutos persos et autres configurations à usage pour soi et pour tous sans que d'autres que l'utilisateur ne puissent y mettre la main.
Ainsi, ça fait toujours des references de plus à consulter en cas de recherche sur un problème...

https://debian-facile.org/utilisateurs:utilisateurs

captnfab · 03-09-2020 12:52:52

En général, installer firmware-amd-graphics est nécessaire pour les cartes amd récentes qui ont ce symptôme.

nikus972 · 03-09-2020 13:26:43

smolski a écrit :

...Il y a la probabilité qu'un pilote proprio s'acharne contre l'installation, peut-être la carte graphique ?
Tu as 2 solutions :
1 La rapido presto : Pour l'installation, utiliser l'iso dfLinux :
https://debian-facile.org/projets:iso-debian-facile
En live puis en install si ça colle.

Utiliser une installation minimale avec serveurX pour contrecarrer la carte graphique au cas où ce serait le problème et mettre le bouzin à jour pas à pas en lignes de commande dans la console, en demandant de l'aide sur ce forum en cas de difficulté majeur.
Le tuto :
https://debian-facile.org/doc:install:install_minimale...

Je pense aussi que cela vient de la carte graphique.
Pourquoi la version ISO de DFLinux serait plus efficace que celle que j'ai utilisé?
Et la solution 2 en mode minimal est aussi réalisé par @Jarek donc je pense faire ainsi.

captnfab a écrit :

En général, installer firmware-amd-graphics est nécessaire pour les cartes amd récentes qui ont ce symptôme.

J'ai fait la modification des sources en ajoutant backports, et j'ai fait les commandes suivantes :

apt update && apt upgrade

apt install --reinstall firmware-amd-graphics

reboot

Mais pas de fonctionnement

naguam · 03-09-2020 14:12:09

Avec debian stable, le ryzen 3500U (zen+) est il me semble trop récent pour le noyau 4.19 de la debian stable.
Si tu n'arrives pas à installer, la stable, je te conseilles d'essayer avec une iso testing.
Il te faudra pour la carte graphique intégrée installer comme déjà indiqué, firmware-amd-graphics.
Pour le processeur, je te conseille également d'installer amd64-microcode.

ath10k/pre-cal-pci-0000:02:00.bin
ath10k/cal-pci-0000:02:00.bin

Sur mon dell xps j'ai les meme messages sous debian et pas sous les autres distros, mais cela n'empeche pas le fonctionnement et de ce que j'ai compris c'est pas très important.

Dernière modification par naguam (03-09-2020 14:15:46)

smolski · 03-09-2020 16:30:25

nikus972 a écrit :

Pourquoi la version ISO de DFLinux serait plus efficace que celle que j'ai utilisé?

Parce que ceux qui la développent le font pour assurer le maximum de compatibilités possible, notamment les firmwares...
Ensuite, si ça fonctionne, tu peux tout aussi bien bidouiller l'installation à ta guise pour la retransformer pas à pas à ton goût.

Yep !

anonyme · 03-09-2020 18:00:13

Bonsoir

Et la solution 2 en mode minimal est aussi réalisé par @Jarek donc je pense faire ainsi.

 

oui c'est le mieux , installe buster en minimal
met a jour ton sources.list
un apt update
installe le firmware-amd-graphics
installe les deux méta-paquet linux-image-amd64 et linux-headers-amd64
modifie ton sources.list en bullseye
du genre en https par exemple

#bullseye11 https

deb https://deb.debian.org/debian-security bullseye-security/updates main contrib non-free

deb https://deb.debian.org/debian/ bullseye-updates main contrib non-free

deb https://deb.debian.org/debian/ bullseye main contrib non-free

un apt-get update , puis un apt-get upgrade puis un apt-get dist-upgrade (une commande après l'autre ) puis un reboot
un apt update et installation du bureau de ton choix
par exemple pour moi avec mate minimal je fais

apt-get install mate-core lightdm

 

reboot => tu dois arriver au bureau
ensuite je personnalise mon bureau tranquillement (ajout de logiciel/paquet )
pour les bugs installe "apt-listbugs" et "synaptic" pour l'équivalent d' apt en mode graphique (sur gnome il est peut être déjà installé par défaut)
sinon tous les bureau ont un mode d'installation "full" , tout est installé par défaut (a l'aide d un méta paquet )
tu évitera de passer par la case "écran noir"

ps: pour le #5 si le noyau ne connaît pas le matériel le firmware ne sert a rien
les backports , c'est se compliquer la vie pour un résultat souvent mauvais

pour finir les backports s'utilise avec l'option "-t" sur buster
par exemple dans ton cas (avec la ligne des backports dans le souces.list)

apt-get install -t buster-backports firmware-amd-graphics amd64-microcode linux-image-amd64 linux-headers-amd64

 

il te manque toute la partie graphique mesa , drm , etc
donc bien compliqué tout ça
tu a l'option "-s" pour tester la commande sans le faire

apt-get -s install -t buster-backports firmware-amd-graphics amd64-microcode linux-image-amd64 linux-headers-amd64

 

tu verra ce que ceci appelle comme dépendances sans le faire en réel .

jarek · 04-09-2020 09:17:26

smolski a écrit :

jarek a écrit :
Il n'y a pas longtemps je l'ai installé en version minimale

Ah c'est fort !

Peut-être, mais c'est pas moi !
Tout ça est dans un sujet du forum INSTALLATION DEBIAN, et à la fin je donne un récapitulatif du comment j'ai fait pour que ça marche.

Si je fais un tuto, une relecture devra être faite parce que c'est pas une bonne idée de laisser traîner des erreurs ou imprécisions.

jarek · 04-09-2020 09:20:16

anonyme a écrit :

Bonsoir

Et la solution 2 en mode minimal est aussi réalisé par @Jarek donc je pense faire ainsi.

oui c'est le mieux , installe buster en minimal

Je parlais de bullseye, pas de buster.

Jean-Pierre Pinson · 04-09-2020 09:31:14

Bonjour nikus972

Je te conseille d'utiliser soit l'iso dfLinux :
https://debian-facile.org/projets:iso-debian-facile

Soit une iso avec tous les firmwares

Dernière modification par Jean-Pierre Pinson (04-09-2020 09:32:11)

jarek · 04-09-2020 09:37:22

Dans des tas de discussions, et de mon expérience, il ressort que ça ne marche pas avec un Ryzen 3xxx

captnfab · 04-09-2020 10:02:09

Tu peux toujours essayer de lancer Xorg en forçant un certain driver.

Voici un squelette de fichier, à créer dans /etc/X11/xorg.conf.d/ma_carte.conf

Section "Device"

  Identifier "Device0"

  Driver "radeon"

EndSection

Tu peux essayer avec "radeon", "amdgpu", "modesetting", "fbdev", "vesa"…

Debian Alain · 04-09-2020 10:23:19

bonjour nikus972

je t'encourage à chercher , mais , tu verra , sur beaucoup de posts qu'il est vivement recommandé d'utiliser testing (ou bullseye) avec le ryzen 5.
ce proc. étant suffisamment récent pour pas être supporté par buster mais plutôt par les dernières versions de debian (testing / sid) .

anonyme · 04-09-2020 13:29:53

captnfab a écrit :

Tu peux toujours essayer de lancer Xorg en forçant un certain driver.

Voici un squelette de fichier, à créer dans /etc/X11/xorg.conf.d/ma_carte.conf
Section "Device"
Identifier "Device0"
Driver "radeon"
EndSection

Tu peux essayer avec "radeon", "amdgpu", "modesetting", "fbdev", "vesa"…

Bonjour
forcer un driver a mon avis ça ne va rien améliorer
il suffit de lui donner une bonne version du noyau et du firmware-amd-graphics pour que sont gpu soit correctement initialisé et fonctionnel
ps: le curseur qui clignote , c'est que le système a tenté de charger tous les drivers compatible sans réussir
un exemple (du Xorg.0.log)

 12.903] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0

[    12.903]  loading driver: amdgpu

[    12.903] (==) Matched amdgpu as autoconfigured driver 0

[    12.903] (==) Matched ati as autoconfigured driver 1

[    12.903] (==) Matched modesetting as autoconfigured driver 2

[    12.903] (==) Matched fbdev as autoconfigured driver 3

[    12.903] (==) Matched vesa as autoconfigured driver 4

si le matériel est reconnu

[    12.903] (==) Assigned the driver to the xf86ConfigLayout

[    12.903] (II) LoadModule: "amdgpu"

[    12.903] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so

forcer un driver a mon avis ne va rien apporter de plus

ps: je pense que toujours le cas , les APU et gpu AMD récent ont besoin des deux "modesetting" et "xserver-xorg-video-amdgpu"

All GPUs supported by the amdgpu kernel driver

[    12.924] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

[    12.924] (II) FBDEV: driver for framebuffer: fbdev

[    12.924] (II) VESA: driver for VESA chipsets: vesa

[    12.943] (II) AMDGPU(0): [KMS] Kernel modesetting enabled.

ensuite c'est le driver "amdgpu" qui est utilisé

[    12.947] (II) AMDGPU(0): Creating default Display subsection in Screen section

  "Default Screen Section" for depth/fbbpp 24/32

[    12.947] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32

[    12.947] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)

[    12.947] (==) AMDGPU(0): Default visual is TrueColor

[    12.947] (==) AMDGPU(0): RGB weight 888

[    12.947] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC)

[    12.947] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x15dd)

bien que mon APU est inconnu , tout fonctionne correctement (sûrement la base de données du matériel sur le driver qui n'est pas a jour )

bref pour faire simple monter en version pour le noyau et le firmware a minima , mais passer a une version de debian en testing encore mieux

anonyme · 04-09-2020 13:51:58

re,
de son #1

J'ai bien-sur fait CTRL ALT F2, je me suis mis en root puis fait les mises jours, mais rien ne fonctionne.

 

soit il passe en backports mais je déconseille et met en place noyau et firmware
soit il migre en bullseye a partir de la console root et ne reboot que a la fin
c'est un vega8 version mobile (m)
si pas déjà fait installer le firmware amd
si pas déjà fait installer les deux méta paquet "linux-image-amd64" et "linux-headers-amd64"
modifier le souces.list en bullseye
un update
un upgrade
un dist-upgrade (ou full-upgrade ) (apt-get ou apt)
a la fin un reboot il doit avoir son bureau
nota: le gpu (apu) est de janvier 2019 environ , donc très récent
je pense que le plus simple pour lui , a partir de son installation de buster

Dernière modification par anonyme (04-09-2020 13:58:00)

captnfab · 05-09-2020 07:11:10

@anonyme:
Les cartes graphiques sont supportées à différents niveaux. Par défaut, Xorg essaie d'utiliser le pilote modesetting. Mais si celui-ci échoue car la prise en charge de KMS pour la carte n'est pas fonctionnelle, il n'est pas impossible qu'un autre pilote (par exemple amdgpu) permette de faire tourner la carte, quitte à ce que ce soit en mode dégradé.

Bien sûr qu'avec un noyau assez récent et des firmwares assez récents, ceci n'est pas nécessaire. Mais c'est bien là le problème, non ?

Normalement, les noyaux + firmwares des backports sont les mêmes que ceux de testing (à quelques semaines près), donc il n'y aurait pas vraiment d'intérêt à passer à testing si ça ne fonctionne pas avec les backports.

De plus, migrer totalement vers testing juste pour un soucis de prise en charge matérielle, c'est un peu dommage.

Et finalement, migrer vers testing nécessite de rajouter les dépôts sid en support, et se révèle être plus complexe à gérer qu'une stable. Il faut savoir dépanner son système pour les quelques fois où il casse.

chalu · 05-09-2020 08:20:06

Bonjour,
Une courte intervention pour rappeler que gérer Bulleyes qui n'est pas une "vraie" distribution comme indiqué dans les pages officielles Debian demande quand même une certaine maitrise/connaissance du système et de la gestion de mises à jour avec apt-lisbugs, des paquets à bloquer s'ils sont bogués, des paquets qui sont supprimés ... Ce n'est pas comme sur une stable où on fait les mises à jour sans se poser de question.
D'après le premier message, le PC a été acheté pour être plus rapide/efficace, ce n'est pas certain que la gestion d'une testing soit souhaitée

Comme captnfab l'indique, installer le noyau des backports et le firmware pour amd, si ça fonctionne, c'est sans doute plus facile ensuite pour gérer le système.
(edit : mon message fait doublon avec le précédent de captnfab que je n'avais pas lu jusqu'à la fin ....)

jarek · 05-09-2020 09:35:04

J'ai lu un peu partout des informations contradictoires concernant l'utilisation de bullseye, alors il y a quelques mois j'ai décidé de l'installer parce que mon Ryzen 3xxxG ne fonctionnait pas sous buster+backports.

Je n'ai rien de sid dans les sources.list et fais les màj à chaque fois que j'allume le PC, sans autre préoccupation ni de apt-listbugs, et ce depuis le mois de mars.
Alors je ne comprend pas bien ces réticences.

captnfab · 05-09-2020 09:43:06

jarek a écrit :

J'ai lu un peu partout des informations contradictoires concernant l'utilisation de bullseye, alors il y a quelques mois j'ai décidé de l'installer parce que mon Ryzen 3xxxG ne fonctionnait pas sous buster+backports.

Je n'ai rien de sid dans les sources.list et fais les màj à chaque fois que j'allume le PC, sans autre préoccupation ni de apt-listbugs, et ce depuis le mois de mars.
Alors je ne comprend pas bien ces réticences.

J'utilise testing/sid depuis 2007, je sais donc de quoi je parle. Il y a des périodes calmes où tout se passe bien, et d'autres où ça casse.
Un autre truc que l'on ne sait pas forcément, c'est que les mises à jour de sécurité n'arrivent dans testing que une, deux semaines voire plus après sid.

jarek · 05-09-2020 10:28:27

Et testing tout court ? (pas testing/sid) C'est pareil ?
Je suppose que les aléas de fonctionnement dépendent aussi des paquets/applications installés.
Mais quand il n'y a pas le choix (c'était le cas fin 2019) . . .

Oui, il est bien indiqué dans la doc debian que des màj peuvent traîner.

Debian Alain · 05-09-2020 11:01:37

bonjour nikus972 et tous les autres

je viens apporter ici ma participation personnelle à ce fil .

la stable actuelle , c'est buster .
la future stable , actuelle testing donc , c'est bullseye .

j'utilise les deux stable (éventuellement avec les backports)
et testing (avec les dépôts sid et expérimental)

que ce soit l'une ou l'autre , je n'ai jamais rencontré de difficulté particulière dans la gestion des paquets .
pour stable , backports me sert parfois pour certaines choses délicates . enfin , m'a servi , par le passé .
je n'ai plus de souci depuis un petit bout de temps (c'était la carte graphique , de mémoire)
j'avais commencé à l'époque à les résoudre avec backports mais , finalement ,
il s'est avéré beaucoup plus simple d'installer testing .

lequivalent de backports sous testing , c'est sid . très pratique .
quand les m.a.j. m'on cassé gnome ou quand un kernel 5.8 me casse VirtualBox , sid s'est avéré très pratique .
avec un peu de pinning , no soucy .

je ne peux que t'encourager à passer à testing si ta config l'exige (ryzen3 / ryzen5 / ....)

bien sûr , les puristes te diront "sid" ! mais si c'est la future stable qui t'intéresse , testing est très bien .
tu peux y mettre les dépôts sid en roue de secours . avec du pinning c'est parfait .

amicalement ,

alain .

chalu · 05-09-2020 11:59:11

@jarek : pas trop de souci car tu as xfce ? Sur Gnome ou KDE, il y a des périodes où ça bouge sans doute plus.
@debian-alain : tu as l’expérience maintenant et le temps ... même de compiler le noyau

dire que tout roule ...tu as quand même créé un certain nombre de fil pour des problèmes de paquets.

Debian Alain · 05-09-2020 12:16:23

chalu a écrit :

dire que tout roule ...tu as quand même créé un certain nombre de fil pour des problèmes de paquets.

oui , surtout au début , quand j'ai découvert testing ou quand j'installais ma première carte graphique sous linux .

je me souviens que , à l' époque , la RX 550 venait de sortir et m' a causé quelques soucis de performances et / ou de compatibilité .

en période de gel , testing peut être délicat à manipuler . quand gnome à fait sa transition de 3.34 à 3.36 , çà m'a causé des soucis aussi .

mais je commence à prendre en mains testing . et tout va bien . pour l'instant .

mes derniers soucis l'ont été avec le noyau 5.8 de kernel.org , donc , non debian .

côté debian , le noyau 5.7.0-3 ne me pose pas de souci particulier .

Debian-facile

#1 03-09-2020 05:49:11

[RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#2 03-09-2020 07:15:17

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#3 03-09-2020 11:21:40

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#4 03-09-2020 11:38:05

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#5 03-09-2020 12:52:52

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#6 03-09-2020 13:26:43

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#7 03-09-2020 14:12:09

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#8 03-09-2020 16:30:25

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#9 03-09-2020 18:00:13

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#10 04-09-2020 09:17:26

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#11 04-09-2020 09:20:16

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#12 04-09-2020 09:31:14

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#13 04-09-2020 09:37:22

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#14 04-09-2020 10:02:09

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#15 04-09-2020 10:23:19

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#16 04-09-2020 13:29:53

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#17 04-09-2020 13:51:58

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#18 05-09-2020 07:11:10

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#19 05-09-2020 08:20:06

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#20 05-09-2020 09:35:04

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#21 05-09-2020 09:43:06

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#22 05-09-2020 10:28:27

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#23 05-09-2020 11:01:37

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#24 05-09-2020 11:59:11

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

#25 05-09-2020 12:16:23

Re : [RÉSOLU] Curseur qui clignote-Debian 10.5 Lenovo S145 Ryzen 5 3500U

Pied de page des forums