Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 586427 - NetworkManager: ifcfg-rh: warning: NM_CONTROLLED was false but HWADDR was missing; device will be managed
Summary: NetworkManager: ifcfg-rh: warning: NM_CONTROLLED was false but HWADDR ...
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
: 587003 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-27 14:39 UTC by udo
Modified: 2014-11-12 15:23 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-28 19:52:22 UTC
Type: ---

Attachments (Terms of Use)

Description udo 2010-04-27 14:39:24 UTC
Description of problem:
NetworkManager:    ifcfg-rh:     warning: NM_CONTROLLED was false but HWADDR was missing; device will be managed
NM_CONTROLLED is not the tool to control this very choice?

Version-Release number of selected component (if applicable):

How reproducible:
Update to NetworkManager-0.8.0-6.git20100408.fc12.x86_64

Steps to Reproduce:
1. yum update
2. see /var/log/messages
3. bingo
Actual results:

Expected results:
No such claims, behaviour as expected, as configured, etc.

Additional info:
Also routing was borked after update. Had to restart network (!) to fix it.

Comment 1 Dan Williams 2010-04-27 17:45:06 UTC
Does the ifcfg file that contains NM_CONTROLLED=no also contain HWADDR=xx:xx... or not?  That's always been mandatory for making NM ignore a device, since devices can only be positively identified by their MAC address (or some other unique hardware ID), not device name.

Comment 2 udo 2010-04-28 02:39:37 UTC
This logic goes WAY too far, again.
NM_CONTROLLED is a KILL-switch. off = NO networkmanager. It saves us. It places us in control.
udev takes care of device naming.
Handle issues there, not in networkmanager.

We had this discussion before when my eth0 (with hw address!) was assigned some usb0 number.
This is borken behaviour. It is.

Please fix.

Comment 3 udo 2010-04-28 16:08:01 UTC
Also: If NM does not see a HW address it will confuse everything, as we have seen.[1]
So if _also_ NM_CONTROLLED is set to off, why bother and INSIST on controlling stuff that is not to be controlled, even if it could control at all?
Just keep NM off of that stuff.

Please fix the logic first, then try to improve on directions by the user.
This will make the user happy.

NM should not doubt device names. Device names are udev's domain.
So name is first choice.
A HW address is an extra check. If the name/HW don't match then complain in logs etc.
If there is no HW address and it IS to be NM_controlled, just act as configured.
Do not secondguess anything.
NOT anything, I wrote.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=550280

Comment 4 Dan Williams 2010-04-28 19:52:22 UTC
When you set NM_CONTROLLED=no, NM needs to know *what* device to stop controlling.  And since device names are not stable, HWADDR is the only way to determine which device should not be controlled by NetworkManager.

udev *tries* to create stable device names, but it's best-effort and does not always work.  Furthermore, devices can be renamed at runtime which breaks any scheme that uses device names.

If the device does not have a MAC address, use udev rules to assign a unique, stable MAC address to the device using a combination of USB serial number or other USB descriptors.

Seriously. Use HWADDR to lock the ifcfg to the device, and things will work.  But if NetworkManager does not fit your needs, you can also remove it or turn it off.

So were NM to use interface names, what happens if you plug another USB ethernet adapter in?  Or another iPaq?  USB enumeration is not stable, and it's very likely that whatever used to be usb0 is now usb1.  This is why you need to be using stable MAC addresses to uniquely identify the device, not device names.

Comment 5 Dan Williams 2010-04-28 19:56:55 UTC
*** Bug 587003 has been marked as a duplicate of this bug. ***

Comment 6 udo 2010-04-29 02:41:22 UTC
NM does know the name from the DEVICE=eth0 line.

Please do not ridicule the names idea as it does mention HW addresses.
The current situation is borken to say the least.
Please find a solution.

Comment 7 udo 2010-04-29 13:21:13 UTC
I.e.: trust udev. Or if not, work on udev so that you can trust it.
Or should I assign this issue to udev so you can explain what needs to be fixed?

Comment 8 Dan Williams 2010-04-29 19:26:05 UTC
see https://bugzilla.redhat.com/show_bug.cgi?id=550280#c13

Comment 9 udo 2014-11-12 15:23:48 UTC
You say you need a HW adress to manage.
The dev did not have one.
So you manage it.
That is logic. (!?)
That is not what the user wants.
That is what we have udev for.
That is why the user got rid of NM as much as he could.

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