Impossible de compiler les modules nvidia et virtualbox sur un noyau 5.X

mattotop · Septembre 30, 2019, 9:21am

Bonjour,
ayant eu quelques problèmes avec ma carte nvidia sur les noyaux 4.X, je tourne actuellement avec ma buster de bureau sur un noyau 5.0.11-amd64 que j’ai compilé depuis kernel.org.
Les modules nvidia et virtualbox pour ce noyau là se compilent bien avec dkms, c’est OK.
Par contre, j’aimerais tester d’autres noyaux 5.X pour corriger quelques détails de matos mal gèré avec mon 5.0, mais quelle que soit la version de noyau en 5 que je prenne sur kernel.org, j’ai un plantage à la compil de nvidia et de virtualbox.
Et je n’arrive pas à comprendre pourquoi.
Si quelqu’un a une idée pour comprendre ce qui empêche la compilation, je vous évite le log de compil de nvidia énormes, mais voici ceux de virtualbox:

DKMS make.log for virtualbox-6.0.4 for kernel 5.3.1-amd64 (x86_64)
lundi 30 septembre 2019, 10:47:45 (UTC+0200)
make : on entre dans le répertoire « /usr/src/linux-headers-5.3.1-amd64 »
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPLibAll.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/initterm-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/memobj-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/mpnotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/powernotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mpnotification-r0drv-linux.o
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjLinuxDoMmap’:
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:215:58: error: ‘MAP_SHARED’ undeclared (first use in this function); did you mean ‘VM_SHARED’?
         ulAddr = vm_mmap(NULL, R3PtrFixed, cb, fLnxProt, MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, 0);
                                                          ^~~~~~~~~~
                                                          VM_SHARED
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:215:58: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o] Error 1
make[2]: *** Attente des tâches non terminées....
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: rtR0MemKernelCopyLnxWorker()+0x16: redundant CLD
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/linux/SUPDrv-linux.o: warning: objtool: VBoxDrvLinuxIOCtl_6_0_4()+0x98: call to VBoxHost_RTR0MemUserCopyFrom() with UACCESS enabled
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.c: In function ‘VBoxHost_RTMpOnAll’:
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.c:287:18: error: void value not ignored as it ought to be
         int rc = smp_call_function(rtmpLinuxAllWrapper, &Args, 0 /* wait */);
                  ^~~~~~~~~~~~~~~~~
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.c: In function ‘VBoxHost_RTMpOnOthers’:
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.c:341:8: error: void value not ignored as it ought to be
     rc = smp_call_function(rtmpLinuxWrapper, &Args, 1 /* wait */);
        ^
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o] Error 1
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrvTracer.o: warning: objtool: .text+0x7: indirect jump found in RETPOLINE build
/var/lib/dkms/virtualbox/6.0.4/build/vboxdrv/SUPDrvTracer.o: warning: objtool: supdrvTracerProbeFireStub() is missing an ELF size annotation
make[1]: *** [scripts/Makefile.build:497: /var/lib/dkms/virtualbox/6.0.4/build/vboxdrv] Error 2
make: *** [Makefile:1624: _module_/var/lib/dkms/virtualbox/6.0.4/build] Error 2
make : on quitte le répertoire « /usr/src/linux-headers-5.3.1-amd64 »

Je me demande si ce n’est pas une question de paramètre de config multiprocesseur de mon noyau custom qui est mal géré, mais ce que je ne comprends pas, c’est que pour compiler mon noyau, je fais un oldconfig depuis le .config de mon noyau 5.0, donc ça devrait coller en remettant les mêmes paramètres de compil noyau, non ?
Bref, si vous avez une idée…

pam547 · Septembre 30, 2019, 9:30am

Bonjour

J’ai une idée oui, c’est que si tu résous ton problème là, le mien sera peut-être aussi résolu :).

Je te renvoie ce que je partage dans le sujet en question : Installer xfsprogs, btrfs-progs, jfsutils, et reiserfsprogs, envoie un message d’erreur concernant les firmwares Nvidia non-free.

mattotop · Septembre 30, 2019, 9:43am

Non, tu n’as pas de problème de compilation dans ce que tu décris dans l’autre fil.
J’ai un peu de mal à comprendre tes 2 derniers posts, c’est pour ça que je n’ai rien dit, mais ce que tu indiques sur l’initramfs ne fait pas partie de la compilation (et en plus, ce sont juste des warnings, pas des erreurs, mais bon).
Donc non, ça n’a rien à voir.

pam547 · Septembre 30, 2019, 9:50am

Tu sais mieux moi ce qui te concerne.

Ce que j’ai cru comprendre, c’est que l’ordre de chargement des modules à partir de je ne sais pas quel noyau empêche la séquence de boot de se terminer correctement.

Quoi qu’il en soit, bonne chance à toi avec tes deux compilations.

mattotop · Septembre 30, 2019, 10:03am

Voilà:
ça, c’est là où se situe ton probléme, à l’execution des modules, etc, mais la fabrication de ces modules, la compilation elle même, se passe bien pour toi.
Moi, c’est bien avant qu’on essaye de les insèrer dans le noyau, c’est au moment ou je tente de les fabriquer que ça coince.

pam547 · Septembre 30, 2019, 4:40pm

Ah oui, et donc ce que j’écris dans mon premier message sur ce post.
C’est que la compilation pourrait être compromise à cause d’un ou des programmes de la liste que j’y partage.

Bonus :
Cartes graphiques Intel® & Intel HD Graphics.
Intel fournissait l’Intel® Graphics Installer for Linux, une application qui installe et met à jour les pilotes d’Intel®. Intel va arrêter cet outil de mise à jour à partir de la version 2.0.6 (destinée à Ubuntu 17.04). Les distributions Linux incluent déjà par défaut un pilote graphique Intel®, sans nécessiter d’installation supplémentaire. Voir aussi la page de la documentation consacrée aux cartes graphiques Intel®.)

anon70622873 · Octobre 1, 2019, 8:13am

Bonjour,

Pourquoi ne pas utiliser le noyau présent dans les backports de buster en version 5.2 ?
Sinon voir ce problème similaire.

mattotop · Octobre 1, 2019, 8:41am

Alors je ne l’ai pas précisé, mais je n’ai pas que le probléme avec les noyaux de kernel.org, j’avais aussi le probléme avec le noyau 5.2 backports.
Par contre, ça m’a fait penser qu’il y avait peut être une version backports de nvidia ou de virtualbox, mais non.
Je vais peut être creuser du coté des versions sid des modules.

Oui, mais non, c’est un autre soucis de compilation, et sur le module OSE, pas le même module.
Et le seul conseil en réponse, c’est:
“attendez un peu, c’est le genre de soucis de compil qui arrive avec un noyau récent et qui se règle tout seul”

petit_chat_noir · Octobre 1, 2019, 11:46am

tu vas les chercher où tes sources pour le module nvidia et pour virtualbox ??

Ca sent la fonction pas implémentée, ou renommée entre deux versions.
Ca fait looooooongtemps que j’ai pas compilé un noyau, mais il y a du parametrage avant la compile il me semble… rien qui ne fait référence à MAP_SHARED ?

mattotop · Octobre 1, 2019, 12:17pm

mj@mercure:~$ apt-cache policy nvidia-kernel-dkms virtualbox-dkms
nvidia-kernel-dkms:
  Installé : 418.74-1
  Candidat : 418.74-1
 Table de version :
 *** 418.74-1 500
        500 http://deb.debian.org/debian buster/non-free amd64 Packages
        100 /var/lib/dpkg/status
virtualbox-dkms:
  Installé : 6.0.4-dfsg-5
  Candidat : 6.0.4-dfsg-5
 Table de version :
 *** 6.0.4-dfsg-5 100
        100 /var/lib/dpkg/status

Tiens, tu as raison, pour vb, sources et binaires ont été installés quand ma machine était en stretch.

Je te rassure, c’est comme le vélo, ça ne s’oublie pas.
Par contre, pour compiler, je fais un make oldconfig, qui ne me pose des questions que sur ce qui a été modifié, donc il reprend une config a priori bonne.
Et de toutes façons, j’ai le même probléme de compil avec le noyau binaire debian de backports, donc ce n’est pas un soucis de paramètrage du noyau lui même.
D’ailleurs, j’ai un peu regardé, et les _SHARED en question ne semblent pas être des flags de config du noyau:

mj@mercure:~/Documents/installs/linux-build/5.3.1/linux-5.3.1$ grep "_SHARED" .config
CONFIG_DMA_SHARED_BUFFER=y
mj@mercure:~/Documents/installs/linux-build/5.3.1/linux-5.3.1$ grep "_SHARED" /boot/config-5.0.11-amd64 
CONFIG_DMA_SHARED_BUFFER=y

petit_chat_noir · Octobre 1, 2019, 12:37pm

Je testerais d’autres sources VB et NVIDIA, lesquelles j’en sais fichtrement rien ! mais quelque chose de récent