Bug 299351

Summary: network interfaces mixed up
Product: [Fedora] Fedora Reporter: Dave Jones <davej>
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: ak, cra, dwmw2, katzj, mishu, pfrields
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-22 14:31:06 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 235703    
Attachments:
Description Flags
screenshot showing interface confusion.
none
anaconda log
none
syslog during install none

Description Dave Jones 2007-09-20 18:04:35 EDT
my laptop has a realtek ethernet, and broadcom wireless.
Anaconda displays a screen asking which to install through that looks like..

eth0: Broadcom corporation BCM4318 yadayada
eth1: Realtek Semiconductor RTL8139 yadayada

This ordering seemed odd to me, so I checked dmesg.
It displays..

eth0: RealTek RTL8139 at 0xffffc20000f0a400, 00:0f:b0:bb:0f:7a, IRQ 22
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'

Anaconda is really confused. To install through ethernet, I have to select the
broadcom wireless entry.  Selecting the Realtek entry gets me..

17:21:20 DEBUG   : dhcp: ioctl SIOCGIFFLAGS failed: 19 No such device

(understandable given it doesn't have firmware for the device)

logs attached..
Comment 1 Dave Jones 2007-09-20 18:05:26 EDT
Created attachment 201351 [details]
screenshot showing interface confusion.
Comment 2 Dave Jones 2007-09-20 18:05:42 EDT
Created attachment 201361 [details]
anaconda log
Comment 3 Dave Jones 2007-09-20 18:05:57 EDT
Created attachment 201371 [details]
syslog during install
Comment 4 Joel Andres Granados 2007-09-21 08:35:47 EDT
*** Bug 300101 has been marked as a duplicate of this bug. ***
Comment 5 David Woodhouse 2007-09-21 08:40:50 EDT
Kind of a digression, but arguably we ought to be excluding the bcm43xx anyway
-- we don't ship firmware for it, and (AFAIK) we don't have any kind of 'driver
disk' method for providing it.
Comment 6 Dave Jones 2007-09-21 16:37:57 EDT
Yeah, I wonder where it's getting the 'eth' name from at all, because it doesn't
exist until you load firmware for it iirc.
Comment 7 David Cantrell 2007-09-22 13:58:55 EDT
It comes from kudzu when we use it to return a list of probed ethernet devices.
 When a module is loaded without the firmware, kudzu gives it the device name
'eth', which messes up our sorting in anaconda since we expect eth to be
followed by an int.
Comment 8 Jeremy Katz 2007-09-24 13:43:16 EDT
We should be ignoring the devices named 'eth', though.  But I'm not seeing
devices with missing firmware coming up as just 'eth' now.  Which is easy to
test, as firmware loading doesn't seem to be working on iwl3945 either...
Comment 9 Charles R. Anderson 2007-09-25 09:18:41 EDT
I saw this same problem with the IBM A/B/G card in my Thinkpad.  This is an
Atheros device, so AFAIK, there isn't any driver at all for it (did MadWifi get
into the distro?), but it still showed up in the Anaconda device list, messing
up the order.
Comment 10 Jeremy Katz 2007-09-28 16:59:09 EDT
Hack of a fix in place although a couple of drivers (ath5k, b43legacy) were left
off the list in the current build.  Next anaconda build will add those
Comment 11 Alex Kanavin 2007-10-04 16:38:35 EDT
The problem persists with F8 test3. I'm too having a Broadcom BCM4306 wireless chip in my PPC 
Powerbook. I can provide more info if needed.
Comment 12 Jeremy Katz 2007-10-05 10:07:32 EDT
Yeah, the PPC bcm bits is being tracked as bug 311421 (it's a little bit more
subtle to fix)
Comment 13 Will Woods 2007-10-18 17:04:43 EDT
Works for me on a ppc powerbook and current rawhide. Dave, does this work for you?
Comment 14 Dave Jones 2007-10-22 14:31:06 EDT
works for me too.