Depuis une r=E9cente mise =E0 jour (debian unstable) j'ai un probl=E8me ave=
c l'ordre
de chargement de mes modules r=E9seaux.
J'ai le fichier l=E0 :
root @ Gatsu # cat /etc/modprobe.d/networks=20
alias eth1 skge
alias eth0 via_rhine
et pourtant lors du boot il s'obstine =E0 charger skge sur eth0 et via_rhin=
e sur
l'eth1
/var/log/syslog.0
Jan 7 14:45:28 localhost kernel: input: PC Speaker as /class/input/input1
Jan 7 14:45:28 localhost kernel: GSI 19 sharing vector 0xC1 and IRQ 19
Jan 7 14:45:28 localhost kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GS=
I 17 (level, low) -> IRQ 19
Jan 7 14:45:28 localhost kernel: skge 1.2 addr 0xfdc00000 irq 19 chip Yuko=
n-Lite rev7
Jan 7 14:45:28 localhost kernel: skge eth0: addr 00:11:d8:22:0d:60
Jan 7 14:45:28 localhost kernel: ACPI: PCI Interrupt 0000:00:10.3[B] -> GS=
I 21 (level, low) -> IRQ 17
Jan 7 14:45:28 localhost kernel: PCI: Via IRQ fixup for 0000:00:10.3, from=
10 to 1
Jan 7 14:45:28 localhost kernel: uhci_hcd 0000:00:10.3: UHCI Host Controll=
er=20
Jan 7 14:45:28 localhost kernel: uhci_hcd 0000:00:10.3: new USB bus regist=
ered, assigned bus number 4
Jan 7 14:45:28 localhost kernel: uhci_hcd 0000:00:10.3: irq 17, io base 0x=
0000c400
Jan 7 14:45:28 localhost kernel: hub 4-0:1.0: USB hub found
Jan 7 14:45:28 localhost kernel: hub 4-0:1.0: 2 ports detected
Jan 7 14:45:28 localhost kernel: usb 1-1: new low speed USB device using u=
hci_hcd and address 2
Jan 7 14:45:28 localhost kernel: via-rhine.c:v1.10-LK1.2.0-2.6 June-10-200=
4 Written by Donald Becker
Jan 7 14:45:28 localhost kernel: GSI 20 sharing vector 0xC9 and IRQ 20
Jan 7 14:45:28 localhost kernel: ACPI: PCI Interrupt 0000:00:0d.0[A] -> GS=
I 18 (level, low) -> IRQ 20
Jan 7 14:45:28 localhost kernel: PCI: Via IRQ fixup for 0000:00:0d.0, from=
5 to 4
Jan 7 14:45:28 localhost kernel: eth1: VIA Rhine II at 0x1b000, 00:50:ba:6=
b:80:04, IRQ 20.
Jan 7 14:45:28 localhost kernel: eth1: MII PHY found at address 8, status =
0x782d advertising 01e1 Link 45e1.
Si quand je prends la main je fais :
root @ Gatsu # ifdown eth0
root @ Gatsu # ifdown eth1
root @ Gatsu # rmmod skge via_rhine
root @ Gatsu # ifup eth0
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lhabert
Johann Heymes :
alias eth1 skge alias eth0 via_rhine
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore, alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »). Les interfaces sont juste nommées ethi puis ethi+1 puis ethi+2 etc dans l'ordre de création. Donc, par exemple, si tu n'as aucun des deux modules chargés, et que tu fais un ifup eth1, skge va être chargé mais va créer l'interface eth0... En fait, ce qui se passe dans ton cas, c'est plus probablement que les modules skge et via_rhine sont chargés automatiquement au boot (genre si tu utilises udev), et skge crée son interface avant via_rhine...
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune de tes interfaces, indépendament de l'ordre de chargement. Une solution plus simple (et peut-être moins fiable, mais chez moi, ça marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne sais pas si ça assure vraiment que via_rhine créera son interface avant skge).
Johann Heymes :
alias eth1 skge
alias eth0 via_rhine
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye
d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore,
alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que
l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »).
Les interfaces sont juste nommées ethi puis ethi+1 puis ethi+2 etc dans
l'ordre de création. Donc, par exemple, si tu n'as aucun des deux modules
chargés, et que tu fais un ifup eth1, skge va être chargé mais va créer
l'interface eth0... En fait, ce qui se passe dans ton cas, c'est plus
probablement que les modules skge et via_rhine sont chargés automatiquement
au boot (genre si tu utilises udev), et skge crée son interface avant
via_rhine...
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune
de tes interfaces, indépendament de l'ordre de chargement.
Une solution plus simple (et peut-être moins fiable, mais chez moi, ça
marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne
sais pas si ça assure vraiment que via_rhine créera son interface avant
skge).
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore, alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »). Les interfaces sont juste nommées ethi puis ethi+1 puis ethi+2 etc dans l'ordre de création. Donc, par exemple, si tu n'as aucun des deux modules chargés, et que tu fais un ifup eth1, skge va être chargé mais va créer l'interface eth0... En fait, ce qui se passe dans ton cas, c'est plus probablement que les modules skge et via_rhine sont chargés automatiquement au boot (genre si tu utilises udev), et skge crée son interface avant via_rhine...
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune de tes interfaces, indépendament de l'ordre de chargement. Une solution plus simple (et peut-être moins fiable, mais chez moi, ça marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne sais pas si ça assure vraiment que via_rhine créera son interface avant skge).
Pascal Hambourg
Salut,
Johann Heymes :
alias eth1 skge alias eth0 via_rhine
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore, alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »).
En bref, c'est un piège abscons (pour être poli).
En fait, ce qui se passe dans ton cas, c'est plus probablement que les modules skge et via_rhine sont chargés automatiquement au boot (genre si tu utilises udev),
Ou par hotplug. Dans ce cas une solution peut être de mettre ces modules dans la liste noire des modules à ne pas charger par hotplug. C'est dans /etc/hotplug/blacklist, je crois.
Mais ce n'est qu'un emplâtre sur une jambe de bois car je persiste à proclamer qu'une bidouille infâme comme l'alias qui peut faire que "ifconfig eth1" monte en fait eth0 est à éviter comme la peste.
et skge crée son interface avant via_rhine...
C'est bien ce qu'indique le log.
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune de tes interfaces, indépendament de l'ordre de chargement.
Ou nameif.
Une solution plus simple (et peut-être moins fiable, mais chez moi, ça marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne sais pas si ça assure vraiment que via_rhine créera son interface avant skge).
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie. S'il n'est pas devenu obsolète sous Sid...
Salut,
Johann Heymes :
alias eth1 skge
alias eth0 via_rhine
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye
d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore,
alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que
l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »).
En bref, c'est un piège abscons (pour être poli).
En fait, ce qui se passe dans ton cas, c'est plus
probablement que les modules skge et via_rhine sont chargés automatiquement
au boot (genre si tu utilises udev),
Ou par hotplug. Dans ce cas une solution peut être de mettre ces modules
dans la liste noire des modules à ne pas charger par hotplug. C'est dans
/etc/hotplug/blacklist, je crois.
Mais ce n'est qu'un emplâtre sur une jambe de bois car je persiste à
proclamer qu'une bidouille infâme comme l'alias qui peut faire que
"ifconfig eth1" monte en fait eth0 est à éviter comme la peste.
et skge crée son interface avant via_rhine...
C'est bien ce qu'indique le log.
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune
de tes interfaces, indépendament de l'ordre de chargement.
Ou nameif.
Une solution plus simple (et peut-être moins fiable, mais chez moi, ça
marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne
sais pas si ça assure vraiment que via_rhine créera son interface avant
skge).
J'ai toujours fait ainsi en mentionnant les modules que je veux charger
dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian
Potato/Woody/Sarge qui est lu avant hotplug et compagnie. S'il n'est pas
devenu obsolète sous Sid...
Tout l'effet que ça a, est que si un programme (genre ifconfig) essaye d'accéder à eth0 (resp eth1) et que cette interface n'existe pas encore, alors le module via_rhine (resp skge) va être chargé, mais rien ne dit que l'interface réseau qu'il va créer va être appellée « eth0 » (resp « eth1 »).
En bref, c'est un piège abscons (pour être poli).
En fait, ce qui se passe dans ton cas, c'est plus probablement que les modules skge et via_rhine sont chargés automatiquement au boot (genre si tu utilises udev),
Ou par hotplug. Dans ce cas une solution peut être de mettre ces modules dans la liste noire des modules à ne pas charger par hotplug. C'est dans /etc/hotplug/blacklist, je crois.
Mais ce n'est qu'un emplâtre sur une jambe de bois car je persiste à proclamer qu'une bidouille infâme comme l'alias qui peut faire que "ifconfig eth1" monte en fait eth0 est à éviter comme la peste.
et skge crée son interface avant via_rhine...
C'est bien ce qu'indique le log.
Tu peux regarder du côté de ifrename pour donner un nom canonique à chacune de tes interfaces, indépendament de l'ordre de chargement.
Ou nameif.
Une solution plus simple (et peut-être moins fiable, mais chez moi, ça marche (tm)) est de s'assurer que via_rhine soit chargé avant skge (je ne sais pas si ça assure vraiment que via_rhine créera son interface avant skge).
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie. S'il n'est pas devenu obsolète sous Sid...
lhabert
Pascal Hambourg :
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le /etc/modules arrive trop tard.
Pascal Hambourg :
J'ai toujours fait ainsi en mentionnant les modules que je veux charger
dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian
Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le
/etc/modules arrive trop tard.
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le /etc/modules arrive trop tard.
Pascal Hambourg
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le /etc/modules arrive trop tard.
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces réseau ne sont pas dans /dev.
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous dis, même s'il y des choses qui me font envie du côté de Netfilter...
J'ai toujours fait ainsi en mentionnant les modules que je veux charger
dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian
Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le
/etc/modules arrive trop tard.
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces
réseau ne sont pas dans /dev.
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous
dis, même s'il y des choses qui me font envie du côté de Netfilter...
J'ai toujours fait ainsi en mentionnant les modules que je veux charger dans l'ordre que je souhaite dans le fichier /etc/modules sous Debian Potato/Woody/Sarge qui est lu avant hotplug et compagnie.
Euh, chez moi, j'ai S04udev et S20module-init-tools, donc a priori, le /etc/modules arrive trop tard.
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces réseau ne sont pas dans /dev.
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous dis, même s'il y des choses qui me font envie du côté de Netfilter...
lhabert
Pascal Hambourg :
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces réseau ne sont pas dans /dev.
En fait, ils ont décidé de mettre udevsend dans /proc/sys/kernel/hotplug, donc udev fait également le boulot de l'ancien /sbin/hotplug... Et le S04udev appelle un programme nommé « udevsynthesize », qui scanne le /sys/bus à la recherche des devices et crée des évènements hotplugs synthétiques leur correspondant...
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous dis, même s'il y des choses qui me font envie du côté de Netfilter...
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on arrive à avoir un système qui marche.
Pascal Hambourg :
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces
réseau ne sont pas dans /dev.
En fait, ils ont décidé de mettre udevsend dans /proc/sys/kernel/hotplug,
donc udev fait également le boulot de l'ancien /sbin/hotplug... Et le
S04udev appelle un programme nommé « udevsynthesize », qui scanne le
/sys/bus à la recherche des devices et crée des évènements hotplugs
synthétiques leur correspondant...
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous
dis, même s'il y des choses qui me font envie du côté de Netfilter...
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant
le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones
du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on
arrive à avoir un système qui marche.
Mais si j'ai bien compris udev s'occupe de /dev, or les interfaces réseau ne sont pas dans /dev.
En fait, ils ont décidé de mettre udevsend dans /proc/sys/kernel/hotplug, donc udev fait également le boulot de l'ancien /sbin/hotplug... Et le S04udev appelle un programme nommé « udevsynthesize », qui scanne le /sys/bus à la recherche des devices et crée des évènements hotplugs synthétiques leur correspondant...
Quel bordel, c'est pas demain la veille que je passe en 2.6, je vous dis, même s'il y des choses qui me font envie du côté de Netfilter...
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on arrive à avoir un système qui marche.
Tom
Salut Johann, la forme ? Qu'est-ce que tu deviens ?
Euh j'ai pas de réponse à ton problème, mais par contre j'ai le même problème que toi avec le wifi et le firewire : ils se battent pour être en eth1 et fouter l'autre en eth2. La carte réseau est la reine du eth0 car j'ai mis le driver en dur dans le noyau :-)
-- Tom
Salut Johann, la forme ? Qu'est-ce que tu deviens ?
Euh j'ai pas de réponse à ton problème, mais par contre j'ai le même
problème que toi avec le wifi et le firewire : ils se battent pour être
en eth1 et fouter l'autre en eth2. La carte réseau est la reine du eth0
car j'ai mis le driver en dur dans le noyau :-)
Salut Johann, la forme ? Qu'est-ce que tu deviens ?
Euh j'ai pas de réponse à ton problème, mais par contre j'ai le même problème que toi avec le wifi et le firewire : ils se battent pour être en eth1 et fouter l'autre en eth2. La carte réseau est la reine du eth0 car j'ai mis le driver en dur dans le noyau :-)
-- Tom
Nicolas George
Luc Habert wrote in message <dpp1lo$2gbc$:
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on arrive à avoir un système qui marche.
Ouh là, tu veux vraiment étaler ta grotesquitude le plus largement possible !
Comme je l'ai déjà signalé ailleurs, udev (les versions récentes) charge les modules qu'il détecte nécessaires avec simplement modprobe sur un alias décrivant ses identifiants, quelque chose comme usb:v046Dp08A2d0100dc00dsc00dp00ic01isc02ip00 (ceci est une souris USB). Il suffit, pour désactiver le chargement automatique d'un module donné, de mettre un alias sur ce module. D'ailleurs, c'est comme ça que fonctionne le chargement : on trouve dans /lib/modules/`uname -r`/ un fichiers modules.alias construit automatiquement qui contient des lignes du style :
alias usb:v*p*d*dc*dsc*dp*ic03isc*ip* usbhid
Luc Habert wrote in message <dpp1lo$2gbc$1@nef.ens.fr>:
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant
le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones
du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on
arrive à avoir un système qui marche.
Ouh là, tu veux vraiment étaler ta grotesquitude le plus largement
possible !
Comme je l'ai déjà signalé ailleurs, udev (les versions récentes) charge les
modules qu'il détecte nécessaires avec simplement modprobe sur un alias
décrivant ses identifiants, quelque chose comme
usb:v046Dp08A2d0100dc00dsc00dp00ic01isc02ip00 (ceci est une souris USB). Il
suffit, pour désactiver le chargement automatique d'un module donné, de
mettre un alias sur ce module. D'ailleurs, c'est comme ça que fonctionne le
chargement : on trouve dans /lib/modules/`uname -r`/ un fichiers
modules.alias construit automatiquement qui contient des lignes du style :
Bah, en mettant udev_root=/udev dans /etc/default/udev.conf, et en modifiant le /etc/rc.d/udev pour masquer temporairement par un mount --bind les zones du /sys/bus où l'on ne veut pas que udevsynthesize aille fourrer son nez, on arrive à avoir un système qui marche.
Ouh là, tu veux vraiment étaler ta grotesquitude le plus largement possible !
Comme je l'ai déjà signalé ailleurs, udev (les versions récentes) charge les modules qu'il détecte nécessaires avec simplement modprobe sur un alias décrivant ses identifiants, quelque chose comme usb:v046Dp08A2d0100dc00dsc00dp00ic01isc02ip00 (ceci est une souris USB). Il suffit, pour désactiver le chargement automatique d'un module donné, de mettre un alias sur ce module. D'ailleurs, c'est comme ça que fonctionne le chargement : on trouve dans /lib/modules/`uname -r`/ un fichiers modules.alias construit automatiquement qui contient des lignes du style :
alias usb:v*p*d*dc*dsc*dp*ic03isc*ip* usbhid
Johann Heymes
Re,
Ok merci c'est bien ce que je pensais... C'est ce foutu chargement automati que de module qui m'en ...
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ? C'est très con étant donné que le fichier qui configure les NICs (/etc/network/interfaces) se base sur le nom de l'interface réseau (ethXX )
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ç a répare après coup...
Quelqu'un a une (autre?) idée ?
Merci,
Johann.
Re,
Ok merci c'est bien ce que je pensais... C'est ce foutu chargement automati que
de module qui m'en ...
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ?
C'est très con étant donné que le fichier qui configure les NICs
(/etc/network/interfaces) se base sur le nom de l'interface réseau (ethXX )
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ç a répare
après coup...
Ok merci c'est bien ce que je pensais... C'est ce foutu chargement automati que de module qui m'en ...
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ? C'est très con étant donné que le fichier qui configure les NICs (/etc/network/interfaces) se base sur le nom de l'interface réseau (ethXX )
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ç a répare après coup...
Quelqu'un a une (autre?) idée ?
Merci,
Johann.
Nicolas George
Johann Heymes wrote in message
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ?
ifrename/nameif est la bonne solution.
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ça répare après coup...
Il est vrai qu'il serait plus propre si l'interface existait de plein droit dans /dev, avec udev derrière pour faire un lien symbolique, serait beaucoup plus satisfaisante. Mais la solution avec ifrename/nameif marche en pratique fiablement, ce qui quand même l'essentiel.
Johann Heymes wrote in message
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ?
ifrename/nameif est la bonne solution.
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ça
répare après coup...
Il est vrai qu'il serait plus propre si l'interface existait de plein droit
dans /dev, avec udev derrière pour faire un lien symbolique, serait beaucoup
plus satisfaisante. Mais la solution avec ifrename/nameif marche en pratique
fiablement, ce qui quand même l'essentiel.
Et donc y a pas de solution pour dire tel NIC je veux qu'elle soit sur eth0 ?
ifrename/nameif est la bonne solution.
Pour ce qui est de ifrename ça a l'air aussi un peu bidouille puisque ça répare après coup...
Il est vrai qu'il serait plus propre si l'interface existait de plein droit dans /dev, avec udev derrière pour faire un lien symbolique, serait beaucoup plus satisfaisante. Mais la solution avec ifrename/nameif marche en pratique fiablement, ce qui quand même l'essentiel.
