Bug 436456 - Kernel 2.6.24.3-12 network adapter names changed
Kernel 2.6.24.3-12 network adapter names changed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: system-config-network (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
: 436957 437016 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-07 06:22 EST by David
Modified: 2008-04-23 11:49 EDT (History)
6 users (show)

See Also:
Fixed In Version: 1.5.5-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-22 18:39:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This is off the new 2.6.24.3-12 kernel (22.16 KB, text/plain)
2008-03-10 17:40 EDT, David
no flags Details
network config - eth0 - edit - hardware tab (note it carefully) (855.90 KB, image/png)
2008-03-11 03:38 EDT, David
no flags Details
network config - eth1 - edit - hardware tab (see this is correct) (868.54 KB, image/png)
2008-03-11 03:39 EDT, David
no flags Details
network config - eth2 - edit - hardware tab (note it carefully) (863.31 KB, image/png)
2008-03-11 03:40 EDT, David
no flags Details
This is the plain hardware tab out of networking, again note the reversed eth0 and eth2! (979.08 KB, image/png)
2008-03-11 03:41 EDT, David
no flags Details
outputs 2.6.23.15-137.fc8 (9.93 KB, application/zip)
2008-03-11 16:06 EDT, Daniel Laczi
no flags Details
outputs 2.6.24.3-12.fc8 (10.42 KB, application/zip)
2008-03-11 16:07 EDT, Daniel Laczi
no flags Details
outputs 2.6.24.3-12.fc8 with only one network adapter (10.29 KB, application/zip)
2008-03-11 16:08 EDT, Daniel Laczi
no flags Details
ifconfig -a dump for 3 kernels (4.31 KB, text/plain)
2008-03-13 01:29 EDT, Alexander Tetervak
no flags Details
double device entry after reboot in "Network Configuration" (43.79 KB, image/png)
2008-03-13 12:38 EDT, Alexander Tetervak
no flags Details

  None (edit)
Description David 2008-03-07 06:22:55 EST
Description of problem:
With this kernel now my eth:0 is detected as eth:2 and it break my firestarter
forwarding.  For some stupid reason this kernel insists my adapter that has been
eth:0 since FC6 is now eth2: and the old eth:2 is now eth:0

Despite resetting the IP addresses and setting firestarter to use internet as
eth:2 (not eth:0) and LAN is eth:1 (it remains the same) no clients on our
network can access the WAN let alone the router to the LAN.

THis kernel needs to handle etherenet adapters the same not just decide it want
to renumber them!

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 David 2008-03-07 06:56:10 EST
Okay I have found the kernel is mis labeling the adapters.

This server has 3 ethernet adapters.  One on board SIS, the other 2 are external
cards.

For some reason it insists eth0 is now the SIS controller this IS NOT correct.
The on board SIS is indeed eth2

Eth0 is really a 100MB realtek card and Eth1 is a 1GB realtek

I found if I tell firestarter to use SIS adapter (eth0) it works but the
ethernet cable is in the realtek 100MB card.

I had to redo my network with eth0 saying its the SIS controller but its really
the realtek..

This is going to be messy as when its fixed in the next kernel this will again
break the network.

So what is happening is eth0 is still eth0 (physically), but for some reason
this kernel says its the SIS (eth2).

So in networking I have got eth0 saying its the SIS onboard, but set to the IP
address I use for the real realtek and the cable is in the realtek.

Comment 2 Michael Lavallee 2008-03-07 10:49:14 EST
I also experienced this problem after upgrading my kernel this morning.  I
removed and recreated my network device and I am back up and running.  I am
running the 64-bit kernel, and am using an nVidia Corporation MCP51 Ethernet
Controller (rev a3).
Comment 3 Dave Jones 2008-03-07 12:49:59 EST
do you have HWADDR entries in all the
/etc/sysconfig/networking/devices/ifcfg-eth* files ?
Comment 4 Chuck Ebbert 2008-03-07 16:20:05 EST
(In reply to comment #2)
> I also experienced this problem after upgrading my kernel this morning.  I
> removed and recreated my network device and I am back up and running.  I am
> running the 64-bit kernel, and am using an nVidia Corporation MCP51 Ethernet
> Controller (rev a3).

Do you have multiple ethernet controllers too?
Comment 5 David 2008-03-07 17:48:11 EST
Dave yes I do have HWADDR in the 3 files in /etc/sysconfig/networking/devices/

Also its as I stated eth0 is truly the realtek card not the onboard SIS as
networking with this kernel insists...

But what I notice is number 0 and 2 don't have the name like 1 does...

0
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=10.0.0.10
TYPE=Ethernet
DEVICE=eth0
HWADDR=xxxxxxxxx
BOOTPROTO=none
NETMASK=255.0.0.0
IPADDR=10.0.0.1
ONBOOT=yes
USERCTL=no
PEERDNS=yes
IPV6INIT=yes
NM_CONTROLLED=no



1
# Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
DEVICE=eth1
BOOTPROTO=none
BROADCAST=192.168.0.255
HWADDR=xxxxxxxx
IPADDR=192.168.0.1
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=no
PEERDNS=yes

2
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Ethernet
DEVICE=eth2
HWADDR=xxxxxxxxx
BOOTPROTO=none
NETMASK=255.255.0.0
IPADDR=172.16.0.1
ONBOOT=no
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
Comment 6 Dave Jones 2008-03-07 17:59:31 EST
ISTR Bill diagnosed a similar problem (if not the same) as this a few months
back. Bill, any ideas ?
Comment 7 David 2008-03-07 23:42:05 EST
I actually now have another server with two nics in it and its also got this
problem.  I have to reset the network card details and reset firestarter.  I
tried this over the phone (its a remote server) but cant get firestarter up yet.
 I will visit later.  But this proves yet another working machine until this
kernel and networking breaks to bits, this machine only has two nics.
Comment 8 Daniel Laczi 2008-03-09 13:54:52 EDT
I have two network cards on board.
I was not able to get even one of them to work.
I don't need two network cards, so I disabled one of them in BIOS and now the
other works fine.
Comment 9 Chuck Ebbert 2008-03-10 16:09:22 EDT
Everyone who has reported this bug: please reply with the exact module names
used by each of your network adapters, (for example 8139too, sis900, etc.)
Comment 10 Chuck Ebbert 2008-03-10 16:15:48 EDT
Also please post the full set of boot messages (from /var/log/dmesg) from the
old and new kernels.
Comment 11 David 2008-03-10 17:40:31 EDT
Created attachment 297516 [details]
This is off the new 2.6.24.3-12 kernel
Comment 12 David 2008-03-10 18:00:00 EDT
My cards are:

PCI card (true Eth1) # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
PCI card (true Eth0) # Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
Onboard (true Eth2) # Silicon Integrated Systems (SIS) SiS900 PCI Fast Ethernet

For my situation I still cant understand why the kernel now insists the SiS
onboard is now Eth0, when it has always been the LAST PCI card.  Its like now
this kernel decides to put onboard PCI at a higher priority.

This is a bad practice as regardless if anyone thinks onboard should go first
not last, it has always been last since I started back on FC6 with every kernel
and to suddenly change this breaks stuff big time.

The problem for me, this is a gateway server serving WAN and bridging our web /
ftp / dns and mailservers to the WAN.  If you really need my /var/log/dmesg from
the previous kernel I will have to schedule a time as it will put Eth0 back the
the proper Realtek 8139 and break the network.
Comment 13 Chuck Ebbert 2008-03-10 18:41:47 EDT
What is in /etc/udev/rules.d/70-persistent-net.rules and does it match up with
the original ifcfg-ethX files?
Comment 14 David 2008-03-10 19:02:30 EDT
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0c:6e:2b:c8:57", ATTR{type}=="1", NAME="eth2"
# Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:40:f4:a9:d5:4d", ATTR{type}=="1", NAME="eth1"
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:05:1c:1c:22:5f", ATTR{type}=="1", NAME="eth0"



Yes this is correct - see that Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ is eth0.... and the Sis is eth2.

Is the order meant to be backwards from eth2, eth1 and eth0 or this is not relevant?
Comment 15 Bill Nottingham 2008-03-11 00:03:06 EDT
From reading the dmesg output you posted, it *looks* like it correctly renamed
the 8139too device to eth0 on boot. 

See:
eth2: RealTek RTL8139 at 0xf89de000, 00:05:1c:1c:22:5f, IRQ 21
eth2:  Identified 8139 chip type 'RTL-8100B/8139D'
udev: renamed network interface eth2 to eth0
udev: renamed network interface eth0_rename to eth2

Is this not taking effect?
Comment 16 David 2008-03-11 03:38:52 EDT
Created attachment 297572 [details]
network config - eth0 - edit - hardware tab (note it carefully)

network config - eth0 - edit - hardware tab (note it carefully)
Comment 17 David 2008-03-11 03:39:41 EDT
Created attachment 297573 [details]
network config - eth1 - edit - hardware tab (see this is correct)
Comment 18 David 2008-03-11 03:40:20 EDT
Created attachment 297574 [details]
network config - eth2 - edit - hardware tab (note it carefully)
Comment 19 David 2008-03-11 03:41:51 EDT
Created attachment 297575 [details]
This is the plain hardware tab out of networking, again note the reversed eth0 and eth2!
Comment 20 Bill Nottingham 2008-03-11 11:24:37 EDT
What's the output of 'ifconfig -a'?
Comment 21 Daniel Laczi 2008-03-11 16:06:51 EDT
Created attachment 297667 [details]
outputs 2.6.23.15-137.fc8

I hope there is something useful within.
Comment 22 Daniel Laczi 2008-03-11 16:07:32 EDT
Created attachment 297668 [details]
outputs 2.6.24.3-12.fc8
Comment 23 Daniel Laczi 2008-03-11 16:08:14 EDT
Created attachment 297669 [details]
outputs 2.6.24.3-12.fc8 with only one network adapter
Comment 24 Bill Nottingham 2008-03-11 16:18:37 EDT
'Alias' - I see nothing wrong with your config or setup in either case.
Comment 25 Daniel Laczi 2008-03-11 17:33:26 EDT
Yes your right.
This is a bit confusing and was a waste of time, because I didn't reconfigure
the configs with kernel 2.6.23.15-137.fc8

This was my fault. Sorry.
Comment 26 David 2008-03-11 18:51:24 EDT
Bill,

Here is dump of ifconfig -a as requested:

eth0      Link encap:Ethernet  HWaddr 00:05:1C:1C:22:5F
          inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::205:1cff:fe1c:225f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2328233 errors:1 dropped:1 overruns:1 frame:0
          TX packets:2703484 errors:0 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1143370458 (1.0 GiB)  TX bytes:783084918 (746.8 MiB)
          Interrupt:21 Base address:0xe000

eth1      Link encap:Ethernet  HWaddr 00:40:F4:A9:D5:4D
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::240:f4ff:fea9:d54d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2688392 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2373412 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:779606708 (743.4 MiB)  TX bytes:1172915664 (1.0 GiB)
          Interrupt:23 Base address:0x8000

eth2      Link encap:Ethernet  HWaddr 00:0C:6E:2B:C8:57
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 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:23 Base address:0x8800

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11860 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11860 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3854034 (3.6 MiB)  TX bytes:3854034 (3.6 MiB)



See its weird ifconfig agrees that eth0 is the realtek 8139 WAN card and eth2 is
the onboard SiS (can see by the macs), but why does networking gui show them up
as reversed?
Comment 27 Bill Nottingham 2008-03-11 18:58:58 EDT
OK, so this is merely a system-config-network problem - the system is operating
correctly with the right interface with the right address (at least, as much as
it's configured.)

Reassigning.
Comment 28 Chuck Ebbert 2008-03-12 15:52:43 EDT
*** Bug 437016 has been marked as a duplicate of this bug. ***
Comment 29 Chuck Ebbert 2008-03-12 15:53:11 EDT
*** Bug 436957 has been marked as a duplicate of this bug. ***
Comment 30 Chuck Ebbert 2008-03-12 19:01:29 EDT
(In reply to comment #26)
> Bill,
> 
> Here is dump of ifconfig -a as requested:
> 

I assume that was from 2.6.24?

If so please post what 2.6.23 says. It looks like HAL has the interface right
but the rename was failing in 2.6.23. system-config-network somehow picked up
the reversed names because HAL assumed the name change worked when it didn't.
This should really be a HAL bug, because it didn't check if the rename was working??
Comment 31 Alexander Tetervak 2008-03-13 01:29:22 EDT
Created attachment 297895 [details]
ifconfig -a dump for 3 kernels

I attached "ifconfig -a" dump for three kernels: 2.6.24.3-12.fc8,
2.6.23.15-137.fc8, and 2.6.20-1.2320.fc5 (the same hardware). This bug pops up
when 2.6.24.3-12.fc8 in use.
Comment 32 Bill Nottingham 2008-03-13 11:24:50 EDT
That seems the same for all three kernels, which implies the underlying
infrastructure is working.
Comment 33 Alexander Tetervak 2008-03-13 12:38:30 EDT
Created attachment 297954 [details]
double device entry after reboot in "Network Configuration"

The "Network Configuration" dialog shows me third entry created automatically
on reboot for "third" *Active* device (duplicate of eth1). I have changed
nicknames manualy. Before the nickname change, with the default nicknames, the
third automatic entry was getting "eth1.bak" nickname generated. 
The hardware tab has two entries where the "Descriptions" are switched between,
similar to the above.
Comment 34 Alexander Tetervak 2008-03-14 15:59:56 EDT
Dear RedHat Guys/Ladies:
My computer shows the bug with two on-board cards. I can  make extra experiments
if there is a chance that it could help you to figure out what is wrong. I have
two spare PCI cards, spare PCI slots on the board, and enough cables. I can boot
the computer with 1-2-3-4 cards and provide outputs if it can be useful,
provided you tell me what you want exactly.   
Comment 35 Uno Engborg 2008-03-15 18:11:16 EDT
This bug is especially annoying if you have both wired and wireless connections.
If the interfaces gets switced, the wired network interface will get
configuration options for the wireless card and vice versa.

The drivers used according to lspci is:

02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network
Connection (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet
Controller (rev 81)

The wireless driver works if I set it up with iwconfig. (I haven't had a chance
to test to set up the wired connection with ifconfig yet)

Comment 36 J.Jansen 2008-03-19 07:26:01 EDT
installing kernel 2.6.24.3-34 did not help. I got the same results as I reported
in bug #436957
Comment 37 Burkhard Holl 2008-03-31 16:08:37 EDT
It seems that 437619 describes the same problem.
Comment 38 Alexander Tetervak 2008-04-01 11:25:36 EDT
with the latest kernel update to 2.6.24.3-50.fc8 the problem on my computer had
disappeared, but the same installation booted with previous kernel
2.6.24.3-34.fc8 shows the same described above problem.   
Comment 39 J.Jansen 2008-04-02 03:11:24 EDT
After installing 2.6.24.3-50 also the problems I reported in bug #436957 did not
occur anymore.

              Jouk
Comment 40 Burkhard Holl 2008-04-06 06:26:59 EDT
After installing 2.6.24.4-64 for x86_64 the problem still remains on my
computer. I hope that the problem can be fixed soon.
Comment 41 Fedora Update System 2008-04-07 10:34:33 EDT
system-config-network-1.5.5-1.fc8 has been submitted as an update for Fedora 8
Comment 42 Fedora Update System 2008-04-09 01:19:52 EDT
system-config-network-1.5.5-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update system-config-network'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2995
Comment 43 Fedora Update System 2008-04-22 18:38:38 EDT
system-config-network-1.5.5-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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