Bug 507084 - netinst.iso fails on second interface
netinst.iso fails on second interface
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-20 13:40 EDT by John Reiser
Modified: 2010-02-23 14:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-23 14:04:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/tmp/syslog DHCP succeeds on first try (57.44 KB, text/plain)
2009-08-12 22:17 EDT, John Reiser
no flags Details
/tmp/syslog DHCP fails eth0, then fails eth1 (53.91 KB, text/plain)
2009-08-12 22:23 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2009-06-20 13:40:13 EDT
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.
Comment 1 Radek Vykydal 2009-07-20 08:14:43 EDT
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.
Comment 2 Jeroen van Meeuwen 2009-07-21 07:48:01 EDT
Cherry picked cee4eef6a4ab0503d8dd3c650d7a2b819432d781 into (unofficial) f11-branch and will be in an upcoming Fedora Unity Re-Spin
Comment 3 John Reiser 2009-08-12 22:14:00 EDT
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.
Comment 4 John Reiser 2009-08-12 22:17:26 EDT
Created attachment 357262 [details]
/tmp/syslog DHCP succeeds on first try

Here the first try is interface 'eth1' which has the cable plugged in.
Comment 5 John Reiser 2009-08-12 22:23:23 EDT
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.
Comment 6 Radek Vykydal 2009-08-26 08:44:41 EDT
Thank you for retesting and detailed report, new patch with fix should go to version 12.17 of anaconda.

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