Bug 170111

This works for me.

I get the "Cannot talk to rtnetlink" message, but the interface is brought up.

Do you have dhcdbd installed/enabled?

I am having the same trouble on my X86_64 system at the latest rawhide level (everything). 
With iproute-2.6.14-5 one is enable to start network. The system hangs at loopback start, 
which seem to hang while running /sbin/ip. Switching iproute to 2.6.13 and earlier (I could 
only find 2.6.11.1) works fine. 
 
This is with the latest kernel in rawhide as well as with 2.6.13-smp.1.1526 kernel from FC4 
updates. 

Re comment #1

Enabled?  Don't know.   How can I tell?

The following services listed in NTSYSV are *NOT* selected:

NetworkManager
NetworkManagerDispatcher
dhcp6s
dhcpd
dhcrelay

I have both NetworkManager services enabled (running on a laptop) and dhcdbd
enabled as well.

The latest dhcdbd package adds itself to the list managed by 'Desktop->System
Settings->Server Settings->Services' (aka system-config-services).  

Not sure if this is the same problem I had before, though.

I don't understand the relevance of dhcdbd to this problem?

I have a working desktop system, with static IP address and network configuration,
that breaks just by upgrading iproute from rpm.  Downgrading iproute clears the
problem.   I'm not modifying any other network software.  I'm not even rebooting
the system.

I have none of those enabled. I just confirmed the ip hang on my i386 system
as well at latest rawhide. I rebuild 2.6.13-3 rpm and this works both on
i386 and 86_64 with older or the latest 2.6.14 based rawhide kernels.

Sorry, I was just trying to identify differences between your system (that's not
working) and mine (that is working).

I didn't mean to criticise.   I just don't understand the connection to dhcdbd
or why one would suspect it as being involved?  

I tried turning it on with "service start dhcbdb" but the problem still exists.
(Why doesn't dhcbdb have an entry in ntsysv ? )

root@ellson:fc-devel# service dhcdbd start
Starting dhcdbd:                                           [  OK  ]
root@ellson:fc-devel# ntsysv
root@ellson:fc-devel# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:  Cannot talk to rtnetlink: Invalid argument
                                                           [  OK  ]
Bringing up interface eth0:  Cannot talk to rtnetlink: Invalid argument
Error adding address 135.207.24.103 for eth0.
bind: Cannot assign requested address
Cannot talk to rtnetlink: Invalid argument
Cannot talk to rtnetlink: Invalid argument
                                                           [  OK  ]

I use dynamic IPs, not static (hence dhcdbd and NM). Sorry, dhcdbd looks like a
red herring.

Checking my /var/log/messages, it appears that after eth0 is configured during
boot (and I get the rtnetlink messages), ntpd fails with DNS errors.  

By the time I login in (run level 5), NetworkManager is running, and all appears
to be fine.

For the record, the patch noted for iproute works for me on FC4 i386 on the two
systems tested.  service network start succeeds, no problems for me.

Created attachment 119726 [details]
Tested just after installation completed 

After installation completed and due to notes made to the test list, I saved
the output from a term and cat redirected to a file. Here is "service network
restart" output in the terminal.

adding to CC

It would seem that it was the update to the upstream 050929 snapshot is what
breaks it; updating to the 051007 snapshot fixes it for me.

Probably related to this, my box hangs on "bringing up loopback interface" after
the latest updates from Rawhide. Funny enough, and for whatever reason, the box
doesn't want to come up in single user mode either (i.e. I give it an "s" at the
end of the boot line and it boots RL 5 - weird), so I think recovery CDs will be
put in action...

Adding myself to CC list.

Reverting to 2.6.14-4 fixes the hang here too.

iproute-2.6.14-6 works and does not exhibit the problem encontered with the
prevous release.