Soucis de passerelle

oups! me suis trompé de poste.

excusez-moi

Et ça marche aussi, miracle :-)
Reste plus que le support usb et la carte reseau et j'ai tout ce qu'il faut.

Merci encore :-)

Bon ça c'est pour le noyau Mandrake, maintenant je vais voir ce que ça donne avec la config que j'avais fait de A à Z....

A priori, vu que j'avais la même erreur pour les deux, ça devrait marcher maintenant :-)

Je vais voir ça....

Ca maaaaarche :-)

J'y croyais plus.... Pour le coup je ne sais pas d'ou ça venait, mrproper ou devfs... En tout cas merci pour tout, dommage que tu sois pas membre, je t'aurais offert un verre au café des membres.... :-)

Ok, je vais changer mon script et désactiver devfs...

Merci encore pour tout.... Je compile et je t'en dis des nouvelles :-)

Pour ton script de compilation, je crois ce n'est pas bien de faire un "make clean" apres le "make xconfig" (ou "make oldconfig"). Le "make xconfig" fait eventuellement de choses necessaires pour la compilation qui sont effaces par le "make clean". En fait si tu ne modifies pas les sources (par un patch etc.) tu peux tout a fait changer la config avec "make xconfig" et apres directement recompiler avec "make bzImage" et "make modules" sans faire "make clean" ! L'avantage ca ne compilera que les choses necessaires (ou il y a de modif de la config) et ca ira plus vite. Si tu fais ca dans l'affichage de la version du noyau il y a un petit numero dans

cat /proc/version 
Linux version 2.6.11-rc4 (kmf@albireo) (gcc version 3.3.5) #1 Sun Feb 13 16:14:29 CET 2005

quit change: le "#1" derrier la version de gcc devient "#2" etc. si tu fais une deuxieme compilation apres une modif de la config sans "make clean/mrproper". C'est uniquement une affichage et ca marche tres bien meme avec "#2", "#3" etc.

Par contre apres tout "make clean" il faut refaire le "make xconfig" ou "make oldconfig" et avec ca ce numero revient a "#1".

Moi te proposerais un script comme:

cp .config config   
make mrproper   
cp config .config  
make oldconfig  # ou:  "make xconfig" on changer la config
make bzImage
make modules
make modules_install

cp ./arch/i386/boot/bzImage /boot/vmlinuz-2.6.10

# ou une solution plus generale pout toute future version du noyau:
KVERSION=`grep UTS include/linux/version.h | cut -d \  -f 3 | cut -d \" -f 2`

cp arch/i386/boot/bzImage /boot/vmlinuz-$KVERSION
cp System.map /boot/System.map-$KVERSION  # c'est un truc pour les symboles des modules (importance modeste)
cp  .config /boot/config-$KVERSION  # pour garder une copie de la config avec l'image du noyau

(Les "rm ..." ne sont pas necessaires. En principe c'est fait par le "make modules_install" et le dernier "cp ..." mais ce n'est qu'un detail.)
La partie avec "make mrproper" peut etre enlevee si on veut.

Pour ton dmesg, je vois cette difference entre toi:
hda: 7056000 sectors (3612 MB) w/96KiB Cache, CHS=7000/16/63, DMA
hda: cache flushes not supported
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 >


et moi:
hda: 26564832 sectors (13601 MB) w/2048KiB Cache, CHS=26354/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 >


C'est certainement relie au "devfs" que tu as active. Je crois il faut le deactiver, ce n'est pas necessaire en faite meme obsolete (selon le texte help du noyau dans "make xconfig"). Ce truc n'est pas necessaire pour acceder ou fichiers devices /dev/hda1, ... etc. au contraire les deux sont mutuellement exclusives. Si le noyau mount le device-filesystem au dessus /dev/... (a voir dans ton dmesg: Mounted devfs on /dev) il va cacher les anciens fichiers devices qui s'y trouve. Donc essaies avec devfs deactive!

Par contre j'ai vu que je pouvais avoir un dmsg...
Je vais l'enregistrer sur mon disque et le mettre en ligne quelque part et je mettrais le lien ici.

Merci.

En fait j'ai une Debian Sid. Et pour le coup j'ai la dernière version:
module-init-tools 3.2-pre1

Je crois j'ai compris ton probleme, si c'est ca ce n'est meme pas la config du noyau ou sa compilation qui est en cause, c'est la version des utilitaires pour charger les modules (insmod, modprobe, depmod, ...). En fait, ca explique tout et c'est le meme piege dans lequel je suis tombe une fois, mais j'avais completement oublie ou disons je pensais sur une debian sarge ca devrait bon (car il y a un paquet noyau 2.6 la dessus).
Alors, entre noyau 2.4 et 2.6 il y a un grand basculement pour modprobe, insmod, etc. (pas seulement une nouvelle version mais un nouveau paquet!) et sur un systeme qui est initialement prevu pour 2.4 il ne suffit pas de compiler un noyau 2.6, il faut aussi installer la nouvelle version pour ces utilitaires!! C'est pour ca que je conseille aux gens qui veulent mettre a jours un noyau sur un systeme base sur 2.4 (par exemple Redhat 2.4) de prendre le dernier 2.4 et pas 2.6, car sinon il faut aussi faire d'autre operations delicates.

Concretement: Pour verifier chez toi, mets toi en root et tapes la commande:

/sbin/depmod -V

pour afficher la version, si ca affiche un truc: "depmod 2.4.xx" (ou xx est un nombre autour de 18 - 30) c'est l'ancienne version qui est active chez toi. Le nom du paquet pour cette version est: modutils.

Pour que ca marche avec un noyau 2.6 il faut que la bonne version soit quelque chose comme: "module-init-tools 3.1". Ici 3.1 c'est une version tres recente (3.0 pourrait aussi aller, eventuellement avec de sous-versions 3.0-pre9 ou similaire, la dernier est 3.2-pre1). Le nom de paquet pour ca s'appelle module-init-tools et c'est celui la qu'il faut absoluement avoir pour un noyau 2.6, sinon le chargement de modules ne fonctionne pas (exactement ton probleme du boot!!).

Il semble pour Debian sarge il y a un paquet "modules-init-tools" mais il est possible que tu ne l'as pas installe car tu as pris un noyau 2.4. Donc il te suffit de le chercher et l'installer et tout est bon.

Sinon tu peux aussi prendre le paquet tar, par exemple ici:
ftp://ftp.fr.kernel.org/pub/linux/utils/kernel/module-init-tools/
mais si tu veux installer a partir des sources il faut faire tres attention pour ne pas effacer les anciens modutils (il y a une procedure pour ca decrite dans INSTALL et README, tres soigneusement lire).

Au fait mon problème n'a rien à voir avec les modules ide. Ce sont les modules contenus dans /etc/modules pour le 2.4.

Le problème c'est au niveau des /dev/hdax qui n'apparaissent pas....

Oui pas de soucis.
J'ai fait tellement de tests que j'ai fini par me faire petit script bash pour chaque compilation:

rm -f /boot/vmlinuz-2.6.10
rm -fr /lib/modules/2.6.10

make clean   # Je me disais bien que mrpoper enlevait le .config, donc j'ai gardé clean
make bzImage
make modules
make modules_install

cp ./arch/i386/boot/bzImage /boot/vmlinuz-2.6.10

Puis je relance grub...
Non vraiment pas de soucis d'ailleurs les messages au démarrage changent selon ma config, et à chaque fois que je change la config je fais toujours make menuconfig puis je sauve à la fin.

J'ai aussi modifié mon fstab pour rajouter sysfs, devfs, devpts...
Ca n'a rien changé mais je suis prêt à parier que mon problème ne vient pas du noyau mais plutôt d'un truc à configurer quelque part et qui change d'un système configuré pour le 2.4 quand on le passe vers un 2.6.

Une petite question pour en etre sur:
Tu fais bien un truc: <<make "blabla"config>> entre copie de .config vers le repertoire source et le "make bzImage" (ou le "make" tout court) ?? Il faut toujours faire ca meme si on ne modifies pas de tout la config, dans ce cas on peut faire "make oldconfig", explicitement:

cd repertoire_sources_noyeau
cp /ailleur/autre_config .config
make oldconfig
make bzImage
make modules

et apres on peut installer (en root) avec "make modules_install" pour les modules et copier "arc/i386/boo/bzImage" vers /boot/... avec un nouveau nom et actualiser grub/lilo.

Si on ne fait pas le "make oldconfig" (ou "make menuconfig", "make xconfig", ... avec saufgarde du ficher .config) ca ne marche pas correctement! Ca compile peut-etre quelque chose sans message d'erreur mais pas forcement ce qui est prevu dans .config!! La commande "make oldconfig" (et les autres) cree de dependances cruciales pour la compilation.
Si on change beaucoup de choses (surtout apres l'application d'un patch) il est aussi recommande de faire "make mrproper" pour le nettoyage des sources (attention: ca efface aussi le .config !!).
Tu peux ajouter "make mrproper" ci-dessus apres le "cd ..." et avant le "cp ....".

Bonsoir,

Ca n'a pas marché, pas plus que le .config de la 2.6.7-mdk livrée par défault avec le kernel source de la mandrake 10.0.

Je vais essayé de prendre le kernel debian par apt-get et de le compiler avec la methode debian. On verra bien....

Pratique le dmesg...

Pour ce qui est de Generic PCI bus-master DMA support j'ai tout selectionné (pas réussi à me debrouiller avec le dmesg)... Je recompile et si ça marche pas j'irais voir du côté de PCI IDE chipset support ...

Merci encore :-)

Woah merci beaucoup!!! :-)
Je vais voir ça tout de suite :-)

Alors si ca peut t'aider, voici les options apropos IDE que j'ai dans mon fichier .config:

CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y

Pour info j'ai obtenu cet output avec:
grep IDE .config | grep -v "#" | grep -v "PARIDE"

Avec ca, ca marche en principe. Certainement on peut faire de facon differente mais tu peux quand-meme comparer avec ta config s'il manque un truc crucial.
Apres il faut aussi veiller de mettre le bon chipset dans:
PCI IDE chipset support
La dedans il faut d'abord selectionner le Generic PCI IDE Chipset Support. Je crois avec ca, ca marche deja mais pas de facon optimale (pas de DMA etc.). Pour ca il faut aussi chosir le bon driver specialise pour ta carte mere (voir en dessous dans: Generic PCI bus-master DMA support). En cas de doute tout selectionner. En principe l'info sur le chipset/driver est affichee dans l'output de "dmesg" (si tu as un autre noyau qui marche bien pour demarrer).

Quand j'ai compile pour la 1ere fois un noyau 2.6 (c'etait le tout premier: 2.6.0-test1) j'ai pris une config 2.4 et ca a ete une vraie catastrophe. J'avais un ecran noir avec le 1er boot. Le boot avancait quand meme mais on ne voyait rien. J'ai vu apres qu'il a fallu de veiller d'ajouter le terminal texte dans la config (le truc le plus elementaire et le plus crucial qui affiche de choses en texte pendant le boot!). En fait dans le 2.6 on peut deselectionner ca pour compiler de noyaux pour les "embedded devices" (linux dans un telephone portable ou un autre appareil ou il n'y a pas d'ecran avec clavier).

Normalement il faut vraiement prendre une config generale de Mandrake, Fedora qui marche bien!

Bonne chance.

Bon ça avance très doucement.
Je ne me sert plus du initrd. J'ai fait fait un Kernel avec l'essentiel compilé en dur (sauf l'usb).

Maintenant il démarre, detecte bien mes periphériques ide avec le nom du disque dur et le cdrom.
Par contre il me dit qu'il y a une erreur lors de la vérification de fsck (impossible d'ouvrir /dev/hda6 => mon home).
Il me propose de réparer ça manuellement. Et je vois qu'il n'ya pas de /dev/hda1 ou /dev/hda6 ni /dev/hda tout court dans /dev
Et la commande fdisk -l ne donne rien.

Puis je passe, et il démarre bien les services cron, sshd mais il s'arrête après le cron (là ou il devrait y avoir la fin du boot => la console).

J'ai remarqué un truc, juste avant l'erreur fsck j'ai ceci:

Loading modules
ide-cd
FATAL : Module ide-cd not found
ide-detect
FATAL : Module ide-detect not found

Mais pourtant tou ce qui est ide je l'ai compilé en dur :'-(

Je commence à me sentir comme un Calimero dans un monde de pingouin....

Ok merci pour tout ces renseignements ^^

Bon j'ai recompilé avec la config Mandrake mais j'ai eu le même soucis. Si je ne signale pas le initrd dans mon grub il démarre mais s'arrête en me disant qu'il ne trouve pas le init.....

Je crois qu'il n'a pas un bon accés au disque dur, en plus ce noyau n'a rien ecris dans le syslog ni dans messages. Et les messages au démarrage vont trop vite... En gros, c'est presque impossible de detecter l'erreur.

Je vais tenter autre chose. Compiler un kernel moins modulaire. Je vais selectionner le strict minimum par rapport à mon matériel et je met l'usb et autres trucs auxilliaires en modules....

On va voir ce que ça donne.... Je finirai par y arriver O_O

Le initrd est uniquement necessaire pour charger les modules indispensable pour acceder a ton disque dur, ca concerne typiquement les drivers de scsi, peut-etre sata et ext3. Le module ext3 peut etre mis en directe pendant que pour les autres ce n'est eventuellement pas possible. Je crois les drivers scsi ne marche qu'en module et pas en directe. Peut-etre c'est aussi le cas pour sata qui est similaire a scsi dans la gestion de driver linux.
Donc si tu n'as pas de disques scsi/sata tu n'as pas besoin d'initrd. Meme si tu laisses ext3 en module ca devrait marcher sans initrd car pour le 1er mount en lecture ca marche aussi avec le driver ext2 (seulement il n'a pas acces au journal de recuperation). Apres verifications de disque on pourra charger le driver ext3 depuis le disque dur et apres il y a le remount en ecriture pour la racine et le mount des autres partitions qui marchera en ext3 car a ce moment le module a ete charge depuis le disque dur. En principe ca marche aussi, je l'ai deja essaye. Cependant c'est quand meme mieux de mettre ext3 en direct.

Pour tous les autres modules (usb, ipfilter, ....) le noyau pourra le charger a partir de la copie sur disque dur, c.-a-d. depuis /lib/modules/2.6.10/....

En fait j'avais configuré en passant en revue chaque option, justement pour avoir un kernel leger. Ca n'avait pas marché à cause de cette option de ext3 je pense.

Comme j'ai perdu mon .config (ô rage, j'avais passé un après-midi à tout configurer...) j'ai pris le .config de ma mandrake (noyau 2.6.10) pour être sûr que ça marche. Après si ça marche j'enlèverais les options inutiles.

Mais alors le initrd, ce n'est pas indispensable pour charger les modules? argh...

Pour le nom du initrd je l'ai appelé comme ça car mon noyau de base possède un nom d'image assez particulier, donc pas de soucis. De toutes façon j'ai changé en initrd.img-2.6.10 depuis hier...