[Résolu] Module ip_tables not found

Support Debian
#1

Voilà, j’ai installé à la sauce debian un nouveau kernel, le 2.6.16.8 qui fonctionne très bien, sauf que je n’ai plus ip_tables. J’ai donc cherché à résoudre le problème avec un make menuconfig => Networking => Networking options => Network packet filtering (replaces ipchains) => Core Netfilter Configuration, puis en activant Netfilter Xtables support ainsi que les modules qui apparaissent ensuite. J’ai alors tout sauvé et recompilé avec un make modules, avant de faire un make modules_install, un depmod -a, reboot et toujours rien. A priori, il aurait peut-être quelques soucis sur ip_tables avec le noyau 2.6.1.8. Si quelqu’un a une solution, je suis preneur. Pierre

PS => j’ai compilé mon nouveau noyau dans mon $HOME. Puis installer les fichiers *.deb kernel-image et kernel-headers via un dpkg -i.

Voilà ce que me retourne $locate ip_tables :

[quote]/usr/include/linux/netfilter_ipv4/ip_tables.h
/usr/src/kernel-headers-2.6.8-2/include/linux/netfilter_ipv4/ip_tables.h
/usr/src/kernel-headers-2.4.27-2-386/include/linux/modules/ip_tables.stamp
/usr/src/kernel-headers-2.4.27-2-386/include/linux/modules/ip_tables.ver
/usr/src/kernel-headers-2.6.16.8-bpier-386/include/linux/netfilter_ipv4/ip_tables.h
/usr/src/kernel-headers-2.4.27-2/include/linux/netfilter_ipv4/ip_tables.h
/usr/src/kernel-headers-2.4.27-2/include/linux/modules/ip_tables.stamp
/usr/src/kernel-headers-2.4.27-2/include/linux/modules/ip_tables.ver
/home/bpier/utils/kernel/linux-2.6.16.8/include/linux/netfilter_ipv4/ip_tables.h/home/bpier/utils/kernel/linux-2.6.16.8/net/ipv4/netfilter/ip_tables.c
/home/bpier/utils/kernel-2.6.16.19/linux-2.6.16.19/include/linux/netfilter_ipv4/ip_tables.h
/home/bpier/utils/kernel-2.6.16.19/linux-2.6.16.19/net/ipv4/netfilter/ip_tables.c
/lib/modules/2.4.27-2-386/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.6.8-2-386/kernel/net/ipv4/netfilter/ip_tables.ko[/quote]

Ne pas prêter attention au fichiers relatifs au kernel 2.6.16.19, je l’ai récupéré sur kernel.org, placé dans un dossier à part de mon $HOME, mais je ne l’ai ni compilé, ni installé.

Quant à # iptables -t filter -L:

[quote]FATAL: Module ip_tables not found.
iptables v1.2.11: can’t initialize iptables table `filter’: iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded[/quote]

#2

Bonsoir,
Ainsi, tu as du :

  • 2.6.8-2
  • 2.4.27-2-386
  • 2.6.16.8
  • (2.6.16.19)
    Et ip_tables.ko en 2.6.8-2-386 ?
    Ben où sont tes sources du noyau ?

$ apt-cache search linux-source-2.6.16 linux-patch-debian-2.6.16 - Debian patches to version 2.6.16 of the Linux kernel linux-source-2.6.16 - Linux kernel source for version 2.6.16 with Debian patches $ apt-cache policy linux-source-2.6.16 linux-source-2.6.16: Installé : 2.6.16-14 Candidat : 2.6.16-15 Table de version : 2.6.16-15 0 500 http://ftp.fr.debian.org sid/main Packages *** 2.6.16-14 0 100 /var/lib/dpkg/status $ locate ip_tables ..................................................................................................... /lib/modules/2.6.16camiptables/kernel/net/ipv4/netfilter/ip_tables.ko /usr/src/linux-source-2.6.16/debian/linux-image-2.6.16camiptables/lib/modules/2.6.16camiptables/kernel/net/ipv4/netfilter/ip_tables.ko
un truc fait pour : Recompilation de son kernel
Penser aux liens :
Dans [color=darkred]/usr/src[/color] :
linux -> /path/des/sources/du/noyau *

Dans [color=darkred]/lib/modules/lenoyaupourliqueltucompilelemodule[/color] :
build -> /usr/src/linux
source -> /usr/src/linux

  • linux-source ou kernel-source-xxx
#3

Pour compiler, j’ai utilisé la commande make-kpkg --append-to-version “custom-XXX” --initrd kernel_image modules_image kernel_headers. Sur les modules, ça n’est pas passé. Je me suis donc retrouvé, comme je le disais, avec deux *.deb, celui du kernel_image et celui du kernel_headers, que j’ai installé. Je me suis donc ensuite préoccupé de mon module fglrx, pour ma carte Ati Radeon et, une fois le *.deb construit, je l’ai installé à son tour. Cela dit, j’ai donc foiré sur le kernel-source.
Comme je le disais aussi, j’ai compilé dans mon $HOME, pour ne pas toucher au /usr/src/linux qui pointe sur mon /usr/src/noyau 2.6.8.2. Je croyais en effet qu’en compilant directement mon nouveau noyau dans /usr/src, il y aurait peut-être eu une incidence sur ma configuration en 2.6.8.2, qui marche bien. Je ne voulais pas la perdre. Est-ce une erreur d’appréciation de ma part ? Si oui, dois-je alors faire pointer mon dossier /usr/src/linux sur ~/chemin/de/monnouveaunoyau par un ln -s ~/chemin/de/monnouveaunoyau /usr/src/linux ? Ou dois-je simplement repasser par la case compilation du 2.6.16.8 pour obtenir, en plus, un paquet deb du nouveau kernel-source et l’installer ?

Avant de passer (récemment) à Debian, je n’avais jamais eu à me poser ces questions. D’où mon ignorance à ce sujet. Pour autant, je suis fort content d’être passé sous debian. Et, mea culpa de ma part, si je ne fréquente pas très souvent le forum en ce moment, c’est tout simplement parce que j’engloutis des tonnes d’infos, pour apprendre à mieux maîtriser mon nouvel OS.

#4

[quote=“bpier”]Cela dit, j’ai donc foiré sur le kernel-source.
Comme je le disais aussi, j’ai compilé dans mon $HOME, pour ne pas toucher au /usr/src/linux qui pointe sur mon /usr/src/noyau 2.6.8.2. Je croyais en effet qu’en compilant directement mon nouveau noyau dans /usr/src, il y aurait peut-être eu une incidence sur ma configuration en 2.6.8.2, qui marche bien. Je ne voulais pas la perdre. Est-ce une erreur d’appréciation de ma part ? Si oui, dois-je alors faire pointer mon dossier /usr/src/linux sur ~/chemin/de/monnouveaunoyau par un ln -s ~/chemin/de/monnouveaunoyau /usr/src/linux ? Ou dois-je simplement repasser par la case compilation du 2.6.16.8 pour obtenir, en plus, un paquet deb du nouveau kernel-source et l’installer ?[/quote]
newbie de chez Newbie alors ? :stuck_out_tongue:
regarde moi je suis passé newbie perseverant . j’étais dans le même cas que toi, ceci dit tu as peut-être l’avantage de connaitre les commandes Unix déjà, c’est non négligeable …
je te revoie au lien donné plus haut, tout y est, si tu comprends pas un passage demande, c’est pas toujours évident quand il nous manque une vision clair des choses et des définitions …
Les sources du noyau, tu peux les mettres ailleurs que dans /usr/src (affaire de préférence)
Le lien /usr/src/linux, pointe vers les SOURCES du noyau, pas vers le noyau.deb que tu viens de compiler, ni vers les sources d’un ancien noyau , ni vers les sources de ton noyau fraichement compilé …sources : les sources complètes (mais d’autre utilise les headers … moi je préfère les sources, j’ai pas tout compris de toute façon).
Si tu veux donc un jour recompiler, compiler un module pour ton ancien noyau, tu n’aura qu’à refaire (ln -s) les liens pour mettre à jours, c’est inévitable, ça prend 20 secondes, ça évite une nuit blanche …
moralité : lis le post Recompiler son kernel, et penses au liens quand tu te sera procuré les sources …

#5

Merci usinagaz. Avant Debian, j’étais successivement sous Fedora 1 (pas longtemps), Mandake 10, Fedora 3, puis 4. Comme j’en avais marre des galères de migrations d’une version de Fedora à l’autre, j’ai choisi Debian. et quelle bonne idée j’ai eue là. J’adore. Mais, pour autant, l’univers est quand même radicalement différent. Exemple qu’on finit par oublier : grâce aux outils fournis, un paquet *.deb se construit avec une facilité qu’ignorent les habitués des paquets logiciels *.rpm.

Cette parenthèse étant faite, voilà une question de newbie : le fichier /usr/src/linux qui pointe sur le noyau actif est-il essentiel au fonctionnement du système sous ce même noyau ? Faute de réponse à cette question, je n’ose pas y toucher.

Bon, maintenant, retour au lien que tu m’as donné dans ton premier post. Si j’ai d’autres questions de newbie, je ne me priverai pas de les poser.

#6

Re -
voilà ce que tu peux faire :

mv /usr/src/linux /usr/src/linux.odlversion ln -s /verslessourcesdunoyau/linux-source-xxx /usr/src/linux
Il te suffira de faire le mv inverse quand tu voudrais retoucher à l’ancien noyau …

mv /usr/src/linux /usr/src/linux.odlversion-2
mv /usr/src/linux.odlversion /usr/src/linux
ln -s /verslessourcesdunoyau/linux-source-xxx /usr/src/linux

par exemple, logiquement les liens build et sources de /lib/molules/noyau sont inchangés,vu qu’ils pointent toujours sur un lien linux qui lui-même pointe sur les sources (globales) du noyau traffiqué que tu traffique encore … et dont les sources sont un .deb qui n’a d’autre utilité que de pouvoir être transmis à quelqu’un par ftp mettons (ce .deb, pas la peine de l’installer par dpkg -i chez toi) … ce quelqu’un aura alors les sources d’un
noyau customisé qui ne lui sera profitable que si il a exactement le même matos que toi, autant dire que si il veut le recompiler, il va avoir un souci en l’absence des sources globales du noyau … tu me suis :unamused:

Le system ne se sert pas des sources vers lesquels les liens cités pointent pour fonctionner, du moins je crois pas, vu que ton system, c’est ton noyau, et qu’il a tout ce qu’il faut pour , si tu as bien compilé… autrement dit, ces liens sont importants lorsque tu veux modifier ton system, ton noyau … Là, il va avoir besoin des sources globales, là où c’est qu’il y a tout de linuxement possible de greffer … (i.e ip_tables.ko)

#7

quote="bpier"grâce aux outils fournis, un paquet *.deb se construit avec une facilité qu’ignorent les habitués des paquets logiciels *.rpm. (…)[/quote]Oh. Faut pas exagèrer, j’ai joué aussi avec des SRPMs, et c’est pas si compliqué.
La logique de conception est finalement assez proche.
Pas structurellement trés différente, quoi. C’est la gestion, aprés, qui change, mais bon.
Pour le reste:
debian.org/doc/manuals/refer … el.fr.html

Mais bon, chapeau usinagaz, ton explication, ça y est. C’est encore un peu … usinagaz :wink: mais du coup je vous laisse.

#8

Avec les SRPM, je suis d’accord avec toi, MattOtop. Ce d’autant qu’à l’origine, ce sont déjà des paquets préparés pour rpm, qui à l’arrivée te donne un paquet et son paquet-devel. Quant aux paquets source.tar.gz, c’est une autre histoire. Vise sur le net le nombre de sites consacrés à la création de rpm à partir de ceux-là. Sur les *.run, c’est encore une autre chose : je n’ai carrément rien trouvé. Or, sur Debian, avec un simple fichier *.run, tu fais juste, pour exemple, un “fakeroot ./ati-driver-installer-8.25.18-x86.run --buildpkg Debian/sarge” et tu obtiens alors le paquet *.deb qui va bien. De plus, pour convertir des rpm en deb, tu as la commande alien. Je n’ai pas souvenir, sous fedora, d’une telle souplesse, même si Fedora a ses avantages (notamment pour des gens comme moi, pas scientifiques pour un sou et qui n’ont jamais fait d’informatique à l’école - et puis, de mon temps, y’avait même pas de PC pour le grand public …). Cela dit, dans le fil de mon raisonnement, je peux toujours me tromper. Pierre

#9

Pour info, alien peut fonctionner dans l’autre sens aussi.
Mais sinon, c’est vrai que ça fait longtemps que j’ai quitté RedHat, donc tu dois mieux connaitre que moi.

#10

Y’a bien un petit problème entre ip_tables et le kernel-2.6.16. Il faut, lors du make menuconfig activer Netfilter xtables et le support iptables désactivé par défaut dans le noyau. Tout cela se trouve dans la branche Networking. Je recompile donc tout cela et vous tiens au courant.
voici un lien qui cause de ce problème : commentcamarche.net/forum/af … t-iptables

#11

bonsoir,
Oui oui, enfin j’ignorais que c’est à partir du 2.6.16 … mais c’est pourquoi on t’aiquillait vers la recompilation de toute façon …
merci pour l’info :wink:

#12

Merci usinagaz. La recompil a marché: Iptables fonctionne de nouveau. Pendant que j’y étais, j’ai installé le kernel-2.6.16.19. Maintenant je suis chaud pour tester le tout nouveau 2.6.17-1. Enfin, je ne peux absolument pas te dire quand ce problème d’iptables est apparu : je n’ai jamais compilé de kernel-2.6.14 et 2.6.15 sous debian.