Carte graphique Nvidia pas reconnue ? Le sujet est résolu

[MicP]

J'ai jamais trop compris quelle pouvait bien être l'utilité de l'UEFI et du mode secure pour un système Linux,
et vu les messages que je vois à ce sujet sur les forums, j'ai même l'impression que ça pose plus de problèmes qu'autre chose.

[dezix]

J'ai jamais trop compris quelle pouvait bien être l'utilité de l'UEFI et du mode secure pour un système Linux,
et vu les messages que je vois à ce sujet sur les forums, j'ai même l'impression que ça pose plus de problèmes qu'autre chose.

Tout est bien expliqué dans SecureBoot | Debian Wiki mais en anglais

Donc en résumé pour les non-anglo-lecteurs :

SecureBoot est un mécanisme d'authentification (par signature) du logiciel qui va être exécuté par le micro-code UEFI.
Typiquement il s'agit d'un chargeur d'amorçage (p.ex: GRUB) ;
mais il peut aussi s'agir d'un utilitaire de maintenance (p.ex: Installateur de MàJ UEFI)

Microsoft CA est l'Autorité Certifiante (CA) émettrice des certificats permettant la signature du code.

SecureBoot est donc un élément de sécurisation de la machine qui empêche d'exécuter au démarrage un code non-authentifié.
Comme toute mesure de durcissement, cela induit des contraintes nouvelles, donc parfois des difficultés de mise en place.


Shim

Pour éviter d'être trop dépendant de Microsoft CA,
les distributions Linux ont mis au point une pièce intermédiaire → shim

Shim est un (petit) amorçeur de démarrage (bootloader) porteur de la signature validée par Microsoft CA, ce qui permet l'amorçage initial.

Ensuite Shim , à la place de SecureBoot, vérifiera les signatures fournies par les applications ;
pour cela il utilise les clés de la distribution,
mais aussi des clés pouvant être fournies par le "Propriétaire" de la Machine → Machine Owner Key (MOK)

Avec cette méthode,
les distributions n'ont plus qu'à faire signer (1fois par version) le code de Shim par Microsoft CA
et le propriétaire de la machine peut reprendre totalement le contrôle au prix de la re-compilation du noyau et du chargeur d'amorçage en les signant avec sa propre clé.

Je ne garantis pas la totale exactitude de ce qui précède, mais c'est l'idée.

[jandelalune]

dezix a écrit :
Alors un test qui ne coûte rien => tu le désactives (temporairement)
et après redémarrage lspci -k pour voir si tu as qqchose sur la ligne Kernel driver in use : pour Nvidia.

Code : Tout sélectionner

 
gerard@VICTUSG:~$ lspci -k
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex
	Subsystem: Hewlett-Packard Company Renoir Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU
	Subsystem: Hewlett-Packard Company Renoir IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
	Kernel driver in use: pcieport
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
	Kernel driver in use: pcieport
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
	Kernel driver in use: pcieport
00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
	Kernel driver in use: pcieport
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
	Kernel driver in use: pcieport
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
	Kernel driver in use: pcieport
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 51)
	Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
	Subsystem: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166a
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166b
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166c
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166d
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166e
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 166f
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1670
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1671
01:00.0 VGA compatible controller: NVIDIA Corporation GA107 (rev a1)
	DeviceName: NVIDIA Graphics Device
	Subsystem: Hewlett-Packard Company Device 88ec
	Kernel modules: nvidia
01:00.1 Audio device: NVIDIA Corporation Device 2291 (rev a1)
	Subsystem: Hewlett-Packard Company Device 88ec
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 16)
	DeviceName: OnBoard Enthernets
	Subsystem: Hewlett-Packard Company RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
	Kernel driver in use: r8169
	Kernel modules: r8169
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8852
	DeviceName: Realtek Wireless LAN + BT
	Subsystem: Hewlett-Packard Company Device 88e1
04:00.0 SD Host controller: Genesys Logic, Inc GL9750 SD Host Controller (rev 01)
	DeviceName: Realtek PCIE CardReader
	Subsystem: Hewlett-Packard Company GL9750 SD Host Controller
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci_pci
05:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN750 / PC SN730 NVMe SSD
	Subsystem: Sandisk Corp WD Black 2019/PC SN750 NVMe SSD
	Kernel driver in use: nvme
	Kernel modules: nvme
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c6)
	DeviceName:  Onboard IGD
	Subsystem: Hewlett-Packard Company Device 88ec
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu
06:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637
	Subsystem: Hewlett-Packard Company Device 88ec
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
06:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
	Subsystem: Hewlett-Packard Company Family 17h (Models 10h-1fh) Platform Security Processor
	Kernel driver in use: ccp
	Kernel modules: ccp
06:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
	Subsystem: Hewlett-Packard Company Renoir USB 3.1
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
06:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
	Subsystem: Hewlett-Packard Company Renoir USB 3.1
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
06:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01)
	Subsystem: Hewlett-Packard Company Raven/Raven2/FireFlight/Renoir Audio Processor
	Kernel driver in use: snd_rn_pci_acp3x
	Kernel modules: snd_pci_acp3x, snd_rn_pci_acp3x
06:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
	Subsystem: Hewlett-Packard Company Family 17h (Models 10h-1fh) HD Audio Controller
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
gerard@VICTUSG:~$ 

Je n’ai pas l’impression que quoi que ce soit ait changé pour nvidia ??

Merci & à +

[PascalHambourg]

Je suppose que PH en écrivant "...ou bien peut-être un noyau plus récent." fait référence au pilote nouveau,
mais le wiki Debian fait de son côté référence à l'usage du noyau backports

Je faisais effectivement référence au pilote "nouveau" d'un noyau plus récent comme celui disponible dans les backports.

J'ai lu (qqpart) que si secureboot est activé dans le firmware UEFI (BIOS)
de la machine cela bloque l'installation/usage ??? des modules non-signés

Peut-être dans mon message datant du 29 janvier de ce sujet, ou celui d'Eikichi du 3 février ?

[dezix]

@jdll

Pendant que secureboot est désactivé,
tu pourrais reprendre :

Concernant (le module nvidia), il faudrait regarder pourquoi il n'est pas utilisé. Est-il chargé ?
Sinon, essayer de le charger manuellement et voir ce qui se passe.

Code : Tout sélectionner

lsmod | grep nvidia
modprobe -v nvidia
lspci -ks 01:00.0
dmesg | tail

Cela donnera peut-être un résultat différent...

[jandelalune]

Salut dezix

dezix a écrit :
Pendant que secureboot est désactivé,
tu pourrais reprendre :
PascalHambourg a écrit : ↑04 févr. 2022, 09:16 Concernant (le module nvidia), il faudrait regarder pourquoi il n'est pas utilisé. Est-il chargé ?
Sinon, essayer de le charger manuellement et voir ce qui se passe.
Code : Tout sélectionner
lsmod | grep nvidia
modprobe -v nvidia
lspci -ks 01:00.0
dmesg | tail
Cela donnera peut-être un résultat différent...

Résultats ci dessous

Code : Tout sélectionner

root@VICTUSG:~# lsmod | grep nvidia 
root@VICTUSG:~# 

Code : Tout sélectionner

 
root@VICTUSG:~# modprobe -v nvidia
install modprobe -i nvidia-current $CMDLINE_OPTS 
insmod /lib/modules/5.10.0-11-amd64/updates/dkms/nvidia-current.ko 
modprobe: ERROR: could not insert 'nvidia_current': Operation not permitted
modprobe: ERROR: ../libkmod/libkmod-module.c:990 command_do() Error running install command 'modprobe -i nvidia-current ' for module nvidia: retcode 1
modprobe: ERROR: could not insert 'nvidia': Invalid argument
root@VICTUSG:~#

Code : Tout sélectionner

 
root@VICTUSG:~# lspci -ks 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA107 (rev a1)
	DeviceName: NVIDIA Graphics Device
	Subsystem: Hewlett-Packard Company Device 88ec
	Kernel modules: nvidia 

Code : Tout sélectionner

 root@VICTUSG:~# dmesg | tail
[    5.181590] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[    5.274473] rfkill: input handler disabled
[    6.831561] r8169 0000:02:00.0 eno1: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.831577] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[   22.086461] rfkill: input handler enabled
[   22.363493] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[   23.879319] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[   24.116834] rfkill: input handler disabled
[ 3884.712504] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[ 4406.131389] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
root@VICTUSG:~# 

PH a écrit le 04/02 : Concernant ce dernier (nvidia-driver), il faudrait regarder pourquoi il n'est pas utilisé. Est-il chargé ? Sinon, essayer de le charger manuellement et voir ce qui se passe.

je n’ai pas retrouvé dans nos échanges de réponse à ce post : j’ai du tout zappé !!!
et même si j’avais lu je ne crois pas savoir faire ou tout au moins je ne comprends pas?? je l'ai installé en ligne de commande ??

Merci de préciser, si c’est toujours utile ???
A+

[PascalHambourg]

Les dernières lignes de dmesg me laissent penser que le secure boot n'est pas désactivé.
Voyons.

Code : Tout sélectionner

dmesg | grep -i "secure.*boot"
mokutil --sb-state

[dezix]

Les dernières lignes de dmesg me laissent penser que le secure boot n'est pas désactivé.
Voyons.

Code : Tout sélectionner

dmesg | grep -i "secure.*boot"
mokutil --sb-state

Tu m'as coupé l'herbe sous le pied

[jandelalune]

Salut

@ PascalHambourg
@ dezix

PascalHambourg a écrit : ↑13 févr. 2022, 20:13 Les dernières lignes de dmesg me laissent penser que le secure boot n'est pas désactivé.
Voyons.
dmesg | grep -i "secure.*boot"
mokutil --sb-state

dezix a écrit : tu m’as coupé l’herbe sous le pied

Pour désactiver le secure boot suite à la proposition de dezix, je l’ai fait sous Windows, où je n’ai modifié que l’État, (j’ignorais en fait que je pouvais le faire dans les boot de linux), ce qui d’ailleurs semble avoir semé la pagaille chez Windows qui me refuse depuis de se relancer

Voilà :
ce que je trouve dans les instructions de boot security  (sous debian):
Périphérique TMC Disponible
Etat TMP Désactivé
Effacer TMP Non

dois-je modifier Périphérique TMC Disponible ??

et les résultats des commandes de PascalHambourg ci-dessous

Code : Tout sélectionner

gerard@VICTUSG:~$ su -
Mot de passe : 
root@VICTUSG:~# dmesg | grep -i "secure.*boot"
[    0.000000] Kernel is locked down from EFI Secure Boot; see man kernel_lockdown.7
[    0.000000] secureboot: Secure boot enabled
[    1.197380] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[    1.197398] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux: 4b6ef5abca669825178e052c84667ccbc0531f8c'
[    1.198321] integrity: Loaded X.509 cert 'HP Inc.: HP UEFI Secure Boot DB 2017: d9c01b50cfcae89d3b05345c163aa76e5dd589e7'
[    1.199976] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
root@VICTUSG:~# 

Code : Tout sélectionner

root@VICTUSG:~# mokutil --sb-state
SecureBoot enabled
root@VICTUSG:~# 

Merci à vous deux

A+

[jandelalune]

@PascalHambourg
@ dezix

je reviens rapidement sur ma réponse concernant cette question de PascalHambourg le 4/02/2022 à propos du driver-nvidia,

il faudrait regarder pourquoi il n'est pas utilisé. Est-il chargé ? Sinon, essayer de le charger manuellement et voir ce qui se passe.

Je ne crois pas savoir le faire ou plutot je ne comprends ps:je l'ai installé en ligne de commande ?? Si c'est toujours utile merci de m'expliquer !!

Merci

[dezix]

SecureBoot est une fonction du firmware UEFI,
qui est un système embarqué sur la carte mère en remplacement du BIOS (c'est le nouveau BIOS).

Donc pour (dés)activer SecureBoot
il faut entrer dans le paramétrage de la machine (Setup UEFI/BIOS) ;
cela peut se faire dans la toute première phase du démarrage de la machine (avant le menu GRUB)
en pressant une touche indiquée furtivement sur le 1er écran HP (souvent F2 mais cela dépend du modèle/constructeur).


Ce paramétrage est indépendant des OS installés => c'est le réglage du matériel,
donc grande prudence
et de toute façon il est demandé confirmation de la prise en compte des modifications avant d'en sortir.

En cas de doute => Sortir sans enregistrer et recommencer.

[jandelalune]

salut dezix

Merci pour la précision

J'essaie d'être prudent, d'où mes demandes de confirmation (ou d'explications) fréquentes avant d'accomplir qque chose ; exemple la dernière question concernant la proposition de PascalHambourg que tu as relayée pour nvidia-driver

Puis je essayer de modifier dans les instructions de boot la ligne "Périphérique TMC Disponible" visée dans ma réponse ci-dessus sans prendre trop de risques ?

Merci d'avance

[dezix]

Pour désactiver le secure boot suite à la proposition de dezix, je l’ai fait sous Windows, où je n’ai modifié que l’État, (j’ignorais en fait que je pouvais le faire dans les boot de linux), ce qui d’ailleurs semble avoir semé la pagaille chez Windows qui me refuse depuis de se relancer

Voilà :
ce que je trouve dans les instructions de boot security  (sous debian):
Périphérique TMC Disponible
Etat TMP Désactivé
Effacer TMP Non

dois-je modifier Périphérique TMC Disponible ??

Je n'ai aucune idée de ce que c'est... attend que quelqu'un nous explique ça.

Tu les a trouvé où ces instructions de boot security ?

[dezix]

Si cela peut t'aider, voici un lien vers la description de ce que doit être : Interface UEFI HP Victus (PDF)

à la page 14 : Configuration > Language doit te permettre de le traduire en FR
et page 34 : Boot Options > Secure Boot

Accès à l'interface UEFI

F10 sur les PC HP en général...de façon variable d'une machine à l'autre.

[dezix]

J'ai trouvé ce qu'est TPM => Trusted Platform Module — Wikipédia

Comme j'utilise du matos à 150€ le barebone, ça dépasse le champ de mes préoccupations

[dezix]

Selon cette vidéo https://youtu.be/VfHEXhYqZ-I => Trusted Computing > c'est PAS le pied !

En français c'est l'Informatique de " confiance " .....

[PascalHambourg]

Les retours des commandes dmesg et mokutil confirment que le secure boot est encore activé.
Deux options :
- signer les modules nvidia et enregistrer la clé dans le firmware UEFI - mais je ne sais pas faire, il faudra te débrouiller
- désactiver le secure boot, ce qui se fait dans les paramètres du BIOS/UEFI au démarrage (F10 sur les PC HP en général) de façon variable d'une machine à l'autre.

il faudrait regarder pourquoi il n'est pas utilisé. Est-il chargé ? Sinon, essayer de le charger manuellement et voir ce qui se passe.

Je ne crois pas savoir le faire ou plutot je ne comprends ps

Tu l'as déjà fait, c'était le but de la séquence de commandes lsmod + modprobe + lspci + dmesg.

[dezix]

Pour faire un point

Si la version actuelle du pilote fonctionne sans SecureBoot , c'est comme vient de le dire PH

Pour l'option 1 : signer le(s) module(s) les instructions sont : SecureBoot > MOK - Debian Wiki
(pour moi c'est 100% nouveau donc pas d'avis sur la question)

Pour l'option 2 : Désactivé SecureBoot ; je l'ai toujours désactivé sans le moindre souci mais je n'utilise pas Windows.


Après, si cette version stable, ne fonctionne pas => Tester la version backports du pilote.

Si ce n'est pas suffisant => Tester aussi le noyau de backports

Si toujours pas bon => Tester l'installation du Pilote directement fourni par Nvidia.

Note que quelque soit la version du pilote l'histoire avec SecureBoot reste la même.

Voilà, le panorama, j'espère ne pas passer à côté d'autres possibilités.

[jandelalune]

Salut dezix et merci pour ta disponibilité et ta démarche de recherche active

dezix a ecrit :
Tu les a trouvé où ces instructions de boot security ?

Dans la partie Menu Securité du Menu utilities Bios de mon ordinateur sous debian (idem sous Windows) décrits sur le site Interface UEFI HP Victus (PDF) que tu me cites dans le post suivant

Malheureusement je ne pratique pas (ou très peu) la langue de shekspeare : je peux me débrouiller grossièrement sur de l’écrit mais l’audio c’est rédhibitoire : mais je chercherais pour comprendre (je trouverais sans doute aussi en français ) sur le fonds

Je continue sur la suite de vos réponses

A+

[dezix]

Bonjour,

Dans la partie Menu Securité du Menu utilities Bios de mon ordinateur sous debian (idem sous Windows) décrits sur le site Interface UEFI HP Victus (PDF) que tu me cites dans le post suivant

J'ai comme l'impression qu'il y a quelque-chose de pas clair dans ta compréhension de "Interface UEFI" ;
cela n'appartient ni à Windows, ni à Debian ; c'est le système de gestion/paramétrage du matériel => ça appartient au PC, plus précisément à la carte-mère du PC.


C'est pour cela que tu y parviens avec la touche F10 avant même le chargeur d'amorçage (GRUB).

Malheureusement je ne pratique pas (ou très peu) la langue de shekspeare

L'interface du UEFI est traduite en français après choix de la langue :

Interface UEFI HP Victus (PDF)

à la page 14 : Configuration > Language doit te permettre de le traduire en FR

donc à ce niveau pas de soucis (il faut peut-être valider/enregistrer/fermer l'interface et y revenir pour l'avoir en français ???)

Pour le reste, on va continuer à t'aider dans la langue d'Astérix par Toutatis !