Description of problem: netinst.iso fails to bring up the network if the first interface is not connected but the second one is. The error messages provide no clues about what is wrong, how to fix it, or what to try next. Having no network means that netinst must give up; the whole install fails. Version-Release number of selected component (if applicable): anaconda-11.5.0.59 How reproducible: always Steps to Reproduce: 1. boot netinst.iso on a box with 2 NIC but network cable attached only to the second NIC 2. try to configure eth0 using DHCP IPv4 (should fail because no connection [no cable]) 3. try to configure eth1 using DHCP IPv4 (should succeed) Actual results: Both eth0 and eth1 give error dialog "Error configuring netowrk: An error occurred trying to bring up the eth[01] network interface" but there are no details. VT4 shows 4 repetitions of: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0.new ifcfg-rh: Error: Couldn't parse file '/etc/sysconfig/network-scripts/ifcfg-eth0.new' and similarly for eth1. But those *.new files are not available anymore. Expected results: Success in bringing up network on NIC that does have cable (with DHCP available), even after failure on other NIC. Additional info: The interface choices are just "eth[01] - Networking interface" with no other info. Instead, the hwaddr (MAC address) and model name (such as "82574L Gigabit Network Connection") should be listed. This info was listed in previous versions (such as Fedora 10) and the model names can be discovered by using 'lspci' on VT2 (so the table of names still does occupy space on the .iso), but it is hard to determine which is eth0 and which is eth1. Previous versions of Fedora detected no carrier and warned "Cable missing?" This would help the diagnosis. Guessing correctly which interface (eth0 or eth1) has the cable, and trying to configure that interface first (DHCP IPv4), succeeds. So there is a specific bug in carrying over bad results from previous failed attempts on other interfaces. Exploring with shell on VT2 reveals these ifcfg-eth[01] files after failure: -----/etc/sysconfig/network-scripts/ifcfg-eth0 # Networking Interface DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:1F:C6:B0:23:48 ONBOOT=yes TYPE=Ethernet PEERDNS=yes PEERROUTES=yes NAME="System eth0" UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ----- -----/etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=00:1B:21:30:E9:E5 ONBOOT=no TYPE=Ethernet BOOTPROTO=dhcp PEERDNS=yes PEERROUTES=yes NAME="System eth1" UUID=9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 ----- Notice that the order of the lines is different: eth0: (BOOTPROTO, HWADDR, ONBOOT, TYPE) eth1: (HWADDR, ONBOOT, TYPE, BOOTPROTO) This does not matter as assignments to shell environment variables, but might suggest bad logic in the writer.
This should be fixed in version 12.3 of anaconda. As for device identification, MAC address has been added to label in bug #504216. HAL doesn't give us other useful info via dbus interface we are now using (in vendor and product properties). Thanks for the report.
Cherry picked cee4eef6a4ab0503d8dd3c650d7a2b819432d781 into (unofficial) f11-branch and will be in an upcoming Fedora Unity Re-Spin
It still fails in today's i386 boot.iso (netinst.iso) on physical CD-RW with anaconda-12.13. I boot for install on bare hardware, and append " vga=0x31a repo=http://mirrors.cat.pdx.edu/fedora/linux/development/i386/os". I accept the splash screen, language, keyboard, and beta nag. I choose Update, specify an existing i686 rawhide partition, skip boot loader update, and arrive at the DHCP configuration dialog for network. If I choose eth1 that has the cable plugged in, then it works: finds the repo, accesses it, completes the update [which does nothing, as expected.] If I reboot the same way to the DHCP dialog, but choose eth0 first (cable is unplugged) then it fails as expected; but continuing with eth1 (still has the cable) *also* fails when it should succeed. The message is "Error Configuring Network; An error occurred trying to bring up the network interface [OK]". I will attach /tmp/syslog from both cases.
Created attachment 357262 [details] /tmp/syslog DHCP succeeds on first try Here the first try is interface 'eth1' which has the cable plugged in.
Created attachment 357263 [details] /tmp/syslog DHCP fails eth0, then fails eth1 The failure on eth0 is expected because it has no cable. However, the subsequent attempt on eth1 also fails even though it should succeed (has cable plugged in, and does work when attempted first after boot.) Something about a failure on the first interface has carried over improperly to a failure on the second interface.
Thank you for retesting and detailed report, new patch with fix should go to version 12.17 of anaconda.