Bug 586427 - NetworkManager: ifcfg-rh: warning: NM_CONTROLLED was false but HWADDR was missing; device will be managed
NetworkManager: ifcfg-rh: warning: NM_CONTROLLED was false but HWADDR ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 587003 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-27 10:39 EDT by udo
Modified: 2014-11-12 10:23 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-28 15:52:22 EDT
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 udo 2010-04-27 10:39:24 EDT
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):
NetworkManager-0.8.0-6.git20100408.fc12.x86_64

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:
NetworkManager-0.8.0-6.git20100408.fc12.x86_64

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 13:45:06 EDT
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-27 22:39:37 EDT
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 12:08:01 EDT
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 15:52:22 EDT
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 15:56:55 EDT
*** Bug 587003 has been marked as a duplicate of this bug. ***
Comment 6 udo 2010-04-28 22:41:22 EDT
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 09:21:13 EDT
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 15:26:05 EDT
see https://bugzilla.redhat.com/show_bug.cgi?id=550280#c13
Comment 9 udo 2014-11-12 10:23:48 EST
Nonsense.
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.