Description of problem: When installing F14-Alpha, the network configurations have NM_CONTROLLED="yes" written even on the minimal install selection which does not include NetworkManager.
Oops, reassign to F14.
Thanks for the report. What is the problem caused by the NM_CONTROLLED setting? I'd guess the network is not up after reboot - then the cause would not be setting of NM_CONTROLLED but that of ONBOOT=no, which would make this a dupe of bug 620823. Is it your case?
ifup/ifdown wasn't doing anything. Looking at it again, the root cause is probably that BOOTPROTO="dhcp" missing.
Can you please attach /var/log/anaconda.syslog, /var/log/anaconda.log from installed system? Also /tmp/ifcfg.log gathered before the end of install (it can by done by switching to tty2 and using scp to remote machine or cp to local storage), or post-install /etc/sysconfig/network-scripts/ifcfg-eth* files would be helpful. Did you do any network configuring/enabling in UI during install? Can you describe it?
I didn't do anything during the install with networking other than use it (netinst). Attaching logs from a 14-Alpha install.
Created attachment 446932 [details] ifcfg-eth0
Created attachment 446933 [details] ifcfg-wlan0
Created attachment 446935 [details] anaconda.log
Created attachment 446937 [details] anaconda.syslog
Okay, it seems to have worsened for F14 Beta. NM_CONTROLLED is still "yes". There is also a lot of other data written to these files that I haven't seen before (though it looks benign). TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no NAME="System eth0" UUID=<hex> Since the beta seems to use anaconda shipped in it, the network was configured right before install rather than before stage2 fetching. NM really needs to not touch the installed system's network configuration in anaconda IMO.
(In reply to comment #10) > Okay, it seems to have worsened for F14 Beta. NM_CONTROLLED is still "yes". > There is also a lot of other data written to these files that I haven't seen > before (though it looks benign). > > TYPE=Ethernet > BOOTPROTO=dhcp > DEFROUTE=yes > PEERDNS=yes > PEERROUTES=yes > IPV4_FAILURE_FATAL=yes > IPV6INIT=no > NAME="System eth0" > UUID=<hex> Now with BOOTPROTO present, ifup/ifdown should work (comment #3) so it doesn't seem like worsening to me. Writing NM_CONTROLLED and other stuff should be harmless for minimal target system (a system without NM). We are aware that we are writing stuff into ifcfg files, and it has its purpose. To be able to address your report we need to know what the actual problem is - what doesn't work for you - only then the info about content of ifcfg files or logs becomes useful. We are now tracking two issues that might be the same as yours, both for installs where network: - is not enabled during install - is not configured in GUI with Connection Editor (invoked with "Configure Network" button) - is not configured in kickstart with network command One is that network is not automatically brought up after install - bug #498207, the second is that for minimal install, in addition to that, it can't be brought up with ifup (missing configuration, e.g. default BOOTPROTO=dhcp) - bug #639006. Do the bugs subsume your issue or is it something different?
Oops, indeed. Sorry; shouldn't be cruising BZ that late after an exhausting day. I can confirm that this is fixed (at least bug #639006). I'm used to ifup/ifdown manually so I didn't notice that being an issue at all. *** This bug has been marked as a duplicate of bug 639006 ***