Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 598432 - Waiting for activation of devices *not* selected before running nm-c-e.
Summary: Waiting for activation of devices *not* selected before running nm-c-e.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-01 11:57 UTC by Radek Vykydal
Modified: 2010-11-10 19:46 UTC (History)
2 users (show)

Fixed In Version: anaconda-13.21.51-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 19:46:30 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch with fix (deleted)
2010-06-01 11:57 UTC, Radek Vykydal
no flags Details

Description Radek Vykydal 2010-06-01 11:57:11 UTC
Created attachment 418606 [details]
patch with fix

Description of problem:

When doing [Configure Network] in anaconda GUI having more than one network device, user selects in a dialog which devices should be configured by NM (edited in nm-c-e). If he unchecks a device that was already set as ONBOOT=yes (e.g. it was used during install, or [ ] Connect Automatically was checked in previous run of nm-c-e), anaconda waits to activation of the device after nm-c-e is left and fails after timeout. It shouldn't wait.


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

anaconda-13.21.48-1


How reproducible:

Always


Steps to Reproduce:
1. Install on a machine with 2 network devices (say eth0, eth1).
2. Enable eth0 in stage 1 (e.g. have ks or stage2 or updates.img over network)
2. Run [Configure Networking] in GUI.
3. In pre nm-c-e dialog, check eth1 and uncheck eth0.
(This will bring down eth0)
4. Leave nm-c-e, anaconda will wait for activation of eth0 for about 45 s and
then error message appears.
  
Actual results:

Anaconda waits for eth0 activation.

Expected results:

Anaconda doesn't wait for eth0 activation as it is not NM controlled.

Additional info:

Patch attached.

Comment 1 RHEL Product and Program Management 2010-06-01 12:16:02 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Radek Vykydal 2010-06-14 15:41:07 UTC
This should be fixed in anaconda-13.21.51-1.

Comment 4 Alexander Todorov 2010-07-07 15:53:54 UTC
I've tested this with snapshot #7 (0701.3 tree) with 2 NICs. 

1) In loader activate eth0 to download stage2. 
2) In stage2 press the Configure network button. Since all interfaces are now managed by NM there's no dialog to select which ones will be not. 
3) In nm-c-e dialog I've selected eth0 and disabled "Connect automatically". Then selected eth1 and enabled "Connect automatically". This is the closest to "check eth1 and uncheck eth0"

4) Close nm-c-e and swith to tty2 and run ifconfig. It showed that both interfaces were active and had assigned addresses by DHCP.
5) Click Next and proceed with the install. Anaconda didn't wait 45 secods but proceeded right away with the installation.

After install the system booted and eth0 was down and eth1 was up as configured in NM. Moving to VERIFIED.

Comment 5 releng-rhel@redhat.com 2010-11-10 19:46:30 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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