Re: Buggy UDEV?

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

 



On 10/13/09, dragondaddy@xxxxxxxxxxxx <dragondaddy@xxxxxxxxxxxx> wrote:
> starts.  The rules for udev worked fine form a couple of months
> until I put in a new hard drive to use as an NFS drive.  And then
> it went to crap. Needless to say the random renaming of the
> interfaces screws up my bridging script and is unacceptable
> behavior.
>
> Udev began renaming the interfaces!! What's the point of having
> rules file if they are not rules?  Here is the current rules file:
>
>
>
> # PCI device 0x10ec:0x8139 (8139too)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:13:8f:ad:bf:06", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth0"
>
> # PCI device 0x1106:0x3106 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:40:f4:9c:ec:dd", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x1106:0x3106 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:e0:4c:6a:4e:f2", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth2"
>
>
>
> Here is dmesg | grep eth from the last boot:
>
> eth0: VIA Rhine III at 0xff0ff400, 00:40:f4:9c:ec:dd, IRQ 21.
> eth0: MII PHY found at address 1, status 0x786d advertising 05e1
> Link 4de1.
> eth1: RealTek RTL8139 at 0xc800, 00:13:8f:ad:bf:06, IRQ 22
> eth2: RTL8169sb/8110sb at 0xf8910800, 00:e0:4c:6a:4e:f2, XID
> 10000000 IRQ 23
> udev: renamed network interface eth0 to eth1
> udev: renamed network interface eth1_rename to eth0
> eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
> eth1: link up, 100Mbps, full-duplex, lpa 0x4DE1
> r8169: eth2: link up
> eth0: no IPv6 routers present
> eth1: no IPv6 routers present
> eth2: no IPv6 routers present
> device eth1 entered promiscuous mode
> device eth2 entered promiscuous mode
> brdg1: port 2(eth2) entering learning state
> brdg1: port 1(eth1) entering learning state
>
> It's clear that the rule says that eth0 should be associated with
> MAC address "00:13:8f:ad:bf:06" udev ignored this rule and
> associated eth0 with "00:40:f4:9c:ec:dd".  And then it decide to
> just ignore the rest of the rules and swap around the interfaces at
> random.

Um, no?  I think your problem is happening later on.  What you've
shown so far makes perfect sense

> eth0: VIA Rhine III at 0xff0ff400, 00:40:f4:9c:ec:dd, IRQ 21.
> eth0: MII PHY found at address 1, status 0x786d advertising 05e1
> Link 4de1.
> eth1: RealTek RTL8139 at 0xc800, 00:13:8f:ad:bf:06, IRQ 22
> eth2: RTL8169sb/8110sb at 0xf8910800, 00:e0:4c:6a:4e:f2, XID
> 10000000 IRQ 23

These are the devices as created by the kernel.  Obviously udev has no
influence over these names; it is not part of the kernel.  All udev
can do is rename the devices once they are created...

> udev: renamed network interface eth0 to eth1
> udev: renamed network interface eth1_rename to eth0

like so.  The 8139 device started off as eth1, so udev renamed it to
eth0 in accordance with your rules.  And the same with eth1 -> eth0.

Regards
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux