|Summary:||Network device detection inconsistant between install and boot|
|Product:||[Fedora] Fedora||Reporter:||Bruno Wolff III <bruno>|
|Component:||kudzu||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED DUPLICATE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-04-16 19:46:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Bruno Wolff III 2007-04-14 15:11:55 UTC
Description of problem: I have a TDM400 telephony card which is not detected as a network device when installing rawhide, but which is when booting after install. Version-Release number of selected component (if applicable): This happened on a snapshot of rawhide from April 13. How reproducible: 100% with my hardware Steps to Reproduce: 1. Have a system with a TDM400 and other network devices 2. 3. Actual results: The TDM400 card is not detected as a network device during the install process, but is during the boot process. Expected results: Probably it shouldn't be detected as a network device at all. Additional info: The main annoyance is that if I set up configuration of the real network devices during the install, the setup is broken because at boot the TDM400 gets associated as eth0 and the other network devices are renamed which invalidates the previously set up configs. lspci -v output for the problem device: 00:08.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface Subsystem: Unknown device b1d9:0001 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d000 [size=256] Memory at f7001000 (32-bit, non-prefetchable) [size=4K] Capabilities:  Power Management version 2
Comment 1 Bill Nottingham 2007-04-16 18:39:32 UTC
'Network controller' is the class used - unfortunately, you can't really do anything else, b/c that's what's used for wireless cards.
Comment 2 Bruno Wolff III 2007-04-16 18:59:46 UTC
I can live with that, but then the install process should also see things the same way, so that the setup during the install still works post install. Maybe this is an anaconda issue instead of a kudzu issue?
Comment 3 Bill Nottingham 2007-04-16 19:27:10 UTC
The installer doesn't see it that way because the ISDN driver (hisax, or whatever) isn't included in the installer.
Comment 4 Bruno Wolff III 2007-04-16 19:46:41 UTC
Can mac addresses be used in the ifcfg files to keep the association between the physical devices and the logical devices consistant? If not, I'll just live with it as it only needs to be dealt with once per install.
Comment 5 Bill Nottingham 2007-04-16 19:50:19 UTC
They can *if the device has them*. Not sure that ISDN devices do?
Comment 6 Bruno Wolff III 2007-04-16 20:10:18 UTC
The two normal ethernet devices (one on motherboard, the other a pci card) do have them and those are the ones that get mucked up. Since the tdm400 isn't even detected, it doesn't have a config from the install process to get messed up. The real annoyance was setting up the IP addresses and related information for the two network cards during the install and then having the devices renamed (eth0 became eth1 and eth1 became eth2) once I booted the system, but the config files kept the name from the install so that they weren't correct. P.S. The tdm400 isn't really an isdn card. It probably uses the same modem chip that someone else uses for one. It is an analog telephony card supported by the zaptel drivers and is used with asterisk (or callweaver - the new name for openpbx).
Comment 7 Bill Nottingham 2007-04-16 20:14:31 UTC
Note that there is a bug in anaconda currently where it won't write out HWADDR for devices that do have them - if that's hitting you, things will go odd on reboot.
Comment 8 Bruno Wolff III 2007-04-16 20:28:16 UTC
That sounds like it. So I think it is safe to mark this one as a duplicate of 234764. (I don't know the right way to do it, but will add myself as a cc to that bug in case you just want to close this one.) Since detecting the TDM400 card as a network device was new, I thought that was the soruce of the issue, rather than a regression. Thanks.