Bug 173592 - After upgrade to udev-075-2 "eth1" has been renamed as "dev18685"
Summary: After upgrade to udev-075-2 "eth1" has been renamed as "dev18685"
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-18 14:43 UTC by Dennis Jacobfeuerborn
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-23 11:14:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dennis Jacobfeuerborn 2005-11-18 14:43:15 UTC
After updating udev to version 075-2 and rebooting my device "eth1" now shows up
as "dev18685" when running "ifconfig -a".

Here is what systool has to say about the device:

  Class Device = "dev18685"
  Class Device path = "/sys/class/net/dev18685"
    addr_len            = "6"
    address             = "00:04:61:4a:12:1f"
    broadcast           = "ff:ff:ff:ff:ff:ff"
    features            = "0x0"
    flags               = "0x1002"
    ifindex             = "2"
    iflink              = "2"
    mtu                 = "1500"
    tx_queue_len        = "1000"
    type                = "1"
    uevent              = <store method only>
    weight              = "0"

    Device = "0000:00:04.0"
    Device path = "/sys/devices/pci0000:00/0000:00:04.0"
      class               = "0x020000"
      config              =  de 10 66 00 07 00 b0 00  a1 00 00 02 00 00 00 00
                             00 00 00 ec 01 ec 00 00  00 00 00 00 00 00 00 00
                             00 00 00 00 00 00 00 00  00 00 00 00 95 16 00 10
                             00 00 00 00 44 00 00 00  00 00 00 00 0a 01 01 14
      device              = "0x0066"
      irq                 = "10"
      local_cpus          = "1"
      modalias            = "pci:v000010DEd00000066sv00001695sd00001000bc02sc00i00"
      resource            = "0x00000000ec000000 0x00000000ec000fff
0x0000000000000200
0x000000000000ec00 0x000000000000ec07 0x0000000000000101
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000"
      subsystem_device    = "0x1000"
      subsystem_vendor    = "0x1695"
      uevent              = <store method only>
      vendor              = "0x10de"

Comment 1 Tom London 2005-11-18 20:04:51 UTC
Similar situation here: eth0 has become eth1, eth1 has become eth0.

['old' eth0 was wired NIC, 'old' eth1 was wireless NIC.]

Comment 2 Harald Hoyer 2005-11-21 12:14:42 UTC
Could you please try the version from ftp://people.redhat.com/harald/udev/075-4/

Comment 3 Tom London 2005-11-21 14:47:12 UTC
udev-075-4 (and today's rawhide,e.g., kernel-2.6.14-1.1696_FC5 fix this for me.

Good old eth0 is back to pointing at my wired NIC.

Also, udev seems to 'complete' during boot much faster (it felt like about 2
seconds vs. the roughly 10 it was previously taking).

Comment 4 Dennis Jacobfeuerborn 2005-11-22 01:02:34 UTC
My eth1 still doesn't show up properly, now it's called "dev3355".

Comment 5 Harald Hoyer 2005-11-22 09:35:17 UTC
Dennis, call s-c-network, name your device eth0 and bind it to the MAC Address.

Comment 6 Dennis Jacobfeuerborn 2005-11-22 13:57:59 UTC
s-c-network lists the device correctly as eth1 and it is bound to the MAC address.

I did an "ifup eth1" after which the "dev3355" was apparently correctly renamed
"eth1". Is this the intended behaviour? I remember "ifconfig -a" actually
listing the devices with the correct names even before you brought them up.

Comment 7 Harald Hoyer 2005-11-22 14:12:53 UTC
In the process of ifup those device are renamed.

Comment 8 Tom London 2005-11-22 17:37:40 UTC
Here's another (possibly) related data point:

the 'starting udev' message during boot now takes the usual 2-3 seconds.

However, the 'initializing hardware' line takes about 35 seconds. Also, it used
to print 'progress' about ever 5 seconds or so (e.g., 'storage', 'audio', ...).
It now appears to hang for about 30 seconds, and then prints out all three at
once (followed by '[OK]').

Comment 9 Harald Hoyer 2005-11-23 07:51:09 UTC
This is, because "Starting udev" triggers a lot of work for udevd, which runs in
the background while "initializing hardware".

Comment 10 Tom London 2005-11-23 14:21:23 UTC
Uhhh... sorry to do this, but this morning I got eth0/eth1 flipped again.

I'm running udev-075-4.

Reopen?

What more info can I provide to help?

Comment 11 Harald Hoyer 2005-11-23 16:15:33 UTC
to prevent flipping bind the interface name to the MAC address.

Comment 12 Tom London 2005-11-25 17:00:53 UTC
Hmmm... the 'devnnnnn' thing seems back:
dev23214  Link encap:Ethernet  HWaddr 00:0E:35:36:F2:34
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3781 errors:0 dropped:0 overruns:0 frame:0
          TX packets:486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x8000 Memory:fceff000-fcefffff

eth0      Link encap:Ethernet  HWaddr 00:0E:7B:4A:79:0B
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:432 errors:0 dropped:0 overruns:0 frame:0
          TX packets:500 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:85995 (83.9 KiB)  TX bytes:49926 (48.7 KiB)
          Base address:0xcf40 Memory:fcec0000-fcee0000

I know this is marked closed (and I don't want to be a drag), but ....

Is this 'fixed' in 075-5?  Something wrong in my config?

tom

Comment 13 Dennis Jacobfeuerborn 2005-11-25 17:14:13 UTC
If I understand Haralds reply in comment #7 correctly then the devices do not
get properly renamed until they get ifup'ed and when that happens the proper
name gets determined by using the HWADDR field in the ifcfg-* files.

In ifcfg-eth0 you should have the following two lines (among others):
DEVICE=eth0
HWADDR=00:0E:7B:4A:79:0B

and ifcfg-eth1 should probably look like this:
DEVICE=eth1
HWADDR=00:0E:35:36:F2:34

If you then do an ifup for both devices they should come up with the correct
names and in the proper order.


Comment 14 Tom London 2005-11-25 17:22:52 UTC
Dennis, thanks.

I did not understand Harald's hint ;)

I've added the appropriate 'HWADDR=' line to ifcfg-eth1 and will give it a shot.

I did try to 'bond' the devices using s-c-network, but obviously erred.


Note You need to log in before you can comment on or make changes to this bug.