Bonjour,
Je tente d'installer VMWare Server 2.0.2 64 bits sur mon Linux Slackware 64 de kernel 2.6.35.4 que j'ai compilé moi même.
Sauf que pendant la création des modules, il ne peut pas continuer suite à une erreur de kernel headers. L'installation me dit :
The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.35.4). Even if the module were to compile successfully, it would not load into the running kernel.
puis :
What is the location of the directory of C header files that match your running kernel? [/usr/src/linux/include]
Mais rien n'a faire. Que je saisisse "/usr/src/linux/include", "/lib/modules/2.6.35.4/build/include" ou encore l'ancienne version "/usr/src/linux-2.6.33.4/include" c'est toujours la même erreur.
Sauf si j'entre "/usr/include", il me dit :
The header files in /usr/include are generally for C libraries, not for the running kernel. If you do not have kernel header files in your /usr/src directory, you probably do not have the kernel-source package installed. Are you sure that /usr/include contains the header files associated with your running kernel? [no]
Que je répond yes ou no, toujours la même erreur.
Est ce une erreur de VMWare ou ma façon de compiler mon kernel ?
Voici ma compilation kernel habituelle :
cd /usr/src/linux
make mrproper
make menuconfig
make dep
make clean
make bzImage
make modules
make modules_install
cp /usr/src/linux/arch/x86/boot/bzImage /boot/bzImage
lilo -v
Une idée s'il vous plait ?
J'ai ajouté dans une nouvelle compilation kernel ceci :
make headers_install ARCH=x86_64 INSTALL_HDR_PATH=/usr/include
Mais j'ai beau le faire dans le /usr/src/linux/, redémarrer le serveur sans compilation et avec compilation, mais j'ai toujours la même erreur.
PS : J'ai tentez également avec seulement "make headers_install" mais c'est toujours pareil.
# il faut les headers qui matche 'uname -r'
Posté par NeoX . Évalué à 6.
sinon vmware t'envoie ballader
à voir donc comment changer la version des headers pour correspondre à la sortie de la commande uname -r
# Remarques
Posté par Jérôme Pinot (site web personnel) . Évalué à 4.
Tu peux remplacer
make dep
make clean
make bzImage
make modules
simplement par
make
D'autre part
make headers_install ARCH=x86_64 INSTALL_HDR_PATH=/usr/include
est une mauvaise idée car tu écrases les headers fournit par la slack (package kernel-headers). Ce qui est dans /usr/include/linux ne devrait pas être modifié tout seul car ces headers ont servi pour la compilation de la glibc et font donc partie de la chaine de compilation.
Est-ce indispensable pour toi de tourner avec un noyau 2.6.35.x ?
Sinon, je te conseille de réinstaller kernel-headers, kernel-source et de booter sur le noyau par défaut de la slack (le 2.6.33.4). C'est peut-être un manque de cohérence dans les versions de noyau qui te causent des soucis.
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
Le kernel-* current de Slackware est effectivemet à la version 2.6.33.4.
Je recompile mon noyau pour éviter de charger en module le reiserfs ainsi que le megaraid_sas de ma carte raid 5 et les mettre en initrd dans le chargeur. Il est vrai que lors de cette recompilation je prend toujours la dernière version stable du kernel pour suivre les corrections de sécurité.
Mais tu me dit que je suis contrainte de suivre le kernel-headers de Slackware alors que les headers sont dans le kernel-source ... C'est dommage que ca dépend de la glibc et je ne souhaites pas me lancer dans la compilation du compilateur non plus ...
Ce que je pourrai alors faire c'est installer simplement les packages kernel-* à la version current de Slackware (et non de Kernel.org) et à l'aide du kernel-source original et non modifié fourni par Patrick (ce qui reviens à télécharger les sources chez Kernel.org à la même version que celle fournis par Slackware) puis recompiler le tout pour activer en dur mon système de fichier et mon raid.
J'abandonne alors de suivre l'évolution des mises à jours de Kernel.org et je m'en tiens à la vitesse de Slackware, dommage ...
Sinon, si je souhaites vraiment suivre Kernel.org, est ce compliqué de compiler la glibc et est ce que je ne vais pas me perdre dans la recompilation quasi totale du compilateur et de ses dépendances ?
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
Avec le kernel-* de Slackware, mon Backplain PERC 5i RAID 5 SAS de DELL ne se trouve plus en sda mais en sdc ... alors je charge via le cd, je chroot, je change sda en sdc et sdc1 dans mon lilo, je modifie mon fstab pour m'adapter, je charge de nouveau le mkinitrd via le /proc/partition actuel actuel (avec les disques dans le désordre) et bien il ne se lance plus. Je débranche tous mes disques SATA pour laisser pour Backplain, il n'y a que /dev/sda et /dev/sda1 (avec sda2 pour la swap) et bien, il ne boot toujours pas, il me dit qu'il ne trouve pas le /dev/init, comme si il n'arrivait pas à le monter, même quand il est seul et que tout est remis en sda ...
Le pire, quand je charge le serveur via le cdrom et en huge.s, tout fonctionne, quand je fais un lilo -X il me donne la version du kernel-header et de la glibc ... je pense qu'il plante à cause de ça ... mais même après avoir remis tous les packages de Slack, il ne veut toujours rien :'(
Je réinstalle tout et je m'en tiens aux packages kernel- de Slack avec un mkinitrd pour charger en ramfs mon raid et le reiserfs :'(
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
Je passe en kernel-generic avec mon mkinitrd habituel (mkinitrd -c -k 2.6.33.4 -m "megaraid_sas:reiserfs") avec un lilo -v mais lors du reboot plus rien ne marche, mon raid devient sdc au lieu de sda. Exactement la même erreur que celle précédemment alors que l'installation était toute fraiche.
Je passe alors en kernel-huge sans mkinitrd et je retire l'initrd du lilo.conf et tout refonctionne.
Je n'ai jamais eu de problème avec le kernel-generic et mkinitrd. Je pratique ce mode d'installation depuis au moins 6 ans et 3 ans avec cette même machine ... à plus rien n'y comprendre.
Au final, je suis passée d'un kernel entièrement compilé à la main fonctionnel mais avec un kernel-header hasardeux) puis d'un kernel-generic fou qui m'inverse les disques et même avec un seul disque il ne comprend rien à finalement un kernel-huge bien lourd ...
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.33.4). Even if the module were to compile successfully, it would not load into the running kernel.
What is the location of the directory of C header files that match your running kernel? [/usr/src/linux/include]
J'utilise le kernel-huge de base sans aucune compilation avec une installation toute fraiche de moins de 30 minutes ...
Je pleure :'(
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
http://hootbah.zingzam.com/2006/12/13/vmware-on-debian-etch-(...)
Getting an error like:
The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.18-3-amd64). Even if the module were to compile successfully, it would not load into the running kernel.
To fix this you need to copy the UTS_RELEASE information into the version.h file.
Copy the line (or similar):
#define UTS_RELEASE "2.6.18-3-amd64"
from /usr/src/linux-headers-2.6.18-3-amd64/include/linux/utsrelease.h /usr/src/linux-headers-2.6.18-3-amd64/include/linux/version.h
The vmmon module will then compile successfully.
Et là, je me dit miracle ... mais je ne comprend pas trop ce qui est dit alors j'ajoute dans le fichier /usr/src/linux/include/linux/version.h ceci :
#define UTS_RELEASE "2.6.33.4"
Je relance mon /usr/bin/vmware-config.pl et il me donner une nouvelle erreur :
The path "/usr/src/linux/include" is a kernel header file directory, but it does not contain the file "linux/autoconf.h" as expected. This can happen if the kernel has never been built, or if you have invoked the "make mrproper" command in your kernel directory. In any case, you may want to rebuild your kernel.
En gros, il me demande de recompiler mon kernel ... Je vais me pendre ou pas ?
Pour info :
[12:31:16] root@everest:~/$ find /usr/src/ -name autoconf.h
/usr/src/linux-2.6.33.4/include/generated/autoconf.h
[^] # Re: Remarques
Posté par Elodie . Évalué à 1.
[^] # Re: Remarques
Posté par Kerro . Évalué à 2.
Il te faut regarder dans le code Perl de vmware. Tu recherches l'endroit où est affiché le message d'erreur, puis tu remontes petit à petit.
J'ai eu le problème sur une Debian bricolée. En une demi-heure c'était réglé. Je ne me souviens plus comment par contre, mais c'était trivial (du genre renommer un répertoire).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.