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#
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.
-# 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.
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
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.
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.
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.
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.
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
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 !