Is the NetworkManager service running?  A 'ps aux | grep Net' will tell you if
it is, or "/sbin/service NetworkManager status".

Can you give the output of /sbin/lscpi, (as root) '/sbin/ethtool eth0', and (as
root) '/sbin/mii-tool eth0' ?

Anyway, if you are not running NetworkManager, have you tried to check the
"Activate device when computer starts" option in the properties window when you
click on a device in the "Device" tab and click the Edit... button?

hmm... https://bugzilla.redhat.com/show_bug.cgi?id=324891

I'm not original reporter but, since I have this same problem I'll answer for my
part.

NetworkManager is stopped

Created attachment 294477 [details]
lspci

Settings for eth9:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes


[root@localhost tmp]# /sbin/mii-tool eth9
SIOCGMIIPHY on 'eth9' failed: Operation not supported


Really dump question, where do I find networkmanager? I can get the
networkmanager applet on the tray but, selecting "Edit connections..." does nothing.

I have this problem working on a VMware guest system with two network adapters
configured.  One is set as a static IP and the other is configured by dhcp
(served by the guest OS).  Both are configured with ONBOOT=yes.  The adapter
with static ip has a NETWORKMANAGER=no, but the dhcp adapter did not.  I'm
testing whether this makes a difference in this situation (NetworkManager is
chkconfig'd off).

When I ifdown eth0; ifup eth0 it picks up a new dhcp address just fine, but it
won't work on boot.

Here is more of the info you'd asked for Dan.

Also I've got a dmesg coming.  The main problem (seen in the dmesg) may be the
selinux audits that show up:

type=1400 audit(1205217645.496:4): avc:  denied  { write } for  pid=1700
comm="cp" name="resolv.conf.predhclient.eth0" dev=sda3 ino=426021
scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0
tclass=file
type=1400 audit(1205217645.496:5): avc:  denied  { unlink } for  pid=1700
comm="cp" name="resolv.conf.predhclient.eth0" dev=sda3 ino=426021
scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0
tclass=file

I'll check this permissive in a minute.

Created attachment 297569 [details]
dmesg-vmware-eth0.txt

Created attachment 297570 [details]
vmware-ifcfg-info-eth0.txt

This issue does not happen when booting with selinux permissive; eth0 receives
dhcp configuration on boot.

Using audit2allow produces this (for these denials):
#============= dhcpc_t ==============
allow dhcpc_t etc_t:file { write unlink };
allow dhcpc_t var_log_t:file append;

Creating a module for these by:
ausearch -m avc | grep dhcp | audit2allow -M mydhcp

and loading by:
semodule -i mydhcp.pp

This does not work on reboot with enforcing, but it does work after inserting
the module and then restarting the network service via telinit 1; telinit 3. 
This should probably be changed to an selinux bug.

The vmxnet ethernet driver does not implement the 'ethtool_ops' interface that
the kernel expects, and therefore calls like:

/sbin/ethtool eth0

will fail to return correct values.  This is one part of the equation; you'll
have to get upstream VMWare to fix that issue and then install an updated vmxnet
driver.

The vmware tools and kernel modules are not installed on my system.  Is this a
recent change in expected behavior?  Earlier rawhide kernels did not have this
issue (the dhcp interfaces used to come up on boot just fine).

For me this bug looks fixed, I'm not seeing it any more with Fedora 9 beta.

I'm using Fedora 9 Preview, with all updates applied (as of this evening).
  I'm still seeing this problem.

Here's an ethool dump for eth0:

Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: g
	Current message level: 0x00000007 (7)
	Link detected: yes

When I originally setup this interface in Anaconda, I had NetManager turned off,
with static IP/DNS settings and "bring up interface at startup" set.

It fails to come up on boot every time.  I have to manually bring the interface
  up.  Very annoying, since I'm targetting this to be a server tucked away
  in a cupboard.

Here are messages relating to eth0:  from dmesg:

e100: eth0: e100_probe: addr 0x90010000, irq 20, MAC addr 00:19:d1:68:c5:4f
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present

My static network configuration works fine - this is a fresh install of current
rawhide bits (F9 almost-RC). 

In most cases where the installed system was a pre-release version of F9 and
static network configs are not working properly, it's because that version of F9
didn't write the proper things into ifcfg-ethX *or* had different startup
priorities for the needed services ('network', 'NetworkManager', 'messagebus',
'hald', etc).

Two things to try before reporting a bug:

1) make sure your network configuration has the right stuff in it
A typical /etc/sysconfig/network-scripts/ifcfg-eth0 for a wired network on a
fresh system will have:
ONBOOT=yes
NM_CONTROLLED=
BOOTPROTO=[static/dhcp]
[etc.]

2) make sure your network services are coming up in the right order.
As root, do:
for service in network messagebus haldaemon NetworkManager; do chkconfig
$service resetpriorities; done

You should also attach your ifcfg-ethX files to any further reports.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Same problem for me on one laptop upgraded from F8 to F9 and one fresh install
of F9. I think this is a duplicate of #447536 (my bug).

My config:
[root@somodi ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
controller
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:19:db:00:00:8b
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=yes
DHCP_HOSTNAME=somodi.ciakt.xxxxx.sk
SEARCH=xxxx.sk
NM_CONTROLLED=no
DNS2=1.197.16.30
TYPE=Ethernet
DNS1=1.197.16.31
USERCTL=yes
PEERDNS=yes
PERSISTENT_DHCLIENT=y

Same without PERSISTENT_DHCLIENT option.
Static network works well, but dhcp network not.
Also IPv6 is working well.

dhclient is running after reboot, but no IPv4 address assigned to my interface.

[root@somodi ~]# ps axw | grep dhclient
 2005 ?        Ss     0:00 /sbin/dhclient -q -cf /etc/dhclient-eth0.conf -lf
/var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0

After service resetpriorities my problem looks to be solved. But why this is not
default after a fresh installation?

Second coputer tested again:

NetworkManager must be running to get IPv4 address from DHCP when trying to do
service netowork restart. There is no effect of NM_CONTROLLED= parameter for this.

After uninstall of NetworkManager and a reboot it's working again properly. :-)

There are 2 solutions for users (before fixes in packages):
  1. Uninstall NetworkManager (yum remove NetworkManager -y)
  2. When you need NetworkManager, be sure that:
     a) it is already running (chkconfig NetworkManager on)
     b) it has good priority (see above)

Marking it as a duplicate of bug #447536 per comment #17 and  comment #18.

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