This is affecting installation. loader writes out the following ifcfg-eth0 file: DEVICE=eth0 HWADDR=xx:xx:xx:xx:xx:xx ONBOOT=yes BOOTPROTO=dhcp NM_CONTROLLED= NetworkManager does manage to connect and anaconda proceeds, but then it quickly disables the connection. The following messages are from tty5 for installation (all output for NM goes to tty5 during installation): nm-system-settings: ifcfg-fedora: removed /etc/sysconfig/network-scripts/ifcfg-eth0. NetworkManager: <info> (eth0): device state changed: 8 -> 3 NetworkManager: <info> (eth0): deactivating device. NetworkManager: <info> eth0: canceled DHCP transaction, dhcp client pid 1374 NetworkManager: <WARN> check_one_route(): (eth0) error -34 returned from rtnl_route_del(): Success nm-system-settings: ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... nm-system-settings: ifcfg-fedora: error: Invalid IP4 prefix '0' nm-system-settings: ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... nm-system-settings: ifcfg-fedora: error: Invalid IP4 prefix '0' Time stamps are removed from those messages, as well as extra spaces. Not sure what's going on.
I have modified loader to write the new ifcfg-DEVICE file in a temporary directory, then move it in to /etc/sysconfig/network-scripts, but that has not changed anything. Just trying different ideas.
Also worth noting that if you choose manual network configuration in loader, NetworkManager runs along just fine and the interface is brought up. Until we come up with a solution, this problem is preventing DHCP from being used during installation.
Correcting previous information, NetworkManager output goes to tty4 during installation. I keep seeing device state change when I try a DHCP install. Device state change goes from 8 to 3, which I think is from NM_DEVICE_STATE_ACTIVATED to NM_DEVICE_STATE_UNAVAILABLE. Could this be the fault of dhclient or something else on the system? As stated before, static IP configuration is working fine.
OK, now I'm completely confused. After making more changes to anaconda, things appear to be working now. I can't recreate the problem I was having, so I'm going to call this whole issue a problem on the anaconda side.
chris, were you able to reproduce this at all today? I added some bits to NM svn4174 so NM will tell you why it's deactivating the interface, so in that case we were looking at on Friday we should be able to figure out why NM was doing what it was.