Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 671081

Summary: NetworkManager is not installed
Product: Red Hat Enterprise Linux 6 Reporter: Alexander Todorov <atodorov>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: dmach, harald, notting, syeghiay
Target Milestone: beta   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-20 23:04:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 670159    
Attachments:
Description Flags
anaconda.ifcfg.log
none
anaconda.log
none
anaconda.program.log
none
anaconda.storage.log
none
anaconda.syslog
none
anaconda.yum.log
none
anaconda-ks.cfg
none
install.log
none
install.log.syslog none

Description Alexander Todorov 2011-01-20 09:09:30 UTC 
Description of problem:
NM is not installed when performing kickstart installation. Because eth interfaces are marked as NM_CONTROLLED="yes" by anaconda this causes no active network on the installed system. 

Version-Release number of selected component (if applicable):
This is with 0118.n.0 nightly build.

How reproducible:
Always

Steps to Reproduce:
1. Schedule a test case in Beaker.
2.
3.
  
Actual results:
NM is not installed

Expected results:
NM is installed

Additional info:
ks.cfg contains: 

%packages --ignoremissing
@Base
@Core
@base
@desktop-platform-devel
@development
@development-libs
@development-tools
@server-platform-devel
RTT
beah
expect
gcc
install
koan
koan
lftp
libxml2-python
make
nfs-utils
ntp
procmail
pyOpenSSL
python
redhat-lsb
wget
Comment 1 Alexander Todorov 2011-01-20 09:10:28 UTC 
Post install the system has no network:

[root@dell-pe2850-01 ~]# ifconfig 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 2 Alexander Todorov 2011-01-20 09:12:38 UTC 
And there's a second issue here as well. The network interfaces are named em1 and em2 instead of eth0 and eth1 but the config files don't respect that:

[root@dell-pe2850-01 network-scripts]# ls -l ifcfg-*
-rw-r--r--. 1 root root  90 Jan 19 23:09 ifcfg-eth0
-rw-r--r--. 1 root root  73 Jan 19 22:34 ifcfg-eth1
-rw-r--r--. 1 root root 254 Jan 14 15:00 ifcfg-lo

[root@dell-pe2850-01 network-scripts]# ifconfig -a
em1       Link encap:Ethernet  HWaddr 00:11:43:D2:D2:E6  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

em2       Link encap:Ethernet  HWaddr 00:11:43:D2:D2:E7  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 3 Alexander Todorov 2011-01-20 09:17:34 UTC 
Created attachment 474413 [details]
anaconda.ifcfg.log
Comment 4 Alexander Todorov 2011-01-20 09:18:03 UTC 
Created attachment 474414 [details]
anaconda.log
Comment 5 Alexander Todorov 2011-01-20 09:18:13 UTC 
Created attachment 474415 [details]
anaconda.program.log
Comment 6 Alexander Todorov 2011-01-20 09:18:23 UTC 
Created attachment 474416 [details]
anaconda.storage.log
Comment 7 Alexander Todorov 2011-01-20 09:18:29 UTC 
Created attachment 474417 [details]
anaconda.syslog
Comment 8 Alexander Todorov 2011-01-20 09:18:39 UTC 
Created attachment 474418 [details]
anaconda.yum.log
Comment 9 Alexander Todorov 2011-01-20 09:18:50 UTC 
Created attachment 474419 [details]
anaconda-ks.cfg
Comment 10 Alexander Todorov 2011-01-20 09:19:04 UTC 
Created attachment 474420 [details]
install.log
Comment 11 Alexander Todorov 2011-01-20 09:19:13 UTC 
Created attachment 474421 [details]
install.log.syslog
Comment 12 Alexander Todorov 2011-01-20 09:36:45 UTC 
Per irc log below:

(11,32,29) atodorov: NM is in the basic-desktop group in comps which is not installed in my case
(11,32,42) atodorov: shouldn't anaconda set NM_CONTROLLED=no if NM is not installed ? 
(11,34,02) rvykydal: no, initscripts should do their job even if NM_CONTROLLED is yes (or missing because default is yes)
(11,35,11) rvykydal: NM_CONTROLLED should be relevant only for NM i think
(11,35,25) atodorov: ok, then the cause of the bug is that device names changed 


Looks like anaconda is doing fine and the only problem is that device names are different from ifcfg-* config files. Not sure which component is this.
Comment 13 Alexander Todorov 2011-01-20 16:03:26 UTC 
Harald,
is this something to do with biosdevname ?
Comment 14 Harald Hoyer 2011-01-20 16:53:43 UTC 
(In reply to comment #13)
> Harald,
> is this something to do with biosdevname ?

the interface naming is from biosdevname, which anaconda really should handle correctly. So biosdevname has to be in the installer image also.
Comment 15 Bill Nottingham 2011-01-20 17:42:13 UTC 
Yes, this is an anaconda issue.
Comment 16 Dave Cantrell 2011-01-20 23:04:17 UTC 

*** This bug has been marked as a duplicate of bug 654063 ***