Problème installation Debian 10

Support Debian
#121

1 Comme ça fonctionne que en nomodeset, je ne sais pas ce que je perds en qualité.
2 Vu mon niveau novice, NON.
3

root@Utilisateur-Debian:/home/utilisateur# dmesg | grep 'radeon'
[    2.869818] [drm] VGACON disable radeon kernel modesetting.
[    2.870005] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
[   12.858278] [drm] VGACON disable radeon kernel modesetting.
[   12.858435] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
root@Utilisateur-Debian:/home/utilisateur# dmesg | grep 'radeon'```

```root@Utilisateur-Debian:/home/utilisateur# apt list libdrm-radeon1
En train de lister... Fait
libdrm-radeon1/stable,now 2.4.97-1 amd64  [installé, automatique]
root@Utilisateur-Debian:/home/utilisateur#

root@Utilisateur-Debian:/home/utilisateur# apt list libdrm-radeon1
En train de lister... Fait
libdrm-radeon1/stable,now 2.4.97-1 amd64  [installé, automatique]
root@Utilisateur-Debian:/home/utilisateur# ls /lib/firmware/radeon/
ARUBA_me.bin	   hainan_smc.bin    mullins_mec.bin	 RV620_me.bin
ARUBA_pfp.bin	   HAINAN_smc.bin    MULLINS_mec.bin	 RV620_pfp.bin
ARUBA_rlc.bin	   hawaii_ce.bin     mullins_pfp.bin	 RV630_me.bin
banks_k_2_smc.bin  HAWAII_ce.bin     MULLINS_pfp.bin	 RV630_pfp.bin
BARTS_mc.bin	   hawaii_k_smc.bin  mullins_rlc.bin	 RV635_me.bin
BARTS_me.bin	   HAWAII_mc2.bin    MULLINS_rlc.bin	 RV635_pfp.bin
BARTS_pfp.bin	   hawaii_mc.bin     mullins_sdma1.bin	 RV670_me.bin
BARTS_smc.bin	   HAWAII_mc.bin     mullins_sdma.bin	 RV670_pfp.bin
bonaire_ce.bin	   hawaii_me.bin     MULLINS_sdma.bin	 RV710_me.bin
BONAIRE_ce.bin	   HAWAII_me.bin     mullins_uvd.bin	 RV710_pfp.bin
bonaire_k_smc.bin  hawaii_mec.bin    mullins_vce.bin	 RV710_smc.bin
BONAIRE_mc2.bin    HAWAII_mec.bin    oland_ce.bin	 RV710_uvd.bin
bonaire_mc.bin	   hawaii_pfp.bin    OLAND_ce.bin	 RV730_me.bin
BONAIRE_mc.bin	   HAWAII_pfp.bin    oland_k_smc.bin	 RV730_pfp.bin
bonaire_me.bin	   hawaii_rlc.bin    OLAND_mc2.bin	 RV730_smc.bin
BONAIRE_me.bin	   HAWAII_rlc.bin    oland_mc.bin	 RV740_smc.bin
bonaire_mec.bin    hawaii_sdma1.bin  OLAND_mc.bin	 RV770_me.bin
BONAIRE_mec.bin    hawaii_sdma.bin   oland_me.bin	 RV770_pfp.bin
bonaire_pfp.bin    HAWAII_sdma.bin   OLAND_me.bin	 RV770_smc.bin
BONAIRE_pfp.bin    hawaii_smc.bin    oland_pfp.bin	 RV770_uvd.bin
bonaire_rlc.bin    HAWAII_smc.bin    OLAND_pfp.bin	 si58_mc.bin
BONAIRE_rlc.bin    hawaii_uvd.bin    oland_rlc.bin	 SUMO2_me.bin
bonaire_sdma1.bin  hawaii_vce.bin    OLAND_rlc.bin	 SUMO2_pfp.bin
bonaire_sdma.bin   JUNIPER_me.bin    oland_smc.bin	 SUMO_me.bin
BONAIRE_sdma.bin   JUNIPER_pfp.bin   OLAND_smc.bin	 SUMO_pfp.bin
bonaire_smc.bin    JUNIPER_rlc.bin   PALM_me.bin	 SUMO_rlc.bin
BONAIRE_smc.bin    JUNIPER_smc.bin   PALM_pfp.bin	 SUMO_uvd.bin
bonaire_uvd.bin    kabini_ce.bin     pitcairn_ce.bin	 tahiti_ce.bin
BONAIRE_uvd.bin    KABINI_ce.bin     PITCAIRN_ce.bin	 TAHITI_ce.bin
bonaire_vce.bin    kabini_me.bin     pitcairn_k_smc.bin  tahiti_k_smc.bin
BONAIRE_vce.bin    KABINI_me.bin     PITCAIRN_mc2.bin	 TAHITI_mc2.bin
BTC_rlc.bin	   kabini_mec.bin    pitcairn_mc.bin	 tahiti_mc.bin
CAICOS_mc.bin	   KABINI_mec.bin    PITCAIRN_mc.bin	 TAHITI_mc.bin
CAICOS_me.bin	   kabini_pfp.bin    pitcairn_me.bin	 tahiti_me.bin
CAICOS_pfp.bin	   KABINI_pfp.bin    PITCAIRN_me.bin	 TAHITI_me.bin
CAICOS_smc.bin	   kabini_rlc.bin    pitcairn_pfp.bin	 tahiti_pfp.bin
CAYMAN_mc.bin	   KABINI_rlc.bin    PITCAIRN_pfp.bin	 TAHITI_pfp.bin
CAYMAN_me.bin	   kabini_sdma1.bin  pitcairn_rlc.bin	 tahiti_rlc.bin
CAYMAN_pfp.bin	   kabini_sdma.bin   PITCAIRN_rlc.bin	 TAHITI_rlc.bin
CAYMAN_rlc.bin	   KABINI_sdma.bin   pitcairn_smc.bin	 tahiti_smc.bin
CAYMAN_smc.bin	   kabini_uvd.bin    PITCAIRN_smc.bin	 TAHITI_smc.bin
CEDAR_me.bin	   kabini_vce.bin    R100_cp.bin	 TAHITI_uvd.bin
CEDAR_pfp.bin	   kaveri_ce.bin     R200_cp.bin	 TAHITI_vce.bin
CEDAR_rlc.bin	   KAVERI_ce.bin     R300_cp.bin	 TURKS_mc.bin
CEDAR_smc.bin	   kaveri_me.bin     R420_cp.bin	 TURKS_me.bin
CYPRESS_me.bin	   KAVERI_me.bin     R520_cp.bin	 TURKS_pfp.bin
CYPRESS_pfp.bin    kaveri_mec2.bin   R600_me.bin	 TURKS_smc.bin
CYPRESS_rlc.bin    kaveri_mec.bin    R600_pfp.bin	 verde_ce.bin
CYPRESS_smc.bin    KAVERI_mec.bin    R600_rlc.bin	 VERDE_ce.bin
CYPRESS_uvd.bin    kaveri_pfp.bin    R600_uvd.bin	 verde_k_smc.bin
hainan_ce.bin	   KAVERI_pfp.bin    R700_rlc.bin	 VERDE_mc2.bin
HAINAN_ce.bin	   kaveri_rlc.bin    REDWOOD_me.bin	 verde_mc.bin
hainan_k_smc.bin   KAVERI_rlc.bin    REDWOOD_pfp.bin	 VERDE_mc.bin
HAINAN_mc2.bin	   kaveri_sdma1.bin  REDWOOD_rlc.bin	 verde_me.bin
hainan_mc.bin	   kaveri_sdma.bin   REDWOOD_smc.bin	 VERDE_me.bin
HAINAN_mc.bin	   KAVERI_sdma.bin   RS600_cp.bin	 verde_pfp.bin
hainan_me.bin	   kaveri_uvd.bin    RS690_cp.bin	 VERDE_pfp.bin
HAINAN_me.bin	   kaveri_vce.bin    RS780_me.bin	 verde_rlc.bin
hainan_pfp.bin	   mullins_ce.bin    RS780_pfp.bin	 VERDE_rlc.bin
HAINAN_pfp.bin	   MULLINS_ce.bin    RS780_uvd.bin	 verde_smc.bin
hainan_rlc.bin	   mullins_me.bin    RV610_me.bin	 VERDE_smc.bin
HAINAN_rlc.bin	   MULLINS_me.bin    RV610_pfp.bin
root@Utilisateur-Debian:/home/utilisateur# 

root@Utilisateur-Debian:/home/utilisateur# grep -m2 linux /boot/grub/grub.cfg
### BEGIN /etc/grub.d/10_linux ###
set linux_gfx_mode=
root@Utilisateur-Debian:/home/utilisateur# 

root@Utilisateur-Debian:/home/utilisateur# id
uid=0(root) gid=0(root) groupes=0(root)
root@Utilisateur-Debian:/home/utilisateur#

root@Utilisateur-Debian:/home/utilisateur# /usr/sbin/modprobe 
modprobe: ERROR: missing parameters. See -h.
root@Utilisateur-Debian:/home/utilisateur#
#122

Tu étais bien en root ?
Connecté avec su - (avec le tiret) ou lancé avec sudo ?

#123

root@Utilisateur-Debian:/home/utilisateur#

#124

Le répertoire courant n’a pas changé donc tu as probablement lancé su sans -, -l ou --login, ce qui n’initialise pas correctement l’environnement.

A part ça, vous n’avez pas l’impression de tourner en rond et de refaire le match d’il y a 15 jours ?

Pour espérer voir les logs du noyau lors d’un démarrage sans nomodeset, je vois deux moyens :

a) Se connecter par SSH depuis une autre machine via le réseau, ce qui suppose d’avoir une autre machine ayant un client SSH (openssh-client) en réseau avec la machine à problème et d’avoir installé un serveur SSH (openssh-server) sur la machine à problème, et que le noyau n’a pas complètement planté.

b) Démarrer sans nomodeset, noter l’heure précise, redémarrer avec nomodeset et examiner les logs du noyau à l’heure notée qui doivent se trouver dans /var/log/syslog ou /var/log/syslog.1.gz (compressé), en supposant que le noyau a pu écrire des logs.

#125

-# Passage en mode rapide #
Bon, je ne sais pas à quelle date le sujet a été ouvert (je ne sais pas comment on fait pour le savoir), mais j’ai cru comprendre que ça fait plusieurs semaines.
Ce qui serait bien est d’arriver à un résultat pour Noël, ou nouvel an au plus tard.

Déjà un très gros BIG Warning que tu dois garder en mémoire.
Lorsque tu ouvres un terminal, et que la ligne commence par root, tout ce que tu fais est extrêmement dangereux.
Etre en mode “root” n’est pas un usage normal et nominal.
Si tu oublies ça, tu vas avoir des problèmes: il y en a qui ont déjà essayé de ne pas comprendre.

Pour ce soir, peux-tu faire ça:

grep 1000 /etc/passwd
grep -m2 vmlinuz /boot/grub/grub.cfg

-# dans un terminal en mode !! “root” !!!

echo radeon >> /etc/initramfs-tools/modules
tail -1 /etc/initramfs-tools/modules
update-initramfs -u
lsinitramfs /initrd.img | grep radeon
sed -i '/timeout/s/=./=5/' /boot/grub/grub.cfg

Et reboot sans nomodeset pour voir ce que ça donne.

#126 
utilisateur@Utilisateur-Debian:~$ grep 1000 /etc/passwd
utilisateur:x:1000:1000:Utilisateur,,,:/home/utilisateur:/bin/bash
utilisateur@Utilisateur-Debian:~$ 

utilisateur@Utilisateur-Debian:~$ grep -m2 vmlinuz /boot/grub/grub.cfg
	linux	/boot/vmlinuz-4.19.0-6-amd64 root=UUID=af31f57f-e645-43ff-8252-cdf7cacc9640 ro  quiet
		linux	/boot/vmlinuz-4.19.0-6-amd64 root=UUID=af31f57f-e645-43ff-8252-cdf7cacc9640 ro  quiet
utilisateur@Utilisateur-Debian:~$

Après redémarrage, aucun changement, toujours écran noir

#127

Bizarre que ces retours soient vides. Tu es bien sûr ??

tail -1 /etc/initramfs-tools/modules

lsinitramfs /initrd.img | grep radeon

#128

Bon, silence très inquiétant sur la complétude des opérations…
Si tu as déjà supprimé des fichiers sous /etc/ considérant qu’ils étaient inutiles, ça va être très compliqué pour la suite. A part une réinstallation, “propre”, je ne vois pas.
Les seuls fichiers qui t’appartiennent en tant qu’utilisateur sont sous /home/utilisateur (tu as probablement manqué d’inspiration pour ton nom d’utilisateur qui est un peu trop générique voir ambigü).
Les autres fichiers système sous la racine (/), tu ne touches à rien si tu ne sais pas ce que tu fais.

On va donc faire très court pour éviter de prolonger le sujet jusqu’en 2020.

La carte RV280 ne doit pas poser de problèmes, les drivers radeon libres gérant très bien le legacy.
Juste un point connu: il peut arriver qu’il soit obligé de charger le module en amont du boot, ce que tu n’as pas pu faire puisque tu as visiblement supprimé des fichiers pour une raison X, Y, ou Z, peu importe.

Comme j’ai noté ceci: “En fait en faisant nomodeset, je n’ai aucun soucis.”, on va simplifier au max.

Tu ouvres un termnial en “root”, avec les plus extrêmes précautions, puis juste 2 commandes:

adduser utilisateur sudo
sed -i '/cdf7cacc9640/s/$/ nomodeset/' /boot/grub/grub.cfg

Et tu rebootes. Ok ? Fine ? game over ? Ou pas ?

#129

On regarde la date du premier message, dans le fil ou dans la liste des sujets : le 18 octobre, il y a 25 jours.

En quoi le résultat importe-t-il ?

Qu’attends-tu de cette manipulation ? Pour moi, inclure le module radeon dans l’initramfs ne va strictement rien apporter. Tout ce que ça va changer, c’est que le module sera chargé plus tôt et donc le problème se produira plus tôt.

Quels retours vides ? Les seuls retours que @SteveL a fournis ne sont pas vides.

Quel intérêt ? On sait déjà ce que fait le paramètre nomodeset. Si le but est de le rendre persistant, modifier directement grub.cfg n’est pas la bonne méthode. Encore moins avec des commandes cabalistiques que je ne laisserais pas un utilisateur inexpérimenté taper.

#130

De manière très succincte, quelques réponses qui seront utiles à Stevel, qui est le principal intéressé.

A quoi ça sert de connaître l’UID 1000 ?
L’UID (user identifier) 1000 est le premier user créé par l’installateur Debian.
Pour connaître le nom du /home/, le fichier /etc/passwd te donnera la réponse.
Comme je ne voyais que des commandes exécutées en mode root, j’ignorai le nom du user principal
Ça permet d’expliquer à Stevel que ses fichiers personnels doivent être sous /home/utilisateur/, et non pas sous /sys/ ou /etc/ ou /boot/.

A quoi ça sert de rajouter “nomodeset” dans le fichier /boot/grub/grub.cfg ?
C’est une commodité pour éviter d’avoir à taper ‘nomodeset’ à chaque boot, ce qui n’est pas toujours commode surtout si le timeout est très court… et qu’il faudra donc rebooter pour renter à la mano “nomodeset” à chaque fois.

Pour le reste et concernant les retours de commandes vides, et non pas celles qui ne sont pas vides, c’est plutôt Stevel qui pourra donner des explications.
Je crois avoir vu précédemment que des fichiers auraient été supprimés sous /etc/, ce qui est probablement l’explication.
Vu les tripatouillages que j’ai aperçus, il faudrait repartir d’une base propre pour vérifier l’amorçage en amont du module radeon, qui aurait normalement du se faire en 5 minutes, et non pas en 25 jours.

Mais il est clair que 25 jours pour traiter un sujet radeon legacy hyper classique, ça fait beaucoup trop, je pense que tout le monde est d’accord sur ce point.

#131

Tu n’as pas regardé assez attentivement. Le répertoire /home/utilisateur était visible dans le chemin courant du prompt.

Quel est le rapport avec l’objet de ce fil, à savoir le problème d’affichage ?

Et je répète que ce n’est pas la bonne méthode pour rendre une option de démarrage persistante, car ce fichier est régulièrement regénéré et toute modification manuelle est écrasée. Cf. mon message #21 mentionnant /etc/default/grub.

Où as-tu vu cela ? Je viens de parcourir la discussion, je n’ai rien lu de tel.
Les seuls tripatouillages, ce sont les tiens.

#132

Bonjour,
Je pense que le plus simple serait que je réinstalle encore une fois le système.
Je dois réinstaller la version amd64 ou la version i386 ?
J’ai les 2 versions qui sont des versions netinst.
Ce qui est étrange c’est que sur un autre pc, la version i386 fonctionne sans soucis.
Merci.

#133

Réponse déjà donnée il y a plusieurs semaines dans le même fil.

#134

Oui le amd64 mais comme cela ne fonctionne pas, je préférais redemander.

#135

Penser par toi-même et ne pas faire confiance à autrui est déjà une preuve que tu as grandement gagné en autonomie et bien assimilé certaines bases qui m’ont semblées fondamentales à rappeler pour éviter de grosses bêtises à l’avenir.
L’autre preuve est que tu n’as pas jugé utile de répondre à certains de mes messages, car tu as eu la bonne capacité d’estimer que mes demandes étaient parfaitement inutiles ou trop barbantes, et tu as sûrement raison.

Si tu souhaites essayer un jour le chargement en initramfs du module radeon, tu sais maintenant comment faire.
Je te donne juste un complément sur l’origine de l’information pour que ton dossier soit complet.

Bug 25607 - drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before
https://bugs.freedesktop.org/show_bug.cgi?id=25607

Je n’ose plus trop te demander de retour de commandes, mais je me permets de t’en donner 2 qui peuvent éventuellement être utiles, et dont tu peux garder secret le retour. Ça ne regarde personne. C’est ton PC.

lscpu | grep name
free -h

Félicitations pour ta témérité depuis bientôt 1 mois déjà, et bonne chance !

#136

La première commande ne donne rien

root@Utilisateur-Debian:~# free -h
              total        used        free      shared  buff/cache   available
Mem:          986Mi       574Mi        95Mi        55Mi       316Mi       219Mi
Swap:         1,0Gi        40Mi       981Mi
root@Utilisateur-Debian:~#
#137

Bon, je retente l’installation

#138

Installation terminée et toujours le même problème d’écran noir après le Grub.
Je viens effectué un apt update et upgrade

#139

Pendant l’installation, j’ai vu plusieurs fois : Error No UMS support In Radeon

#140

Essaye de démarrer avec radeon.dpm=0 au lieu de nomodeset