Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
=c3
On 04/11/2018 04:14 PM, wrote:
Bonjour,
Bonjour André,
Depuis l'upgrade de Jessie vers Stretch, je n'arrive plus à faire fonctionner ma carte graphique AMD Radeon 6550M. Aussi, plus de fglrx sous stretch.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'année 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, qui n'a pas reçu de mise à jour depuis, d'où le manque de support. Le driver libre alternatif est le pilote radeon, les cartes gpu plus récentes peuvent aussi avoir besoin du pilote amdgpu: $ lsmod | grep radeon radeon
J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree" et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre votre problème. En espérant que ça aide, À plus, -- Étienne Mollier
On 04/11/2018 04:14 PM, andre_debian@numericable.fr wrote:
Bonjour,
Bonjour André,
Depuis l'upgrade de Jessie vers Stretch,
je n'arrive plus à faire fonctionner ma carte graphique
AMD Radeon 6550M.
Aussi, plus de fglrx sous stretch.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'année
2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx,
qui n'a pas reçu de mise à jour depuis, d'où le manque de support.
Le driver libre alternatif est le pilote radeon, les cartes gpu plus
récentes peuvent aussi avoir besoin du pilote amdgpu:
$ lsmod | grep radeon
radeon
J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree"
et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre
votre problème.
En espérant que ça aide,
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Depuis l'upgrade de Jessie vers Stretch, je n'arrive plus à faire fonctionner ma carte graphique AMD Radeon 6550M. Aussi, plus de fglrx sous stretch.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'année 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, qui n'a pas reçu de mise à jour depuis, d'où le manque de support. Le driver libre alternatif est le pilote radeon, les cartes gpu plus récentes peuvent aussi avoir besoin du pilote amdgpu: $ lsmod | grep radeon radeon
J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree" et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre votre problème. En espérant que ça aide, À plus, -- Étienne Mollier
andre_debian
On Wednesday 11 April 2018 19:55:55 Étienne Mollier wrote:
On 04/11/2018 04:14 PM, wrote: Bonjour André,
Depuis l'upgrade de Jessie vers Stretch, je n'arrive plus à faire fonctionner ma carte graphique AMD Radeon 6550M.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'ann ée 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, qui n'a pas reçu de mise à jour depuis, d'où le manque de support. Le driver libre alternatif est le pilote radeon, les cartes gpu plus récentes peuvent aussi avoir besoin du pilote amdgpu: $ lsmod | grep radeon radeon
Merci Étienne pour votre aide. $ lsmod | grep radeon ne répond rien.
J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfr ee" et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoud re votre problème.
J'ai bien installé le paquet "xserver-xorg-video-radeon", ainsi que le pilote "xserver-xorg-video-amdgpu".
En espérant que ça aide, À plus,
Oui, ça aide, bons tuyaux mais toujours pas de vidéo... :-) Il me semble avoir vu passer un mail sur la ML sur ce même sujet, il y a environ 6 mois, mais pas retrouvé... Bonne soirée, André
On Wednesday 11 April 2018 19:55:55 Étienne Mollier wrote:
On 04/11/2018 04:14 PM, andre_debian@numericable.fr wrote:
Bonjour André,
> Depuis l'upgrade de Jessie vers Stretch,
> je n'arrive plus à faire fonctionner ma carte graphique
> AMD Radeon 6550M.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'ann ée
2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx,
qui n'a pas reçu de mise à jour depuis, d'où le manque de support.
Le driver libre alternatif est le pilote radeon, les cartes gpu plus
récentes peuvent aussi avoir besoin du pilote amdgpu:
$ lsmod | grep radeon
radeon
Merci Étienne pour votre aide.
$ lsmod | grep radeon ne répond rien.
> J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfr ee"
> et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoud re
votre problème.
J'ai bien installé le paquet "xserver-xorg-video-radeon",
ainsi que le pilote "xserver-xorg-video-amdgpu".
En espérant que ça aide, À plus,
Oui, ça aide, bons tuyaux mais toujours pas de vidéo... :-)
Il me semble avoir vu passer un mail sur la ML sur ce même sujet,
il y a environ 6 mois, mais pas retrouvé...
On Wednesday 11 April 2018 19:55:55 Étienne Mollier wrote:
On 04/11/2018 04:14 PM, wrote: Bonjour André,
Depuis l'upgrade de Jessie vers Stretch, je n'arrive plus à faire fonctionner ma carte graphique AMD Radeon 6550M.
J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'ann ée 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, qui n'a pas reçu de mise à jour depuis, d'où le manque de support. Le driver libre alternatif est le pilote radeon, les cartes gpu plus récentes peuvent aussi avoir besoin du pilote amdgpu: $ lsmod | grep radeon radeon
Merci Étienne pour votre aide. $ lsmod | grep radeon ne répond rien.
J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfr ee" et "xserver-xorg-video-ati".
Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoud re votre problème.
J'ai bien installé le paquet "xserver-xorg-video-radeon", ainsi que le pilote "xserver-xorg-video-amdgpu".
En espérant que ça aide, À plus,
Oui, ça aide, bons tuyaux mais toujours pas de vidéo... :-) Il me semble avoir vu passer un mail sur la ML sur ce même sujet, il y a environ 6 mois, mais pas retrouvé... Bonne soirée, André
=c3
On 04/11/2018 08:38 PM, wrote:
$ lsmod | grep radeon ne répond rien.
Ça, ce n'est pas normal. Vous pouvez déjà vérifier deux points. Est-ce que le module radeon est bien configuré dans votre kernel : $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" CONFIG_DRM_RADEON=m Normalement le noyau par défaut de Debian devrait l'embarquer en tant que module comme dans la copie ci-dessus. Est ce que le module fglrx est toujour présent ? $ lsmod | grep fglrx Si oui, les deux pilotes sont probablement en conflit et il faut évacuer toute trace du pilote propriétaire. Le désinstaller et redémarrer devrait suffire. À plus, -- Étienne Mollier
On 04/11/2018 08:38 PM, andre_debian@numericable.fr wrote:
$ lsmod | grep radeon ne répond rien.
Ça, ce n'est pas normal. Vous pouvez déjà vérifier deux points.
Est-ce que le module radeon est bien configuré dans votre kernel :
Normalement le noyau par défaut de Debian devrait l'embarquer en
tant que module comme dans la copie ci-dessus.
Est ce que le module fglrx est toujour présent ?
$ lsmod | grep fglrx
Si oui, les deux pilotes sont probablement en conflit et il faut
évacuer toute trace du pilote propriétaire. Le désinstaller et
redémarrer devrait suffire.
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Ça, ce n'est pas normal. Vous pouvez déjà vérifier deux points. Est-ce que le module radeon est bien configuré dans votre kernel : $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" CONFIG_DRM_RADEON=m Normalement le noyau par défaut de Debian devrait l'embarquer en tant que module comme dans la copie ci-dessus. Est ce que le module fglrx est toujour présent ? $ lsmod | grep fglrx Si oui, les deux pilotes sont probablement en conflit et il faut évacuer toute trace du pilote propriétaire. Le désinstaller et redémarrer devrait suffire. À plus, -- Étienne Mollier
andre_debian
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
On 04/11/2018 08:38 PM, wrote:
$ lsmod | grep radeon ne répond rien.
Ça, ce n'est pas normal. Vous pouvez déjà vérifier d eux points. Est-ce que le module radeon est bien configuré dans votre kernel : $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" CONFIG_DRM_RADEON=m
Je reçois la réponse : "aucun fichier ou dossier de ce type"
Normalement le noyau par défaut de Debian devrait l'embarquer en tant que module comme dans la copie ci-dessus. Est ce que le module fglrx est toujour présent ? $ lsmod | grep fglrx
Si oui, les deux pilotes sont probablement en conflit et il faut évacuer toute trace du pilote propriétaire. Le désinstall er et redémarrer devrait suffire. À plus,
Ni radeon ni fglrx ne semblent installés, Je suis perdu... Vais je devoir retourner à Jessie ? Bonne fin de soirée, André
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
On 04/11/2018 08:38 PM, andre_debian@numericable.fr wrote:
> $ lsmod | grep radeon ne répond rien.
Ça, ce n'est pas normal. Vous pouvez déjà vérifier d eux points.
Est-ce que le module radeon est bien configuré dans votre kernel :
Je reçois la réponse : "aucun fichier ou dossier de ce type"
Normalement le noyau par défaut de Debian devrait l'embarquer en
tant que module comme dans la copie ci-dessus.
Est ce que le module fglrx est toujour présent ?
$ lsmod | grep fglrx
Aucune réponse.
# apt-cache search fglrx
Aucune réponse;
Si oui, les deux pilotes sont probablement en conflit et il faut
évacuer toute trace du pilote propriétaire. Le désinstall er et
redémarrer devrait suffire. À plus,
Ni radeon ni fglrx ne semblent installés,
Je suis perdu...
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
On 04/11/2018 08:38 PM, wrote:
$ lsmod | grep radeon ne répond rien.
Ça, ce n'est pas normal. Vous pouvez déjà vérifier d eux points. Est-ce que le module radeon est bien configuré dans votre kernel : $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" CONFIG_DRM_RADEON=m
Je reçois la réponse : "aucun fichier ou dossier de ce type"
Normalement le noyau par défaut de Debian devrait l'embarquer en tant que module comme dans la copie ci-dessus. Est ce que le module fglrx est toujour présent ? $ lsmod | grep fglrx
Si oui, les deux pilotes sont probablement en conflit et il faut évacuer toute trace du pilote propriétaire. Le désinstall er et redémarrer devrait suffire. À plus,
Ni radeon ni fglrx ne semblent installés, Je suis perdu... Vais je devoir retourner à Jessie ? Bonne fin de soirée, André
andre_debian
On Wednesday 11 April 2018 22:48:20 wrote: Ça s'améliore mais avec des pépins : J'ai supprimé et purgé tous les pilotes xserver-xorg-video et réinstallé ceux ci : xserver-xorg-video-radeon xserver-xorg-video-ati lsmod | grep radeon m'affiche bien que le firmware radeon est actif. Strecth lance bien le bureau graphique (trinity), sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ? Merci... André
On Wednesday 11 April 2018 22:48:20 andre_debian@numericable.fr wrote:
Ça s'améliore mais avec des pépins :
J'ai supprimé et purgé tous les pilotes xserver-xorg-video
et réinstallé ceux ci :
xserver-xorg-video-radeon
xserver-xorg-video-ati
lsmod | grep radeon
m'affiche bien que le firmware radeon est actif.
Strecth lance bien le bureau graphique (trinity),
sauf que je n'ai aucune liaison souris + clavier.
On Wednesday 11 April 2018 22:48:20 wrote: Ça s'améliore mais avec des pépins : J'ai supprimé et purgé tous les pilotes xserver-xorg-video et réinstallé ceux ci : xserver-xorg-video-radeon xserver-xorg-video-ati lsmod | grep radeon m'affiche bien que le firmware radeon est actif. Strecth lance bien le bureau graphique (trinity), sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ? Merci... André
andre_debian
On Thursday 12 April 2018 12:31:10 wrote:
Strecth lance bien le bureau graphique (trinity), sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ?
Il suffisait de taper : # dpkg-reconfigure xserver-xorg pour récupérer la connexion souris + clavier en mode graphique. Seule déception, plus de configurations de la carte ATI en mode graphique mais console, plus abscons. Dépannage fastidieux mais instructif. André
On Thursday 12 April 2018 12:31:10 andre_debian@numericable.fr wrote:
Strecth lance bien le bureau graphique (trinity),
sauf que je n'ai aucune liaison souris + clavier.
Comment rétablir ma connexion souris + clavier ?
Il suffisait de taper :
# dpkg-reconfigure xserver-xorg
pour récupérer la connexion souris + clavier en mode graphique.
Seule déception, plus de configurations de la carte ATI
en mode graphique mais console, plus abscons.
Strecth lance bien le bureau graphique (trinity), sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ?
Il suffisait de taper : # dpkg-reconfigure xserver-xorg pour récupérer la connexion souris + clavier en mode graphique. Seule déception, plus de configurations de la carte ATI en mode graphique mais console, plus abscons. Dépannage fastidieux mais instructif. André
=c3
Bonsoir, Si on recoud la résolution... André, le 2018-04-11, à 22:48 (CEST) :
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa configuration correspondante dans /boot, mais bon, admettons, je suis peut-être passé à côté de la convention de nommage, à vouloir faire le malin avec de la détection automatique...
$ lsmod | grep fglrx
Aucune réponse.
Donc finalement ce n'était peut-être pas dû à un conflit entre les deux pilotes.
Ni radeon ni fglrx ne semblent installés, Je suis perdu...
...moi aussi... André, le 2018-04-12 à 00:31 (CEST) :
J'ai supprimé et purgé tous les pilotes xserver-xorg-video et réinstallé ceux ci : xserver-xorg-video-radeon xserver-xorg-video-ati lsmod | grep radeon m'affiche bien que le firmware radeon est actif. Strecth lance bien le bureau graphique (trinity),
C'est vrai que faire table rase, ça aide à y voir plus clair. Bon réflexe
sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ?
André, le 2018-04-12 à 00:31 (CEST) :
Il suffisait de taper : # dpkg-reconfigure xserver-xorg pour récupérer la connexion souris + clavier en mode graphique.
On dirait que le(s) fichier(s) de configuration rattaché aux entrées, probablement défini dans le paquet xserver-xorg, à sauté pendant la purge des paquets. La commande est intéressante, à garder en tête si d'aventure ça se reproduit.
Seule déception, plus de configurations de la carte ATI en mode graphique mais console, plus abscons.
Il y a probablement un outil dédié à la gestion de l'affichage dans TDE. Si ce n'est pas le cas, lxrandr, emprunté au bureau LXDE, devrait faire l'affaire. Il est basique, mais moins abscons que la commande xrandr et ses 65535 options. Après un rapide test pour changer de résolution, il n'y a pas de problèmes à signaler ; je n'ai pas eu l'occasion de tester avec plusieurs écrans cependant.
Dépannage fastidieux mais instructif.
J'imagine vu les dates des courriels. Content que ce soit tombé en marche et que ça ait pu enseigner quelque chose au passage. :-) À plus, -- Étienne Mollier
Bonsoir,
Si on recoud la résolution...
André, le 2018-04-11, à 22:48 (CEST) :
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa
configuration correspondante dans /boot, mais bon, admettons, je
suis peut-être passé à côté de la convention de nommage, à
vouloir faire le malin avec de la détection automatique...
$ lsmod | grep fglrx
Aucune réponse.
Donc finalement ce n'était peut-être pas dû à un conflit entre
les deux pilotes.
Ni radeon ni fglrx ne semblent installés,
Je suis perdu...
...moi aussi...
André, le 2018-04-12 à 00:31 (CEST) :
J'ai supprimé et purgé tous les pilotes xserver-xorg-video
et réinstallé ceux ci :
xserver-xorg-video-radeon
xserver-xorg-video-ati
lsmod | grep radeon
m'affiche bien que le firmware radeon est actif.
Strecth lance bien le bureau graphique (trinity),
C'est vrai que faire table rase, ça aide à y voir plus clair.
Bon réflexe
sauf que je n'ai aucune liaison souris + clavier.
Comment rétablir ma connexion souris + clavier ?
André, le 2018-04-12 à 00:31 (CEST) :
Il suffisait de taper :
# dpkg-reconfigure xserver-xorg
pour récupérer la connexion souris + clavier en mode graphique.
On dirait que le(s) fichier(s) de configuration rattaché aux
entrées, probablement défini dans le paquet xserver-xorg, à sauté
pendant la purge des paquets. La commande est intéressante, à
garder en tête si d'aventure ça se reproduit.
Seule déception, plus de configurations de la carte ATI
en mode graphique mais console, plus abscons.
Il y a probablement un outil dédié à la gestion de l'affichage
dans TDE. Si ce n'est pas le cas, lxrandr, emprunté au bureau
LXDE, devrait faire l'affaire. Il est basique, mais moins
abscons que la commande xrandr et ses 65535 options. Après un
rapide test pour changer de résolution, il n'y a pas de problèmes
à signaler ; je n'ai pas eu l'occasion de tester avec plusieurs
écrans cependant.
Dépannage fastidieux mais instructif.
J'imagine vu les dates des courriels. Content que ce soit tombé
en marche et que ça ait pu enseigner quelque chose au passage.
:-)
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa configuration correspondante dans /boot, mais bon, admettons, je suis peut-être passé à côté de la convention de nommage, à vouloir faire le malin avec de la détection automatique...
$ lsmod | grep fglrx
Aucune réponse.
Donc finalement ce n'était peut-être pas dû à un conflit entre les deux pilotes.
Ni radeon ni fglrx ne semblent installés, Je suis perdu...
...moi aussi... André, le 2018-04-12 à 00:31 (CEST) :
J'ai supprimé et purgé tous les pilotes xserver-xorg-video et réinstallé ceux ci : xserver-xorg-video-radeon xserver-xorg-video-ati lsmod | grep radeon m'affiche bien que le firmware radeon est actif. Strecth lance bien le bureau graphique (trinity),
C'est vrai que faire table rase, ça aide à y voir plus clair. Bon réflexe
sauf que je n'ai aucune liaison souris + clavier. Comment rétablir ma connexion souris + clavier ?
André, le 2018-04-12 à 00:31 (CEST) :
Il suffisait de taper : # dpkg-reconfigure xserver-xorg pour récupérer la connexion souris + clavier en mode graphique.
On dirait que le(s) fichier(s) de configuration rattaché aux entrées, probablement défini dans le paquet xserver-xorg, à sauté pendant la purge des paquets. La commande est intéressante, à garder en tête si d'aventure ça se reproduit.
Seule déception, plus de configurations de la carte ATI en mode graphique mais console, plus abscons.
Il y a probablement un outil dédié à la gestion de l'affichage dans TDE. Si ce n'est pas le cas, lxrandr, emprunté au bureau LXDE, devrait faire l'affaire. Il est basique, mais moins abscons que la commande xrandr et ses 65535 options. Après un rapide test pour changer de résolution, il n'y a pas de problèmes à signaler ; je n'ai pas eu l'occasion de tester avec plusieurs écrans cependant.
Dépannage fastidieux mais instructif.
J'imagine vu les dates des courriels. Content que ce soit tombé en marche et que ça ait pu enseigner quelque chose au passage. :-) À plus, -- Étienne Mollier
andre_debian
On Thursday 12 April 2018 19:42:40 Étienne Mollier wrote:
Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa configuration correspondante dans /boot, mais bon, admettons, je suis peut-être passé à côté de la convention de nommage, à vouloir faire le malin avec de la détection automatique...
Bonjour, merci pour votre aide qui m'a aidé. "/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type" Pourtant, j'ai bien ce fichier dans mon répertoire /boot : /boot/config-4.9.0-6-686-pae Y a t-il une erreur dans la commande ? : grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" et faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ? Bonne journée, André
On Thursday 12 April 2018 19:42:40 Étienne Mollier wrote:
>> $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
>> CONFIG_DRM_RADEON=m
> Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa
configuration correspondante dans /boot, mais bon, admettons, je
suis peut-être passé à côté de la convention de nommage, à
vouloir faire le malin avec de la détection automatique...
Bonjour, merci pour votre aide qui m'a aidé.
"/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type"
Pourtant, j'ai bien ce fichier dans mon répertoire /boot :
/boot/config-4.9.0-6-686-pae
Y a t-il une erreur dans la commande ? :
grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
et
faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?
Je reçois la réponse : "aucun fichier ou dossier de ce type"
C'est curieux que le noyau en cours d'exécution n'ait pas sa configuration correspondante dans /boot, mais bon, admettons, je suis peut-être passé à côté de la convention de nommage, à vouloir faire le malin avec de la détection automatique...
Bonjour, merci pour votre aide qui m'a aidé. "/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type" Pourtant, j'ai bien ce fichier dans mon répertoire /boot : /boot/config-4.9.0-6-686-pae Y a t-il une erreur dans la commande ? : grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" et faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ? Bonne journée, André
=c3
Bonsoir, André, le vendredi 13 avril 2018 :
"/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type" Pourtant, j'ai bien ce fichier dans mon répertoire /boot : /boot/config-4.9.0-6-686-pae
À ma connaissance, la seule manière d'avoir un fichier absent, mais présent en apparence, est d'avoir un lien symbolique brisé, une sorte de raccourci vers un fichier qui n'existerait plus. Si c'est le cas, ça devrait se voir en faisant un : $ ls -l /boot/config-4.9.0-6-686-pae Ou bien, si la commande précédente est récalcitrante : $ ls -l /boot Dans le doute, est ce que le système de fichier hébergeant le /boot/ est plein ? Chez moi il n'y a pas de problèmes, du moins pas apparents, et le système de fichier sous-jacent est rempli à 86% par exemple : $ df /boot/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda7 13889020 11186404 1974040 86% / On a vu plus d'une erreur bizarre causée au final par un disque plein...
Y a t-il une erreur dans la commande ? : grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" et faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?
Il y a à priori pas d'erreur dans la commande, et la chaîne "CONFIG_DRM_RADEON=m" aurait dû être le résultat, donc pas à taper. Vous avez correctement interprété le contenu de mon courriel initial. :-) L'idée était d'utiliser "grep" pour trouver toutes les lignes contenant "CONFIG_DRM_RADEON=" dans le fichier de configuration de la compilation du noyau "/boot/config-<version>", où la version était obtenue dynamiquement avec la commande "uname -r", injectée à la fin du nom de fichier avec la syntaxe propre à bash en "$(commande)". Avec ce genre de commande et de fichier, les quatre résultats possible sont : 1. CONFIG_DRM_RADEON=m : devrait apparaitre avec le noyau 4.9.0-6-686-pae par défaut ; 2. CONFIG_DRM_RADEON=y : apparait quand pilote radeon a été compilé en statique, au lieu d'être un module dynamique ; 3. pas de résultat affiché : le noyau n'a pas été configuré pour embarquer le pilote ; 4. erreur : le fichier de configuration n'a pas pu être lu, pour une raison quelconque. Nous sommes dans le cas numéro quatre. À plus, -- Étienne Mollier
Bonsoir,
André, le vendredi 13 avril 2018 :
"/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type"
Pourtant, j'ai bien ce fichier dans mon répertoire /boot :
/boot/config-4.9.0-6-686-pae
À ma connaissance, la seule manière d'avoir un fichier absent,
mais présent en apparence, est d'avoir un lien symbolique brisé,
une sorte de raccourci vers un fichier qui n'existerait plus. Si
c'est le cas, ça devrait se voir en faisant un :
$ ls -l /boot/config-4.9.0-6-686-pae
Ou bien, si la commande précédente est récalcitrante :
$ ls -l /boot
Dans le doute, est ce que le système de fichier hébergeant le
/boot/ est plein ? Chez moi il n'y a pas de problèmes, du moins
pas apparents, et le système de fichier sous-jacent est rempli à
86% par exemple :
$ df /boot/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7 13889020 11186404 1974040 86% /
On a vu plus d'une erreur bizarre causée au final par un disque
plein...
Y a t-il une erreur dans la commande ? :
grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
et
faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?
Il y a à priori pas d'erreur dans la commande, et la chaîne
"CONFIG_DRM_RADEON=m" aurait dû être le résultat, donc pas à
taper. Vous avez correctement interprété le contenu de mon
courriel initial. :-)
L'idée était d'utiliser "grep" pour trouver toutes les lignes
contenant "CONFIG_DRM_RADEON=" dans le fichier de configuration
de la compilation du noyau "/boot/config-<version>", où la
version était obtenue dynamiquement avec la commande "uname -r",
injectée à la fin du nom de fichier avec la syntaxe propre à bash
en "$(commande)".
Avec ce genre de commande et de fichier, les quatre résultats
possible sont :
1. CONFIG_DRM_RADEON=m : devrait apparaitre avec le noyau
4.9.0-6-686-pae par défaut ;
2. CONFIG_DRM_RADEON=y : apparait quand pilote radeon a été
compilé en statique, au lieu d'être un module dynamique ;
3. pas de résultat affiché : le noyau n'a pas été configuré pour
embarquer le pilote ;
4. erreur : le fichier de configuration n'a pas pu être lu, pour
une raison quelconque.
Nous sommes dans le cas numéro quatre.
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
"/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type" Pourtant, j'ai bien ce fichier dans mon répertoire /boot : /boot/config-4.9.0-6-686-pae
À ma connaissance, la seule manière d'avoir un fichier absent, mais présent en apparence, est d'avoir un lien symbolique brisé, une sorte de raccourci vers un fichier qui n'existerait plus. Si c'est le cas, ça devrait se voir en faisant un : $ ls -l /boot/config-4.9.0-6-686-pae Ou bien, si la commande précédente est récalcitrante : $ ls -l /boot Dans le doute, est ce que le système de fichier hébergeant le /boot/ est plein ? Chez moi il n'y a pas de problèmes, du moins pas apparents, et le système de fichier sous-jacent est rempli à 86% par exemple : $ df /boot/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda7 13889020 11186404 1974040 86% / On a vu plus d'une erreur bizarre causée au final par un disque plein...
Y a t-il une erreur dans la commande ? : grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" et faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?
Il y a à priori pas d'erreur dans la commande, et la chaîne "CONFIG_DRM_RADEON=m" aurait dû être le résultat, donc pas à taper. Vous avez correctement interprété le contenu de mon courriel initial. :-) L'idée était d'utiliser "grep" pour trouver toutes les lignes contenant "CONFIG_DRM_RADEON=" dans le fichier de configuration de la compilation du noyau "/boot/config-<version>", où la version était obtenue dynamiquement avec la commande "uname -r", injectée à la fin du nom de fichier avec la syntaxe propre à bash en "$(commande)". Avec ce genre de commande et de fichier, les quatre résultats possible sont : 1. CONFIG_DRM_RADEON=m : devrait apparaitre avec le noyau 4.9.0-6-686-pae par défaut ; 2. CONFIG_DRM_RADEON=y : apparait quand pilote radeon a été compilé en statique, au lieu d'être un module dynamique ; 3. pas de résultat affiché : le noyau n'a pas été configuré pour embarquer le pilote ; 4. erreur : le fichier de configuration n'a pas pu être lu, pour une raison quelconque. Nous sommes dans le cas numéro quatre. À plus, -- Étienne Mollier
