[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <madduck@debian.org> writes:

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

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



Reply to: