Vous n'êtes pas identifié(e).
Pages : 1
pas tout compris (je n'ai que le noyau 5.8.0-3 installé )
le 5.8.0-2 je vais le virer
première fois que je vois ça , je vais essayer de savoir qui lance cela sur la mise a jour (bullseye)
ps: les modules sont correct et fonctionnel
Dernière modification par anonyme (19-10-2020 11:10:58)
si nagam passe par la , il pourra m' expliquer .
j'ai trouver sur un autre forum le même genre de choses pour nvidia avec ce fameux script "conftest.sh" que je ne trouve nulle part
ils appliquent un patche sur certaines choses , puis l'applique aux modules
j'ai jamais fait ce genre de chose ni sur un noyau , ni sur autre chose .
aujourd'hui une autre machine , même punition sur les mises a jours sur bullseye
ps: le premier bi xeon "j -24" , le second un amd 1700X "j -16" pour les threads utilisés
pas tout compris (je n'ai que le noyau 5.8.0-3 installé )
le 5.8.0-2 je vais le virer
Du coup tu en as deux noyaux installés, je suppose que la réflexion était sur le fait que ça a build que sur le nouveau noyau?
Si le driver était déjà là avant et installé il est logique qu'il se rebuild seulement sur le nouveau kernel sur lequel il n'était pas installé. Quand le driver se rebuild sur tous les kernels présents c'est quand le driver lui même est mis à jour.
En fait j'ai pas assez d'info et la question pas assez claire pour savoir où tu veux en venir.
Ah et a propos du scripts conftest.sh, je supposes (mais je garanti rien) d'après son nom qu'il sert à faire des tests sur la conf de l'hote.
Je supposes que dans un module externe, rien ne t'empêche de mettre un script pour aider à la conf ou au build.
Tu dis qu'il n'est jamais apparu avant : je sais pas, je répète je n'ai pas de nvidia
Dernière modification par naguam (23-10-2020 19:15:56)
Unixien?
Compiler son kernel!
Hors ligne
par contre
on dirait que la version de ce driver pour les modules (et les dépendances) est compatible avec le 5.7 (et suivant) et pas le 5.8.0-3
et oui il a uniquement compilé 'avec ce patch les 4 modules du 5.8.0.3 (rien eu sur le 5.8.0-1 et -2 modules déjà présent )
c'est la première fois que je vois cela sur une mise a jour de bullseye (pas a l'installation du driver)
parfois j'ai entre 100 et 200 paquets a mettre a jour et je fais pas toutes les machines le même jour (et surtout pas tous les jours )
je pense que c'est pour éviter de mal compiler les modules avec ce noyau
ça applique le patch "modules KERNEL_UNAME"
et ensuite la compilation normale avec DKMS pour créer les 4 modules
ps: pas trouvé de trace, ni le contenu du script sur la machine
c'est juste pour pas rester ignorant
nota: j'ai trouvé sur le net ce script pour installer le driver nonfree nvidia (mais pas le contenu ) sur "debian.fr"
Dernière modification par anonyme (24-10-2020 11:48:34)
le noyau
les erreurs
je vais tenter la version d'experimental du driver nvidia sans me faire trop d'illusion
ps : la GTX750 est une petite carte , je sais pas si supporté par le dernier driver de nvidia
bogue
le retour de l'installation
a priori cela a l'air correct (faut que je vire plymouth )
un reboot et on teste cuda si ok
Dernière modification par anonyme (25-10-2020 01:47:15)
ça veut pas dire que c'est parfait , mais au moins la compilation avec ce noyau est correcte
ps: il risque d' avoir des bugs avec certaines cartes et ou des jeux . (le i386 ne doit pas être installé )
je passe a cuda 11 @++
les bogues
pour cuda c'est moins bon
mon application ne détecte ni Cuda , ni OpenCL
pour ce soir ça suffira
Dernière modification par anonyme (25-10-2020 02:43:04)
je vais revenir pour cette machine sur une buster sur un ssd , a la place du DD de 200Go actuel
nota: tenter de mettre cuda10 a cassé le driver
on suivra l'actualité
ps: le lien ci dessus est pour debian10
traduit de ce lien => https://forums.developer.nvidia.com/t/n … 5-9/157260
Dernière modification par anonyme (25-10-2020 11:38:15)
Hors ligne
que je conseille de laisser en 5.8.14-1 le temps que ce soit résolu
ps: pour les utilisateur du driver nvidia et de cuda
Pages : 1