When exactly does the NIC *not* have a cable attached?

But in any case, can you provide the results of this command?

dbus-send --system --print-reply --dest=com.redhat.ifcfgrh1 /com/redhat/ifcfgrh1 com.redhat.ifcfgrh1.GetIfcfgDetails string:"/etc/sysconfig/network-scripts/ifcfg-eth0"

sorry for the confusion. This is a quad-port NIC with the same configuration always:
eth0 cable connected
eth1 no cable
eth2 no cable
eth3 no cable

[root@intel-sunriseridge-01 ~]# dbus-send --system --print-reply --dest=com.redhat.ifcfgrh1 /com/redhat/ifcfgrh1 com.redhat.ifcfgrh1.GetIfcfgDetails string:"/etc/sysconfig/network-scripts/ifcfg-eth0"
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.redhat.ifcfgrh1 was not provided by any .service files

When you get that output to the command, can you check whether or not NetworkManager is actually running?

ps ax | grep Net

that response indicates that NM may not actually be running at the time.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Thanks jkachuck for the clear steps to reproduce.

I think the problem is in ifdown script.
The first 'ifdown eth0' calls  'nmcli dev disconnect iface eth0', because the device is connected. However the second 'ifdown eth0' doesn't call that command. Instead it continues executing the script as if NM was not running, and calls 'ip link set dev eth0 down' that brings the link down. That's why next 'ifup eth0' is not successful within NM.

I'd suggest this change in /etc/sysconfig/network-scripts/ifdown:
if [ "$USE_NM" = "true" ]; then
    if [ -n "$UUID" -a -z "$DEVICE" ]; then
        DEVICE=$(nmcli -t --fields uuid,devices con status | awk -F ':' "\$1 == \"$UUID\" { print \$2 }")
    fi
-    if [ -n "$DEVICE" ] && is_nm_active "$DEVICE" ; then
+    if [ -n "$DEVICE" ] ; then
        nmcli dev disconnect iface "$DEVICE"
        exit $?
    fi
fi

'nmcli dev disconnect' will just return an error that the device is not active, but the link won't be down.

Event posted on 10-26-2010 09:52pm EDT by Glen Johnson

------- Comment From qinzhl.com 2010-10-26 21:47 EDT-------
(In reply to comment #22)
> Hello IBM,
> Please let me know if you would be able to test this to confirm it
corrects
> this issue.
>
> Thank You
> Joe Kachuck

Yes, It works. But  when will the 1st Rhel6 be released and this bug going
to be integrated into the 1st Rhel6 normal release?

And also we suggest that the error message for repeated ifdown can be
optimized.

Thanks.


This event sent from IssueTracker by jkachuck 
 issue 1482233

Bill, what do you think?

No, b/c that will cause errors on bonding, bridging, etc. devices that don't use NM but are present when NM is running.

Created attachment 456835 [details]
ifdown: call nmcli for managed devices, ifdown-<devtype> for others

Oh, you are right. That would break function for devices unmanaged by NM.
Nevertheless, we should call nmcli not only for connected devices, but for all managed devices. The attached patch should fix both cases.

Event posted on 11-21-2010 05:09am EST by Glen Johnson

File uploaded: sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

This event sent from IssueTracker by jkachuck 
 issue 1482233
it_file 1161453

*** Bug 628545 has been marked as a duplicate of this bug. ***

Created attachment 467288 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

------- Comment From qinzhl.com 2010-10-21 01:29 EDT-------
(In reply to comment #14)
> (In reply to comment #12)
> > Created an attachment (id=57148) [details] [details]
> > SOSReport
> Hi
>
> Thank you for providing sosreport. please provide the following as well.
>
> 1. Installation key used during installation.
> 2. Was the NetworkManager stopped, and network was started before doing any of
> this testing.
>
> Cheers,
> Prem

1. What do you mean by the installation key? I have no key typed on my installation. The ISO I use is from https://ftp3.linux.ibm.com/files/redhat/beta_cds

2. NO, I have verified that it is an issue of NetworkManager. When I stop NetworkManager and start network, everything goes well.

------- Comment From qinzhl.com 2010-10-21 22:02 EDT-------
(In reply to comment #17)
> Hello,
> In the summery you noted  it works on Rhel6 Basic Server while failed on other
> Rhel6 Servers.
> Please provide more details on how to recreate this issue. Please confirm how
> you are doing the install.
>
>
> Status set to: Waiting on Client

1 Install Rhel6 Development Server (All other options is by default)
2 Input the following cmds and then you will find the problem(Here eth0 is already up):

ifdown eth0
ifdown eth0
ifup eth0

I have verified it's an issue of NetworkManager. Infact as long as you start the NetworkManager, the issue can be reproduced.

All of these info already mentioned on comments 4 and 15, why don't take a glance at the history records?

> Please let me know if you would be able to test this to confirm it corrects
>
> Thank You
> Joe Kachuck

Yes, It works. But  when will the 1st Rhel6 be released and this bug going to be integrated into the 1st Rhel6 normal release?

And also we suggest that the error message for repeated ifdown can be optimized.


------- Comment From prem.karat.ibm.com 2011-01-07 02:51 EDT-------
Joe,

Can you confirm in which release this fix is going to be included?

Cheers,
Prem

Created attachment 487842 [details]
SOSReport


------- Comment (attachment only) From qinzhl.com 2010-10-19 22:14 EDT-------

Created attachment 487843 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

Created attachment 487844 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

Created attachment 487845 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

Created attachment 487846 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0647.html