tuXXX Posté(e) le 18 août 2004 Auteur Posté(e) le 18 août 2004 - tout commence par un yum install kernel-sourcecode c'es le vrai noyau, ça? parce que déjà, que ça ne compile pas la première fois, c pas normal...
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 en fait il cherchait un module de crypto en .ko qui n'existais pas dans le répertoire crypto/ . Il n'y avais q'un .o du même nom... La compilation s'était bien passée. Ca avais merdé pendant le make modules install
tuXXX Posté(e) le 18 août 2004 Auteur Posté(e) le 18 août 2004 make modules install ça existe pas, ça... "make modules_install" plutôt...
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 oui désolé pour le "_", je l'avais bien mis , sinon ça n'aurais même pas commencer... En plus ce fichu module est loin dêtre le premier sur le liste
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 Si personne n'a de réponse je reprnedrais tout depuis le début: # yum remove kernel-sourcecode# rm -r /usr/src/linux-2.6.8.1...#yum install kernel-sourcecode$ cd /usr/src/linux-2.6.8.1...vérification dans crypto qu'il y a bien tous les bons modules$ make clean$ make mrproper$ make menuconfig$ make$ make modules_install...Un module en .ko ça vous aprait pas étrange ? il n'y aurais pas une fautes de frappe ?
Sandeman Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 ( après un make mrproper ton .config est dégagé ...) ( .ko est l'extension officielle des modules en 2.6)
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 J'avais sauvegarder mon .config dasn un autre fichier (comme conseiller dans le tuto) donc je l'avais rechargé... pour le .ko je ne savais pas, dans les sources il me semble que tout le fichier du repertoire crypto sont en .o ...
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 J'ai regarder et en fait c'est pas des .o mais des .c en majorité dans crypto/ Pour être sur j'ai tout repris depuis le début après avoir supprimés les sources actuelles. J'ai aussi modifié mon yum.conf car apparemment l'ordre dasn le yum.conf ne donne pas l'ordre de priorité pour les source d'istallation. Maintenant, je suis sure les sources viennent de chez Fedora.
tuXXX Posté(e) le 18 août 2004 Auteur Posté(e) le 18 août 2004 sinon, tu télécharge directement depuis le site officiel : http://www.kernel.org ... J'ai jamais vu un noyau officiel qui ne compilait pas... Mais tu met des patches ou pas? si oui, cela pourraît très bien venir de là (il faut qu'ils soient adaptés pour la version du noyau...)
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 J'ai appliqué aucun patch aux sources officielles Ensuite un noyau vanilla il faut aps le patcher dans tous les sens ? Pour la compilation je dirais ce soir si ça compile, j'ai pas eu le temps à midi de finir la config donc pas lancer la compilation encore...
tuXXX Posté(e) le 18 août 2004 Auteur Posté(e) le 18 août 2004 J'ai appliqué aucun patch aux sources officiellesEnsuite un noyau vanilla il faut pas le patcher dans tous les sens ? Ben non... ça marche très bien "tel quel"...sinon, y'aurait pas bcp d'intérêt...
zaverel Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 ça marche très bien "tel quel"...sinon, y'aurait pas bcp d'intérêt... Et ils servent aquoi alors les patch ck machin , mm truc ? A pourrir le kernel ? :langue:
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 l'avantge de la version Fedora est qu'il est déjà patcher et qu'on retrouve une continuité avec les versions précédentes
tuXXX Posté(e) le 18 août 2004 Auteur Posté(e) le 18 août 2004 Et ils servent aquoi alors les patch ck machin , mm truc ? A pourrir le kernel ? :langue: à améliorer les perfs de différentes manières en général... à tester des nouveaux trucs pour les noyaux mm (nouveau modèle de développement)... ensuite, il y a des patchs pour faire des choses plus spécifiques (openmosix, win4lin, patches subfs, etc...) mais globalement, le noyau officiel est sensé être le plus stable...
Arofarn Posté(e) le 18 août 2004 Posté(e) le 18 août 2004 le plus stable mais pas le plus complet... je pense que chaque distrib doit avoir un certain nombres de patch sur le noyau officiel suivant sont orientation plus ou moins professionnel /grand publique/seveur/station de travail...
Arofarn Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 Même problème de compilation apres avoir tout repris à zero. Donc soit il y a une merde dans les sources fedora soit je le configure comme un pied gauche J'ai vu aussi qu'il y avait une nouvelle "sous-version" 2.6.8-1.521 => 2.6.8-1.524 pour le kernel (mais pas trouver les sources donc j'arrive pas à recompiler les drivers videos???) conclusion: je suis revenu à la 2.6.7, et j'essayerai de les recompiler pour voir (genre support du NTFS en lecture au moins dont j'ai besoin et qui n'est pas activer par défaut)
-rem- Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 J'ai vraiment plus que lu en diagonale; emploi du temps charge oblige, mais Tuxxx a carrement raison, un noyau officiel doit compiler, apres, ptet que tu as mis des options qui provoquent des incompatibilites avec ton systeme, et dans ces cas la, Fedora applique un patch...tout simplement. J'ai deja rencontre ce cas plusieurs fois avec debian, et soit en retirant qq options, soit en patchant le noyau, ca marchait mieux. Aussi, tu n'as jamais reussi a le compiler ou il a compiler au moins une fois ?
Arofarn Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 il a compilé une fois, mais "modules_install" a merdé => fichier .ko manquant dans le sous-répertoire crypto/ des sources. Du coup, j'ai viré le module qui me paraissait manquant => compilation qui plante. Depuis ça plante toujours au même endroit ... Donc je vais essayer sur le 2.6.7 dont j'aia priori tous ce qu'il faut et attendre un peu que ça se tasse avec le 2.6.8.1. . En fait, il est présent sur les dépôt yum, mais n'est pas encore proposé par le soft de mise à jour de Fedora... Je précsie que mes source viennent toutes des dépôt yum pour fedora core 2. Donc je n'ai pas essayé avec le kernel vanilla, à voir...
Arofarn Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 Est-ce que lancer la compilation dasn une Konsole sous X avec d'autre application de lancer (xine, xmms, azureus, Firefox, Konqueror et superkaramba) peuvent perturber la compilation et être à l'origine de mon erreur ???
zaverel Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 Est-ce que lancer la compilation dasn une Konsole sous X avec d'autre application de lancer (xine, xmms, azureus, Firefox, Konqueror et superkaramba) peuvent perturber la compilation et être à l'origine de mon erreur ??? Je pense pas , je le fait aussi -D Sa rallonge surtout le temps de compilation (moins de ressource cpu dispo)
tuXXX Posté(e) le 19 août 2004 Auteur Posté(e) le 19 août 2004 Sa rallonge surtout le temps de compilation (moins de ressource cpu dispo) Euh... Ouais, enfin bon, ça enlève quoi? 1% de puissance...
green Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 J'ai installé Mandrake 10.1 bêta 1 sur hdb7 . Comme il y avait un noyau 2.6.8.rc2 (bof) je crois, j'ai installé le tmb-2.6.7-2 et là devant mes yeux ébahis je vois que dans le /boot de ma Mdk 10.1 il n'y a pas de initrd pour ce kernel !!! Je me dis alors que ça ne marchera jamais, je n'arriverai pas à démarrer sous ce kernel car j'ai tjs utiilisé jusqu'à présent un initrd... Et bien SI ça marche sans ... D'où ma question : à quoi sert ce truc ? Si j'ai bien compris, ça sert à ce que le kernel puisse s'installer sur un hd, en l'occurrence IDE pour moi , ça charge le module qui gère les IDE puis le kernel s'y installe... Comprends pas ... HELP
Dark26 Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 Est-ce que lancer la compilation dasn une Konsole sous X avec d'autre application de lancer (xine, xmms, azureus, Firefox, Konqueror et superkaramba) peuvent perturber la compilation et être à l'origine de mon erreur ??? je ne pense pas non plus.... faut dire dans la série compliqué, je compile le noyau de mon serveur sous debian sur mon pc desktop qui tourne sous fedora, avec un pc virtuel debian sous vmware dédié à ça
tuXXX Posté(e) le 19 août 2004 Auteur Posté(e) le 19 août 2004 D'où ma question : à quoi sert ce truc ?Si j'ai bien compris, ça sert à ce que le kernel puisse s'installer sur un hd, en l'occurrence IDE pour moi , ça charge le module qui gère les IDE puis le kernel s'y installe... Comprends pas ... HELP (Note à moi-même : expliquer ça dans le topic noyau, pour pas le dire plusieurs fois...) (EDIT : c'est fait!) L'initrd est un disque virtuel sur lequel sont stockés les modules nécessaires au boot sur le disque dur voulu... Vu que en général, c'est mis en dur dans le noyau, ça sert à rien (surtout quand c'est pour booter sur un simpmoe DD PATA IDE) j'ai déjà vu l'utilité pour booter sur un contrôleur raid Highpoint avec modules prorpio...mais sinon, non, ça sert à rien... (ah si : avoir une ligne de commande très simplifiée si il y a un problème...)
-rem- Posté(e) le 19 août 2004 Posté(e) le 19 août 2004 j'ai déjà vu l'utilité pour booter sur un contrôleur raid Highpoint avec modules prorpio...mais sinon, non, ça sert à rien... ouais, en gros si tu as un matos exotique et que ton noyau a besoin de charge des controleurs ou autre avant de pouvoir booter, le initrd sert a ca. Donc, comme le dit tuxxx, ca ne sert a rien, dans 95% des cas.
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.