Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 600454 - initscripts try to use NetworkManager when it it has been deconfigured for a device
initscripts try to use NetworkManager when it it has been deconfigured for a ...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: initscripts Maintenance Team
Miroslav Vadkerti
:
Depends On: 599707
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-04 14:20 EDT by Bill Nottingham
Modified: 2014-03-16 23:23 EDT (History)
12 users (show)

See Also:
Fixed In Version: initscripts-9.03.9-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 599707
Environment:
Last Closed: 2010-11-10 15:40:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2010-06-04 14:20:56 EDT
+++ This bug was initially created as a clone of Bug #599707 +++

Description of problem:
When I uncheck "Controlled by NetworkManager" in system-config-network, the network interface deactivates and won't reactivate.

Version-Release number of selected component (if applicable):
system-config-network-1.6.0-2.fc13.noarch

How reproducible:
always

Steps to Reproduce:
1. system-config-network
2. Click eth0, click edit, uncheck "Controlled by NetworkManager", click OK
3. File->Save
4. Click "Activate"
  
Actual results:
A pop-up box says, "Error: Unknown connection: 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03." and the network does not work.

Expected results:
Either the network should work, or it should give a helpful error message which gives a hint as to how to resolve the problem. 

Additional info:
Despite having used Fedora for years, I'm stumped by the current network setup. I absolutely do not want my computer to connect to my dhcp server, or try to scout out other ways to connect, or to raise and lower the network connection at the console user's whim. I want to give it a static ip address, and have it connect to that at boot and remain connected until shutdown. There should be an easy way to shut off all the dynamic network "management".

--- Additional comment from jpopelka@redhat.com on 2010-06-04 09:48:55 EDT ---

(In reply to comment #0)
> Actual results:
> A pop-up box says, "Error: Unknown connection:
> 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03." and the network does not work.
> 
Not a s-c-network problem.
Adding (or changing to)
NM_CONTROLLED=no
in network-scripts/ifcfg-ethx (ethx is previously NM controlled NIC)
and then ifup ethx
also fails with the above mentioned Error.

Not sure whether this is initscripts (let's try this first) or NM problem (adding Dan to CC).
 
> Additional info:
> Despite having used Fedora for years, I'm stumped by the current network setup.
> I absolutely do not want my computer to connect to my dhcp server, or try to
> scout out other ways to connect, or to raise and lower the network connection
> at the console user's whim. I want to give it a static ip address, and have it
> connect to that at boot and remain connected until shutdown. There should be an
> easy way to shut off all the dynamic network "management".
what about:
Right click on NM-applet, 'Edit connections...', select interface, 'Edit...', 'IPv4 Settings' tab, switch Method to Manual, fill in your static address/netmask

--- Additional comment from jbayes@gmail.com on 2010-06-04 10:46:28 EDT ---


> Right click on NM-applet, 'Edit connections...', select interface, 'Edit...',
> 'IPv4 Settings' tab, switch Method to Manual, fill in your static
> address/netmask    

When I first tried the above (right-click, manage connections), there was no interface listed. So I created one, called it eth0, but no matter what I do it is listed as "last used: never". 

But if I click on nm-applet, it lists two connections: there's eth0, with a little heart beside it, and says "active", but there's an unplugged rj45 jack beside it and if I hover, a blue window pops up with "status: preparing to connect". 

There's also a "System eth0", which has none of the above heart and rj45, etc. But if I delete my "eth0", then the "System eth0" gets the "active" tag with the heart and the rj45 and the "preparing to connect". 

When I first booted, I thought I had set up my network properly. After spending a couple of hours figuring out why I couldn't accept incoming connections, I found that the system had ignored the network that I had set up and had sneakily gotten itself a dynamic IP and called it "auto manage" or something like that. I'm not sure how I managed to turn that off, but at least it's gone. 

Sorry about the rambling. If there's any helpful information I can provide...
Comment 1 RHEL Product and Program Management 2010-06-04 14:33:16 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Miroslav Vadkerti 2010-09-24 03:33:16 EDT
VERIFIED as fixed in initscripts-9.03.17-1.el6

I could not reproduce the fail of ifup ethX no more with the latest initscripts. Movin to verified.

Patch is applied in current sources
[snip]
    ! is_false $NM_CONTROLLED && is_nm_running && USE_NM=true
    if [ -z "$UUID" -a "$USE_NM" = "true" ]; then
    UUID=$(get_uuid_by_config $CONFIG)
    fi
[snip
Comment 4 releng-rhel@redhat.com 2010-11-10 15:40:26 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.