RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 600454 - initscripts try to use NetworkManager when it it has been deconfigured for a device
Summary: initscripts try to use NetworkManager when it it has been deconfigured for a ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: Miroslav Vadkerti
URL:
Whiteboard:
Depends On: 599707
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-04 18:20 UTC by Bill Nottingham
Modified: 2014-03-17 03:23 UTC (History)
12 users (show)

Fixed In Version: initscripts-9.03.9-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 599707
Environment:
Last Closed: 2010-11-10 20:40:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bill Nottingham 2010-06-04 18:20:56 UTC
+++ 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 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 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 Program Management 2010-06-04 18:33:16 UTC
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 07:33:16 UTC
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 20:40:26 UTC
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.