|
Home > Archive > Debian Developers > January 2006 > udev naming problems for eth*
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
udev naming problems for eth*
|
|
| Davide Natalini 2006-01-18, 7:51 am |
| Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
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=="0000: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?
thanks
davide
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Emilio Jesús Gallego Arias 2006-01-18, 5:56 pm |
| Davide Natalini <tindal@katamail.com> 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
> KERNEL=="eth*", ID=="0000:02:05.0", NAME="eth1", RUN+="/bin/echo 3
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-01-18, 5:56 pm |
| also sprach Emilio Jesús Gallego Arias <egallego@babel.ls.fi.upm.es> [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 <madduck@debian.org>
: :' : 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
| |
| Marco d'Itri 2006-01-18, 5:56 pm |
| On Jan 18, Emilio Jesús Gallego Arias <egallego@babel.ls.fi.upm.es> 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
| |
| Marco d'Itri 2006-01-18, 5:56 pm |
| On Jan 18, Davide Natalini <tindal@katamail.com> 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/echo1
> /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
| |
| Thomas Hood 2006-01-18, 5:56 pm |
| > 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2006-01-18, 5:56 pm |
| On Jan 18, Thomas Hood <jdthood@yahoo.co.uk> 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/opensus....50.0-3.src.rpm
--
ciao,
Marco
| |
| Thomas Hood 2006-01-18, 5:56 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Emilio Jesús Gallego Arias 2006-01-18, 5:56 pm |
| Hello!
martin f krafft <madduck@debian.org> writes:
> also sprach Emilio Jesús Gallego Arias <egallego@babel.ls.fi.upm.es> [2006.01.18.1254 +0100]:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Davide Natalini 2006-01-19, 8:12 am |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2006-01-19, 8:12 am |
| On Jan 19, Davide Natalini <tindal@katamail.com> 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
| |
| Emilio Jesús Gallego Arias 2006-01-19, 8:12 am |
| md@Linux.IT (Marco d'Itri) writes:
> On Jan 19, Davide Natalini <tindal@katamail.com> wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2006-01-19, 8:12 am |
| On Jan 19, Emilio Jesús Gallego Arias <egallego@babel.ls.fi.upm.es> 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
| |
| Emilio Jesús Gallego Arias 2006-01-19, 8:12 am |
| md@Linux.IT (Marco d'Itri) writes:
> On Jan 19, Emilio Jesús Gallego Arias <egallego@babel.ls.fi.upm.es> wrote:
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2006-01-19, 8:12 am |
| 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 <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2006-01-19, 8:12 am |
| On Jan 19, Hamish Moffatt <hamish@debian.org> wrote:
> 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
| |
| Davide Natalini 2006-01-19, 8:12 am |
| Md wrote:
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2006-01-19, 8:12 am |
| On Jan 19, Davide Natalini <tindal@katamail.com> 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
|
|
|
|
|