Re: udev naming problems for eth*
Md wrote:
This reminds me that there should be a list of modules which MUST NOT be
added to the initramfs because loading them too early is both useless
and as in this case actively harmful.
I'm testing this solution:
I added a blacklist file in /etc/mkinitramfs/, put blacklist
net-module lines in it and added a line to /usr/sbin/mkinitramfs to
append these blacklist lines to initramfs' blacklist:
grep -v # ${CONFDIR}/blacklist ${DESTDIR}/etc/modprobe.d/blacklist
udev now can rename the interfaces, because they haven't a name yet.
furthermore this (or something similar) could be useful if we need some
modules not to appear in the initramfs.
cheers
davide
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. furthermore this (or something similar) could be useful if we need some modules not to appear in the initramfs. If you do not want to load modules in the initramfs then do not put them there in the first place. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. Maybe network interface renaming doesn't belong in udev, as they're really kernel assigned names. I think this point has been raised before, ( but I couldn't find any thread relating to it), but the right place to do that would be in the ifupdown package, that could have the right logic to do so. A (somewhat flawed) metaphor regarding this topic would be that IP address configuration doesn't belong in udev either. I've looked into the Suse sysconfig package, and it includes all the network configuration utils, such as ifup and dhcp handling, and they're coupled with the udev rules. As previously said those interactions are tricky, in order to guarantee that there are no race conditions. Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Some bug numbers talking about this: 182012 227283 Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: I've looked into the Suse sysconfig package, and it includes all the network configuration utils, such as ifup and dhcp handling, and they're coupled with the udev rules. As previously said those Look harder, because there is no reason to couple them. Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Wrong. OTOH it would be useful if ifupdown allowed reporting to udev the name of an interface given its MAC address. Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Wrong. I think that ifupdown maintainers are the ones who can say that for sure, looking at the bugs I didn't get that impression. OTOH it would be useful if ifupdown allowed reporting to udev the name of an interface given its MAC address. Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. The point is to call them with the kernel generated name, and let them to rename the iface. The bad is that then ifupdown should look at sysfs or some other place to get again the interface info. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Thu, Jan 19, 2006 at 12:54:32PM +0100, Marco d'Itri wrote: Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. When are those network hotplug handlers called? I've got udev loading the network drivers, then ifrename assigning fixed names, then whereami or ifupdown configuring the network. Where are the problems in this configuration? Is there a problem if the device was removed for example (pcmcia, usb etc)? Pre-udev I fixed this by adding modules to /etc/modules, which was processed before hotplug ran. Now udev runs earlier, making /etc/modules much less useful. :( thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Hamish Moffatt [EMAIL PROTECTED] wrote: Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. When are those network hotplug handlers called? When udev receives the events from the kernel, like for any other event. I've got udev loading the network drivers, then ifrename assigning fixed names, then whereami or ifupdown configuring the network. Where are the problems in this configuration? Is there a problem if the device was That if you use ifrename to rename the device then the hotplug agents run by udev will not know about the new name. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
Md wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. maybe I miss something, but for what I see we don't need udev not to load the modules: we just need they are not loaded *before* udev is ready to rename the interfaces. I can see only two ways to do that: 1) the modules are not loaded till udev starts the renaming process, and that, as I can see, only happens *after* /sbin/init starts 2) udev is ready to rename from within the initramfs T. Hood wrote: I just looked at the rename_netiface script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name this approach can only work if the names are not assigned yet. I cannot see any way we can swap two interfaces' names after they're assigned, at least not in user space (exept if we use rmmod, of course) cheers davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: maybe I miss something, but for what I see we don't need udev not to Indeed. udev can rename the modules without any need to mess with the initramfs or change anything else. Even if the driverss have already been loaded, network hotplug events will be synthesized at boot time. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
Davide Natalini [EMAIL PROTECTED] writes:
Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
As far as I can tell, network interface names are given by the kernel
and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
the system is debian sarge based, with udev version 0.076-6 and kernel
2.6.14-7-686-smp on a P4. the network interfaces are a realtek 8139
integrated in the motherboard (eth0) and a 3com pci (eth1)
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
beside the fact that I find useful to name eth0 the realtek and eth1
the other, there is a casuality in the naming process that I cannot
remove :-(
my /etc/udev/rules.d/000local.rules looks like this:
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
SYSFS{address}==00:10:4b:b2:1e:6e, NAME=eth1, RUN+=/bin/echo 2
/root/udev.log
KERNEL==eth*, ID==:02:05.0, NAME=eth1, RUN+=/bin/echo 3
/root/udev.log
DRIVER==3c59x, NAME=eth1, RUN+=/bin/echo 4 /root/udev.log
SUBSYSTEM==net, SYSFS{address}==00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 5 /root/udev.log
KERNEL==eth*, SYSFS{address}!=00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 6 /root/udev.log
SYSFS{device}==0x9055, NAME=eth1, RUN+=/bin/echo 7 /root/udev.log
in the hope that the creation of the ethernet interface could match at
least one of these rules (and log wich), but this isn't happening.
I tried to add this at the top of the file:
ACTION==add, DEVPATH==/devices/*, ENV{PHYSDEVBUS}==?*, \
WAIT_FOR_SYSFS=bus
but it didn't help.
can anybody tell me what I'm doing wrong?
I hope this helps,
Emilio
p.d: I think this is a debian-user question, setting MFT, but I'm not
subscribed to debian-user, so CC me please.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
can certainly rename interfaces, though I don't know what the OP's
problem is. I'd suggest talking to a udev-related list, or at least
to debian-user, for this isn't really something to do with -devel.
Anyway, this is what I use on one of my machines, and it works like
a charm:
KERNEL=eth*, SYSFS{address}=00:10:dc:c8:85:07, NAME=lan
I suggest not using NAME=ethX because there may be name clashes.
Use a completely different name instead.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
if you are going to run a rinky-dink distro made by a couple of
volunteers, why not run a rinky-dink distro made by a lot of
volunteers?
-- jaldhar h. vyas
signature.asc
Description: Digital signature (GPG/PGP)
Re: udev naming problems for eth*
On Jan 18, Davide Natalini [EMAIL PROTECTED] wrote:
the system is debian sarge based, with udev version 0.076-6 and kernel
Just to be sure, I suggest you upgrade your version of udev.
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
IOW, renaming is not happening.
my /etc/udev/rules.d/000local.rules looks like this:
Renaming must happen after the WAIT_FOR_SYSFS, which is in
permissions.rules.
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
This RUN action will never work because /root is not writeable when the
rule is processed. You should use something like:
RUN+=/bin/touch /dev/flag-eth0-1
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: udev naming problems for eth*
On Jan 18, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: As far as I can tell, network interface names are given by the kernel and they've nothing to do with udev. Obviously you have no clue about udev (nor about proper quoting). -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
beside the fact that I find useful to name eth0 the realtek and eth1 the other, there is a casuality in the naming process that I cannot remove If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? What I mean by 'races' are sequences like these: * Kernel creates eth0 * Userspace notices eth0, looks at its properties, and... * Kernel creates eth1 * ...tries to rename it to 'eth1', but that name is taken -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 18, Thomas Hood [EMAIL PROTECTED] wrote: If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? No. SuSE uses some scripts to handle persistent interface names, we need something similar but I had no time yet to investigate the details. (Any help would be appreciated.) http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/sysconfig-0.50.0-3.src.rpm -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
Md wrote: SuSE uses some scripts to handle persistent interface names [...] I had no time yet to investigate the details. I just looked at the rename_netiface script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name Now trying several times, etc., may work, but it's a kludge. There are sound ways of resolving contention for a shared resource. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Hello!
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
As it has been pointed by Tomas Hood, udev is the same hack that
ifrename of a custom nameif script and it is not race free. Indeed,
some of the DEV_NET events are special-cased in half of udev due to
not having a device file associated.
A netif name is given in the kernel, udev only tries to rename it (as
the other tools do):
udev_add.c:287
} else if (udev-type == DEV_NET) {
/* look if we want to change the name of the netif */
if (strcmp(udev-name, udev-kernel_name) != 0) {
retval = rename_net_if(udev);
if (retval != 0)
goto exit;
info(renamed netif to '%s', udev-name);
/* we've changed the name, now fake the devpath, cause
the
* original kernel name sleeps with the fishes and we
don't
* get an event from the kernel with the new name
*/
pos = strrchr(udev-devpath, '/');
if (pos != NULL) {
pos[1] = '\0';
strlcat(udev-devpath, udev-name,
sizeof(udev-devpath));
strlcpy(udev-kernel_name, udev-name,
sizeof(udev-kernel_name));
setenv(DEVPATH, udev-devpath, 1);
setenv(INTERFACE, udev-name, 1);
}
}
With the current situation, upstream (kernel) support is needed to do
the rename in a successfully way. You could retry the rename, but then
you'd get into liveliness issues (you want eth0-eth1 and eth1-eth0,
etc...).
So I think that using other tools for the job is equally appropriate.
I'll stop now as I really have no clue about udev and this has nothing
to do with the original post.
Regards, sorry for the noise and keep up the good work with Debian,
Emilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Philipp Matthias Hahn wrote:
udevd uses ioctl(SIOCSIFNAME) to rename the devices. If you drivers are
compiled in, the get assigned eth[01] during init, but udev is called
much later. Renaming eth0 to eth1 will fail, because there already is an
eth1 and vis versa. Consider using another name system for your network
interfaces, like lan and man.
(be advised, that renaming will break Debian's VLAN scripts, because they
expect your device names to be eth[0-9]*.[0-9]*)
Emilio JesÃs GallegoArias wrote:
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio JesÃs Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
As it has been pointed by Tomas Hood, udev is the same hack that
ifrename of a custom nameif script and it is not race free. Indeed,
some of the DEV_NET events are special-cased in half of udev due to
not having a device file associated.
...
With the current situation, upstream (kernel) support is needed to do
the rename in a successfully way. You could retry the rename, but then
you'd get into liveliness issues (you want eth0-eth1 and eth1-eth0,
etc...).
Md wrote:
my /etc/udev/rules.d/000local.rules looks like this:
Renaming must happen after the WAIT_FOR_SYSFS, which is in
permissions.rules.
...
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
This RUN action will never work because /root is not writeable when the
rule is processed. You should use something like:
RUN+=/bin/touch /dev/flag-eth0-1
Marco, this is useful indeed, but the problem remains: in the debian
standard kernel the 8138too and 3c59x drivers are both modules, and both
are present in the initramfs.
If they are loaded and get the kernel name before udev starts I have no
chances in renaming them, because the names are both token.
I can imagine many hacks for solving the situation, but none of them is
clean nor standard.
renaming the interfaces to something like net*, for what I can see,
means that I have to reconfigure some packages by hand, and probably I
will have to do the same during the next upgrade.
surely I can set up a script that removes the two modules, modprobe them
in the right order and restart the networking stuff, but that's not
really clean.
or I could remove the 3c59x module from the initramfs, etc...
maybe modifying mkinitramfs script to include udev in the initramfs
could help?
is there any plan to do so?
I did so with wy firewall, and now it can load the firmware for the usb
modem from within the initramfs, but I don't know if this could solve
this situation.
thanks
davide
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: maybe modifying mkinitramfs script to include udev in the initramfs could help? udev is already part of the initramfs, but its presence is not relevant. The options are: - use names which cannot be used by the kernel, or - help me cleaning up and adapting to Debian the SuSE scripts which provide persistent names for network interfaces I did so with wy firewall, and now it can load the firmware for the usb modem from within the initramfs, but I don't know if this could solve this situation. This reminds me that there should be a list of modules which MUST NOT be added to the initramfs because loading them too early is both useless and as in this case actively harmful. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
Op do, 19-01-2006 te 00:11 +0100, schreef Davide Natalini: Marco, this is useful indeed, but the problem remains: in the debian standard kernel the 8138too and 3c59x drivers are both modules, and both are present in the initramfs. If they are loaded and get the kernel name before udev starts I have no chances in renaming them, because the names are both token. I can imagine many hacks for solving the situation, but none of them is clean nor standard. renaming the interfaces to something like net*, for what I can see, means that I have to reconfigure some packages by hand, and probably I will have to do the same during the next upgrade. surely I can set up a script that removes the two modules, modprobe them in the right order and restart the networking stuff, but that's not really clean. or I could remove the 3c59x module from the initramfs, etc... maybe modifying mkinitramfs script to include udev in the initramfs could help? IIRC mkinitramfs already includes udev and copies your udev configuration into the into to initramfs. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
