Problème carte nvidia sur Trixie (ou bootloader ? Kernel ? autre ?)

(je sais qu’il y a un sujet sur les problèmes de migration, mais je ne sais pas s’il recense juste les problèmes ou est censé accueillir les solutions. J’ouvre un nouveau sujet au cas où la solution ne soit pas si simple. Ne pas hésiter à le fusionner dans l’autre sujet si c’est pertinent)

J’ai essayé de migrer de bookworm à trixie, X ne démarrait plus; Apparemment le problème venait de ma carte nvidia un peu ancienne, nvidia GeForce GT 710.
Après plusieurs manipulations infructueuses en suivant le wiki debian (NvidiaGraphicsDrivers - Debian Wiki , j’ai tenté la version 535.216.03), je me suis résigné à réinstaller une Trixie de zéro… sans succès, et idem avec une Bookworm.

Quelqu’un saurait-il comment je peux installer le bon driver nvidia, sur une Trixie tant qu’à y être ?

PS : Actuellement je suis sur une bookworm cassée en résolution 1024x768, je ne parviens pas à y installer le driver. Le driver « nouveau » provoque des freeze sur ma machine.

Bonjour,

Sur le site NVdia le pilote 535.216.03 n’est pas supporté au delà de Debian 10.3. (Version 535.216.03(Linux) :: NVIDIA Data Center GPU Driver Documentation)

Vu l’age de ta carte NVIDIA, pourquoi ne pas utiliser nouveau? c’est largement suffisant.

As-tu Secure Boot d’activé?

Concernant les pilotes NVIDIA, sur nvidia.fr c’est la version 390.157 qui est indiquée, ou en 396.18 pour le pilote Bêta.

Et sur Appendix A. Supported NVIDIA GPU Products

Indiqué par le wiki Debian, c’est le 470.xx

Sur Trixie quand tu fait nvidia-detect quelle est la réponse optenue?

Merci pour ta réponse

Parce que le pc freeze. Ça marche « bien » (quoique l’affichage presente quelques glitches) quelques dizaines de secondes et ça gèle.

Non. Du moins je ne crois pas, je ne crois pas en avoir jamais entendu parler avant aujourd’hui. :grinning_face_with_smiling_eyes:

J’écris ça de mémoire, donc à prendre avec des pincettes, qqch comme « la carte GeForce GT 710 n’est plus supportée il faut utiliser le driver legacy ». Mais où le trouver et comment l’installer ?

Je viens de tenter autre chose, j’ai installé une bookworm minimale sans X, upgradée en trixie. Dans l’espoir d’installer le driver 535 (mais du coup ça semble vain ?). Apres reboot sur le nouveau noyau, la machine reboote avant que j’aie eu le temps de taper une commande…

Non pour installer NVIDIA, il faut passer par nvidia-detect:
apt install nvidia-detect
ensuite il te dit quel pilote installer.
Et accessoirement dans ton cas:
apt install nvidia-legacy-check

Quand à nouveau s’il freeze, il faut aller vois les logs pour savoir pourquoi

Il y a du neuf. Je viens de faire deux essais:

  • installation d’une trixie de zero sur une partition.
    Installation de base, sans environnement graphique, juste les utilitaires de base. On ne parle pas d’installer les drivers nvidia.
    Quand je veux ouvrir une session en console, ça fige et le pc reboote tout seul comme un grand.

  • installation d 'une bookworm sur une autre partition. Essai sous X avec nouveau, ça freeze . Je ne sais pas comment récupérer les logs (les fichiers auxquels j’étais habitué n’existent plus, merci systemd)
    J’ai suivi tes indications :

Et là nickel, j’ai installé le driver tesla 470, j’ai de nouveau une bookworm fonctionnelle, j’écris en ce moment depuis celle-ci. Au moins je peux utiliser mon pc.

Par contre pour la trixie je ne sais pas comment faire. Est-ce même un problème lié à la carte graphique ? Possible mais pas si sûr en fait. (edit : même si c’est plausible, on voit un léger « glitch » à l’écran juste avant le reboot)

sur la trixie en fait, ça reboote quand ça veut, ce n’est pas lié à l’ouverture de la session. Parfois c’est avant, parfois j’ai le temps de taper une commande…
Et aussi, juste après le menu de grub, quand le système démarre j’ai des messages d’erreur, voir photo jointe. Je ne sais pas si ça a un rapport avec mes soucis mais je n’ai pas vu ça avec des noyaux plus anciens.
IMG_20250814_203406_resized_20250814_083643865

Il est donc inutile de t’acharner sur nvidia pour le moment.
La priorité est de clarifier le plantage amd_pstate.
• Le paquet power-profiles-daemon a-t-il été installé ?
• Le CPU est à quelle température ? (soit par accès BIOS, ou à la louche pour le moment).
• Le BIOS est-il à jour ?
Tu as peut-être une erreur du genre:

kernel: amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

Voir si l’ACPI est activé dans le BIOS.
Concernant nvidia, l’étape d’après, commence par observer le comportement avec le driver nouveau (par défaut).

nvidia-tesla-470-driver n’est plus disponible pour trixie (470 → legacy), mais si vraiment estimé nécessaire, il réapparait étonnament en SID. Il y aurait donc éventuellement moyen de s’arranger de manière expérimentale.
nvidia-tesla-470-driver SID

merci pour ta réponse.

non mais je viens de le faire (via un chroot sinon ce n’était pas possible). Le comportement reste identique.

autour de 40°

j’ai cherché mais je ne vois pas de mention de l’acpi

Sans doute que non, je ne l’ai jamais mis à jour depuis l’achat du pc en 2020

Pour l’erreur que tu mentionnes je ne la vois pas, elle apparaîtrait à quel moment ?

ah oui ça c’est surprenant. Il y a peut être espoir qu’il arrive en testing à un moment donné ? (je suis

réticent à installer une sid mais la migration de mon systeme en testing est envisageable)

J’ai réussi à récupérer la sortie de dmesg dans un fichier avant que ça plante, je mets ça en pièce jointe.
dmsg.txt (82,1 Ko)

Difficile d’estimer si finalement amd_pstate est un problème majeur ou pas, mais à surveiller de près. Rien de transcendant dans le dmesg.
Mettre à jour un BIOS n’est pas une opération agréable, mais ça ne ferait pas de mal (si ça se passe bien…).

Pour l’erreur que tu mentionnes je ne la vois pas, elle apparaîtrait à quel moment ?

C’était une hypothèse anticipée, vue pour d’autres problèmes amd_pstate, qui touche à la gestion d’énergie, de cpu_freq.

Unknown kernel command line parameters « single dis_ucode_ldr BOOT_IMAGE=/boot/vmlinuz-6.12.41+deb13-amd64 », will be passed to user space.

Utilises-tu les options de grub faites par l’installation (-> option dis_ucode_ldr) ?

Si tu arrêtes grub au lancement, et modifies les options de noyau avec seulement ‹ ro single ›, tu dois arriver à la console de boot système qui demande le mot de passe root. Nvidia n’a rien à faire jusqu’à ce niveau.
As-tu un mot de passe root ? Si non, comme tu accèdes en chroot, il faudrait l’ajouter pour être sûr d’avoir un comportement nominal de l’option single, pour y voir plus clair.

Tiens c’est marrant, ça. Non je ne la lance pas avec ces options, mais avec « ro quiet ».
Je pense que ce que j’ai dans le dmesg doit correspondre à un moment où je l’ai lancée en mode recovery…
Ceci dit ça plante pareil dans les deux cas.

(edit : Et oui j’ai mis le même mot de passe root sur la bookworm et la trixie. Je me suis servi du chroot juste pour installer le package)

j’avoue que je suis assez réticent :grinning_face_with_smiling_eyes: :cold_sweat: je sais que dans la pratique en général ça se passe bien… Mais à tout hasard il y a moyen de restaurer une version antérieure si ça se passe mal ou c’est retour usine obligatoire ?

Ça t’ennuies d’essayer ‹ ro single › ?
Avec single, tu vois au moins ce qui se passe à l’écran lors du boot, des messages éventuellement en rouge.
Si vraiment tu n’arrives pas à rentrer ton mot de passe root sans même arriver à la console système, ça va être plus embettant.

non non ça ne m’embête pas. :wink:
Je vois apparaitre un msg au milieu de l’écran :
EFI Stub Loaded initrd from LINUx_EFI_INITRD_MEDIA_GUID device path

ensuite je vois les messages se dérouler, mais rien de spécial ne me saute aux yeux.

c’est ce qui arrive :neutral_face: ça plante pareil. Je vais tenter une mise à jour du bios. En croisant les doigts…
Screenshot_20250815-115746

Donc ‹ single › a permit de pointer EFIStub.
Si efibootmgr n’est pas installé, essayer avec.
Voir aussi si différence avec ou sans secure-boot.

Plus, un peu de lecture…: EFIStub, pour investigation, et se mettre en condition.

Manually setting up EFIStub

To set up EFIStub, you need to first copy the kernel and initrd into the EFI system partition, then set up an EFI boot entry for it.
…/…

Je vais regarder ça, je ne connais pas. C’est une nouveauté sur trixie ?
Actuellement j’ai cela, mais à l’install je n’ai pas touché à cette partition, ça peut être une source de problème, non ?

ls /boot/efi/EFI/debian/ -lha
total 4,4M
drwx------ 2 root root 4,0K 8 déc. 2020 .
drwx------ 4 root root 4,0K 14 août 18:58 …
-rwx------ 1 root root 108 14 août 20:16 BOOTX64.CSV
-rwx------ 1 root root 86K 14 août 20:16 fbx64.efi
-rwx------ 1 root root 126 14 août 20:16 grub.cfg
-rwx------ 1 root root 2,6M 14 août 20:16 grubx64.efi
-rwx------ 1 root root 831K 14 août 20:16 mmx64.efi
-rwx------ 1 root root 935K 14 août 20:16 shimx64.efi

Sinon j’ai essayé entre temps de passer le parametre amd_pstate=disable au démarrage. Les messages d’erreur disparaissent, mais ça plante quand même ensuite.

je peine à voir l’intérêt d’efistub, ça apporte quoi en plus de grub (qui est installé sur la trixie) ?
ça pourrait être la cause de mes ennuis ?

Sinon j’ai flashé mon bios et je n’ai plus les erreurs amd_pstate. J’ai une erreur au démarrage de la bookworm mais ça fonctionne toujours, visiblement.

C’est déjà ça de gagné.
Concernant le boot, je n’utilise jamais d’installation automatique, mais gère toujours un loader de manière indépendante du système.
C’est trop délicat pour laisser un automatisme gérer ça (mon avis).
Je ne sais donc pas exactement comment un installateur Debian procède, particulièrement en UEFI, mais il doit commencer par détecter l’environnement et faire ce qu’il peut en fonction.

Je t’ai posé la question si tu voyais une différence avec ou sans secure-boot. Pas vu la réponse.
Ce que je ferais, c’est une réinstallation du loader (grub ou autre ?) à partir d’un chroot, pour voir comment ça cause.

je n’utilise pas secure-boot.
Je vais me pencher sur la question du boot loader, mais ce ne sera sans doute pas avant la semaine prochaine. (Et ça va me prendre un peu de temps, ça fait un moment que je n’ai pas joué avec ça. D’habitude ce qui est fait par défaut fonctionne bien pour moi)

edit : je viens de démarrer la bookworm avec le parametre « ro » au lieu de « ro quiet » et je m’aperçois que j’ai aussi les messages sur EFI stub :no_mouth:

J’ai vu passer ça hier, un « text installer » pour Trixie. Ça ne supporte pas les cartes Tesla, mais ce n’est pas le cas la tienne me semble-t-il ??

@ricecooker
La bonne nouvelle est que le message 'EFI stub ’ n’est pas un message d’erreur, mais juste une information générée par le kernel:

if (status == EFI_SUCCESS) {
	efi_info("Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path\n");

grep HANDOVER /boot/config*
CONFIG_EFI_HANDOVER_PROTOCOL=y

Le point pas clair est que le protocole ‹ EFI handover › semble déprécié.

Reste à clarifier exactement où coince le boot.
Pour booter en console, le loader a besoin de 3 choses:
→ trouver les fichiers vmlinuz + initrd.img du système à booter, et être sûr que l’option « root=UUID=… » du noyau est correct.

La partie boot UEFI est complexe et évolutive, fonction du noyau, donc pas facile à tracer, et aussi dépendante d’éventuels bugs du BIOS. Le BIOS étant à jour, ça élimine cette suspicion.
Peut-être pas un problème de loader, mais l’intérêt de réinstaller en mode ‹ verbose › est au moins de récupérer des messages pour confirmer ou non que le loader s’installe correctement, ou pas.

@pled : je salue l’initiative… J’essaierai cela dès que j’aurai quelque chose de plus stable. :wink:

@Verner : Justement au vu de ce que tu écris, je ne suis pas bien sûr qu’il s’agisse d’un problème de bootloader, à moins que qqch m’échappe ? Le système démarre bien, c’est « juste » qu’ensuite il plante et reboote plus ou moins rapidement (j’ai parfois le temps de taper quelques commandes).
Dernière nouveauté dans les messages depuis le flash du bios (qui m’affiche 4 coeurs, bizarrement alors que gkrellm me parle de 8)
IMG_20250817_183808_resized_20250817_065418259