Bug 696286

Well, NetworkManager should honor the settings passed from dracut: 

/dev/.initramfs/state/etc/net.$netif.resolv.conf
/dev/.initramfs/state/etc/sysconfig/network-scripts/ifcfg-*
/dev/.initramfs/net.*

In F15+ these setting can be found in /run/initramfs instead of /dev/.initramfs

Many thanks for your help - a bit of additional info:

The versions of dracut and NetworkManager are

dracut-006-6.fc14.noarch
NetworkManager-0.8.3.998-2.fc14.i686

With NetworkManager disabled the machine boots fine and I'm able to SSH into it, but as there's no eth0 defined networking from the machine doesn't work at all. I've then created the ifcfg-eth0 file included below and enabled the NetworkManager service, and when it starts the network is disconnected and nfsroot stops working.

ifcfg-eth0:

DEVICE=eth0
ONBOOT=yes
TYPE=Ethernet
HWADDR=00:30:18:A2:A0:FD
BOOTPROTO=dhcp
IPV6INIT=no
USERCTL=no
NAME="System eth0"
UUID=3ce85f3a-7980-4e2d-a191-3fa554ca79dc
DEFROUTE=yes

(In reply to comment #2)
> In F15+ these setting can be found in /run/initramfs instead of /dev/.initramfs

NM honors anything in /etc/sysconfig/network-scripts and /var/lib/dhclient/*.lease, otherwise the interface will get taken down.  The problem with keeping this stuff in /dev/.initramfs is that that location is not the permanent location for configuration storage...  So I was hoping that something would copy the stuff from that location in /dev/.initramfs to /etc/sysconfig/network-scripts and the leases to /var/lib (which of course is the location that network config is stored) and then NM will automatically pick it up.  Having NM read and monitor another directory for network configuration gets confusing and complicated...

(In reply to comment #4)
> (In reply to comment #2)
> > In F15+ these setting can be found in /run/initramfs instead of /dev/.initramfs
> 
> NM honors anything in /etc/sysconfig/network-scripts and
> /var/lib/dhclient/*.lease, otherwise the interface will get taken down.  The
> problem with keeping this stuff in /dev/.initramfs is that that location is not
> the permanent location for configuration storage...  So I was hoping that
> something would copy the stuff from that location in /dev/.initramfs to
> /etc/sysconfig/network-scripts and the leases to /var/lib (which of course is
> the location that network config is stored) and then NM will automatically pick
> it up.  Having NM read and monitor another directory for network configuration
> gets confusing and complicated...

What about readonly NFS root? "/run" is the perfect location.

Checked this for Fedora 16, and it is safe to start network manager on an nfs mounted root, provided that NetworkManager is not allowed to control this connection. I'm not sure this would be a dracut bug.

dracut-013-20.fc16.noarch
NetworkManager-0.9.2-1.fc16.i686

The file ifcfg-em1 should exist and contain (at least?) the following lines:

NM_CONTROLLED="no"
ONBOOT="no"
HWADDR="xx:xx:xx:xx:xx:xx"
DEVICE="em1"
BOOTPROTO=DHCP

I guess the NM_CONTROLLED="no" line is of importance in this case. If NetworkManager takes control this does indeed stop the network connection to your root filesystem.

Just wanted to include this comment because the bug seems to indicate that Network Manager cannot be used with an NFS mounted root.

Maybe it would be nicer if dracut rewrites the ifcfg-em1 file as I think it does when explicit network configuration from the dracut kernel command line is used.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping