Xorg "générique" pour carte nvidia plus supportée

Support Debian
#1

Bonjour

Je viens de basculer un vénérable (10 ans) pc portable en D11.
Mauvaise surprise : la carte nvidia GeForce 9300M GS qui l’équipe n’a plus de pilote propriétaire supporté et le pilote libre « nouveau » est trop instable (gels fréquents).

J’ai donc banni « nouveau ». Le pc démarre et le serveur X aussi, quoiqu’avec une résolution inférieure (1280x720) à celle à laquelle j’étais habitué (1440x900) et en plus le désavantage que le rapport d’aspect semble légèrement différent de 1.

J’ai donc inséré les paramètres

GRUB_GFXMODE=1440x900
GRUB_GFXMODE=1440x900x32
GRUB_GFXPAYLOAD_LINUX=keep

dans /etc/default/grub et regénéré le fichier de configuration de grub en conséquence.

Au reboot, visuellement, j’ai récupéré une meilleure résolution, bien que je sois incapable de vérifier ce qu’elle est réellement.

Par contre, X ne démarre plus, avec le message d’erreur :

(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

Je ne sais pas très bien quoi faire pour résoudre ce problème : j’imagine qu’il faut que je crée un fichier de configuration adhoc mais je n’ai aucune idée de ce qu’il faut que j’y mette.

Pour info #X -configure crée un fichier de configuration … avec le pilote « nouveau » (et quelques erreurs), donc inutilisable.

Incidemment, il fut un temps où j’étais capable de modifier dynamiquement la résolution des terminaux textuels. J’ai malheureusement oublié comment je faisais. J’ai tenté d’installer le module uvesafb et de faire quelques manipulations avec fbset, mais le serveur X ne démarre pas non plus avec ce module et de plus la résolution que je vise n’est pas disponible.

Cordialement.

#2

As-tu essayé avec une clé USB ?

#3

Bonjour,

Je ne comprends pas ce que devrait contenir cette clef USB.

Cordialement.

#4

Un système Debian sur une clé USB pourrait détecter automatiquement les bons pilotes et paramètres.

#5

Bonjour,

Pourquoi un système sur une clef USB ferait-il mieux que le système installé sur le PC lui-même ?
D’autant plus qu’il risque de me proposer « nouveau » dont je ne veux plus.

Cordialement.

#6

Bonjour

Pourtant, j’en ai trouvé un pour la carte GeForce 9300M GS
sur le site officiel de NVIDIA : Linux x64 (AMD64/EM64T) Display Driver | 340.108 | Linux 64-bit | NVIDIA

#7

J’ai écrit « pourrait », c’est juste une piste.
Sinon, tu as nvidia-detect ?

#8

Bonsoir,

Je me suis mal exprimé : j’aurais du écrire « plus supporté par Debian ».

Je pourrais effectivement essayer de compiler moi-même ce support mais je crains que ce ne soit au delà de mes compétences immédiates.

À voir, si je ne parviens pas à forcer le Xorg de base à travailler en 1440x900.

Cordialement.

#9

Bonsoir,

Bien sûr, et sa réponse est :

    Detected NVIDIA GPUs:
    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98M [GeForce 9300M GS] [10de:06e9] (rev a1)

    Checking card:  NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1)
    Your card is only supported by the 340 legacy drivers series, which is only available up to buster.

Cordialement.

#10

En fait, le pilote accessible sur le site de NVIDIA est un fichier compressé téléchargeable, qui une fois décompressé devient un script qu’il faudra rendre exécutable afin de pouvoir lancer son exécution sur un système Linux pour que le pilote s’installe.
Il n’y a donc aucune compilation à faire.

Il faut :

  • Télécharger le fichier depuis le site de NVIDIA
  • Décompresser le fichier téléchargé
  • Rendre exécutable le fichier (script) décompressé
  • Fermer sa session graphique
  • Passer en console mode texte*** afin de pouvoir arrêter le gestionnaire de session graphique (gdm, lightdm, etc.)
  • Lancer le script NVIDIA (qui a été décompressé) depuis le compte root
  • suivre les instruction du script

De mémoire, le déroulement du script va faire tout ce qu’il faut et ne demandera de redémarrer la machine qu’une seule fois pour pouvoir terminer son installation.
Mais il ne faudra pas oublier, quand la machine aura redémarré, de ne surtout pas ouvrir une session graphique mais de passer directement en mode console texte afin de fermer le gestionnaire de session graphique (gdm, lightdm, etc.) pour pouvoir relancer le script qui va alors terminer son travail d’installation, et au démarrage suivant le pilote sera installé.

***Pour passer en console en mode texte depuis le gestionnaire de session graphique,
il faudra, suivant le gestionnaire de session,
utiliser un des raccourcis clavier Ctrl+Alt+F1 à Ctrl+Alt+F7

#11

Bonsoir,

Je veux bien concéder que le script fait tout, mais un bref coup d’œil sur le mode d’emploi m’a quelque peu effrayé : par exemple la possible nécessité de signer le module est déjà un point qui m’est complètement étranger.

Je tenterai toutefois l’opération un jour, par curiosité, sachant que j’ai résolu mon problème (voir message suivant).

Cordialement.

#12

Bonsoir,

J’ai résolu mon problème et j’expose la solution parce qu’elle pourrait intéresser d’autres personnes.

En examinant le journal d’Xorg qui me fournissait une résolution dégradée, j’ai constaté la présence de la ligne :

(II) VESA(0): Not using built-in mode "1440x900" (hsync out of range)

J’en ai conclu que la résolution était connue mais que le « moniteur » n’était pas capable de l’afficher car sa plage de fréquences horizontales (31,50 - 48 kHz) est insuffisante.

cvt m’a donné la fréquence nécessaire : 53,93 kHz pour 1440x900 en 60 Hz vertical.

J’ai donc concocté un petit xorg.conf sur mesure

Section "Screen"
        Identifier "Screen0"
        Monitor "Monitor0"
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 30-60 
#       Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync

EndSection

qui augmente la plage de synchronisation horizontale.

Bingo.

Cordialement.

#13

C’est effectivement effrayant.

Mais ça, c’est seulement si tu utilises un démarrage de ta machine en mode EFI secure boot*** et si tu utilises l’EFI secure il n’y aura pas que pour le pilote de ta carte graphique qu’il te faudra une signature.

Par contre, en mode legacy, tu n’auras besoin d’aucune signature.

La sécurité des systèmes Linux est reconnue depuis bien longtemps et n’a absolument pas besoin (très doux euphémisme) de l’EFI

*** EFI secure en deux lignes :
Tout système d’exploitation autre que Windows sera considéré comme un système malveillant.
Il devra demander (acheter) une autorisation (signature) pour pouvoir fonctionner sur un PC

Les spécifications de lUEFI (2540 pages) :

#14

Bonjour,

Voilà une nuance dont je n’étais pas conscient.

Merci de m’avoir éclairé sur ce point.

Cordialement.

#15

Très souvent, si les utilisateurs choisissent de garder leur machine avec un démarrage en mode EFI
c’est parce que windows était déjà installé sur leur machine en mode EFI
Donc, s’ils veulent garder leur système Windows installé et fonctionnel, il est plus simple pour eux d’installer les autres systèmes d’exploitation en mode EFI, ou alors il leur faut trouver le moyen de réinstaller leur système windows en mode legacy (je ne sais pas si on peut changer en legacy un système windows déjà installé en mode EFI ou s’il est possible de passer temporairement en mode legacy car toutes les machines ne respectent pas les standards EFI et legacy de la même façon)

Mais s’il n’y a encore aucun système installé en mode EFI sur la machine et que le mode legacy est possible, on peut installer tout un tas de systèmes Linux sur la même machine en mode legacy <=> pas besoin de signature(s)

La machine que j’utilise en ce moment a un système Windows 10 qui y avait été installé en mode legacy, et j’ai 6 systèmes linux installés en plus sur cette même machine en mode legacy <=> sans problèmes de signatures.

Voilà le choix que j’ai au démarrage de ma machine (Lenovo ThinkPad T450) :

Ceci dit, il existe aussi des machines sur lesquelles c’est impossible car on n’a pas le choix entre EFI ou legacy ou sur lesquelles le mode legacy n’existe pas ou ne respecte pas certains standards, mais elles sont (pour l’instant) encore assez rares.

#16

Bonjour,

Merci pour le complément d’information qui me rappelle à quel point j’ai galéré pour installer D11 sur mon autre PC. Et d’ailleurs, je ne sais pas pourquoi ça fonctionne.

Pour ma part, je ne conserve le Windows installé que pendant la durée de garantie matérielle, parce que le service après-vente du vendeur se fera un plaisir de la refuser si seul un linux est installé sur le système.

Cordialement.

#17

En effet, le mode EFi est plus destiné à des machiens dont la securité doit etrfe plus importante, le legacy etant moins bon.

#18

http://www.pc-boost.com/pages/news_1643873161_une-societe-de-securite-avertit-que-ces-failles-de-securite-majeures-du-bios-uefi-affectent-des-millions-d-appareils.html

Je n’ai pris que 9 des plus récents des liens très rapidement trouvés.

#19

OUi le problème c’est la securité du boot efi, mais si tu veux avoir certains actifs de sécurité tu es obligé d’etre en efi, c’est justement ça le probleme.
Les disques chiffrés permettent de palier au problème indirectement. Le secure boot en est un autre. Après les puces type Titan peuvent aussi aider.
Pour faie simple, appliquer la stratégie de défense en profondeur: ne pas se contenter d’une seule ligne de défense mais de plusieurs.
En fait les articles perlent à peu prêt tous de la même chose.
C’est le code UEFI qui est en cause,mais les article parlent d’un materiel ou un autre,d’entreprises ou d’autres.
Comme c’est à peu prêt le même code partout, l’importante quantité de machines concernées est logique.
Ceci dit aussi, ce n’est pas forcément aisé de l’exploiter. Car qui dit faille, ne dit pas toujorus exploitation de cette faille, et qui dit exploitation ne dit pas facilité non plus.
Une des dernière faille de Microsoft nécessite d’avoir accès à la machine physiquement, donc cela réduit la surface d’exposition.

#20

J’ai lu sur des forums (peut-être ici) que certains paramètres du noyau peuvent améliorer la stabilité du pilote nouveau, mais je ne les ai plus en tête.

EDIT: J’ai retrouvé init_on_alloc=0 mais il me semble qu’il y en a un autre.
EDIT2: L’autre paramètre mentionné est no_console_suspend mais je ne sais pas s’il est vraiment utile ou ne sert que pour le débogage

Les performances d’affichage vont être abominables avec le pilote générique VESA.
Est-ce le seul GPU ou y a-t-il un GPU intégré au chipset ou au CPU ? Dans ce cas il vaudrait mieux utiliser le GPU intégré avec les pilotes optimisés qui offriraient de biens meilleures performances.

Concernant l’UEFI, quelques mises au point.

En effet, cela concerne tout noyau ou module du noyau compilé localement, notamment les pilotes propriétaires virtualbox, r8168 pour cartes réseau Realtek, wl pour cartes wifi Broadcom…

Ni en mode UEFI sans secure boot. Apparemment il y a une certaine confusion entre secure boot et UEFI. Le secure boot n’est qu’une fonctionnalité optionnelle de l’UEFI.

L’UEFI en lui-même n’apporte aucune sécurité. C’est le secure boot qui apporte une certaine (très relative) sécurité.

C’est très grossièrement résumé mais assez vrai en pratique.
La théorie : le système doit être signé avec une clé reconnue par le firmware UEFI.
La pratique : les firmwares UEFI ne reconnaissent que la clé de Microsoft. Certains permettent d’enregistrer d’autres clés mais ce n’est pas toujours le cas.

Mais il n’est pas forcément nécessaire de laisser le secure boot activé (ça peut l’être, j’ai vu bitlocker bloquer le démarrage de Windows si le secure boot avait été désactivé).

Non, on peut seulement faire l’inverse, ce qui va au passage entraîner une conversion de la table de partition du disque système au format GPT (et probablement casser les éventuels autres systèmes présents).

Si tu veux dire passer en mode legacy pour booter Linux ou en mode EFI pour booter Windows, c’est possible du moment que le firmware UEFI supporte l’amorçage legacy.

Pas besoin de signature non plus en mode EFI sans secure boot. Et les systèmes ne s’écraseront pas le GRUB les uns des autres dans le MBR (par contre ils s’écraseront quand même le GRUB s’il sont de la même distribution).

Non, c’est le secure boot qui est censé apporter une sécurité, pas l’UEFI en lui-même.

Le chiffrement du disque ne répond pas au mêmes risques. Même avec un disque chiffré, l’amorçage lui-même n’est pas chiffré. Le secure boot a précisément pour but de protéger l’amorçage, mais pas ce qui se passe après. Les deux sont donc complémentaires.