This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 690589 - RHEL 6.1 Beta: ifcfg-emN and ifcfg-pciXpY files should not contain HWADDR field
RHEL 6.1 Beta: ifcfg-emN and ifcfg-pciXpY files should not contain HWADDR field
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Radek Vykydal
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-24 13:53 EDT by Narendra K
Modified: 2011-05-19 08:40 EDT (History)
8 users (show)

See Also:
Fixed In Version: anaconda-13.21.109-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 08:40:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Narendra K 2011-03-24 13:53:51 EDT
Description of problem:

With 'biosdevname' suggesting names to network interfaces based on their physical location of the mother board, the ifcfg-emN and ifcfg-pciXpY files need not contain HWADDR field. The names are suggested by biosdevname every time the system reboots.

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

anaconda-13.21.104-1.el6

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
ifcfg-emN and ifcfg-pciXpY files contain HWADDR field.


Expected results:
ifcfg-emN and ifcfg-pciXpY files contain HWADDR field.


Additional info:
Comment 2 RHEL Product and Program Management 2011-03-28 17:19:44 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 3 Radek Vykydal 2011-03-29 08:06:03 EDT
Hm, I thought it was harmless, just providing the info for nm-c-e in anaconda (not that I know if anybody cares). Here is a patch that should stop anaconda writing out HWADDR:
http://www.redhat.com/archives/anaconda-devel-list/2011-March/msg00280.html
Comment 6 Narendra K 2011-03-31 16:41:24 EDT
I think system-config-network would still create HWADDR. 

Also, with HWADDR not being present, is 'DEVICE=' field required ?
Comment 8 Radek Vykydal 2011-04-13 07:21:48 EDT
Removing HWADDR breaks BOOTPROTO=ibft configuration as NetworkManager (ifcfg-rh plugin) needs this information to read ibft configuration using iscsiadm, see
bug #696127.

Also, biosdevname feature is on by default only for specific dell hardware, no?

Is writing-out HWADDR actually breaking anything?
Comment 9 Radek Vykydal 2011-04-13 11:34:15 EDT
Another possible malconsequence of HWADDR removal:
https://bugzilla.redhat.com/show_bug.cgi?id=696198#c5
Comment 10 David Cantrell 2011-04-13 15:59:03 EDT
We will likely be reverting this patch and marking this bug as devel_ack- since it is causing bug #696127 and bug #696198 regressions.
Comment 11 Dan Williams 2011-04-21 12:39:37 EDT
We'll need to find a better way of handling locking specific configuration to specific hardware with NetworkManager.  The problem is that for most consumer hardware we can't use device names, since they aren't always stable.  But for enterprise hardware we now do want to account for the BIOS name of the device.

I don't mind adding another mechanism like HWADDR for "bus:slot:port" like we've got SUBCHANNELS for s390, we just need to be able to get that information.  Should we create a new "HWNAME" field that would contain that sort of information or something?  HWNAME and HWADDR would be mutually exclusive.  We'd probably want HWNAME (or whatever we call it) to work across platforms, thus we'd have to include the mechanism/scheme used to get that hardware-name in the text.

One thing we'd need is a mechanism to do the reverse of what biosdevname does, ie take a BIOS device name and get the kernel device name that corresponds to it.

If we had a mechanism like this, then anaconda could write out HWNAME for those devices, and if that didn't exist, fallback to HWADDR, and then NM would take that information and do the right thing.
Comment 12 Dan Williams 2011-04-21 12:45:37 EDT
Any thoughts on this Bill?
Comment 13 Bill Nottingham 2011-04-25 10:37:54 EDT
(In reply to comment #11)
> We'll need to find a better way of handling locking specific configuration to
> specific hardware with NetworkManager.  The problem is that for most consumer
> hardware we can't use device names, since they aren't always stable.  But for
> enterprise hardware we now do want to account for the BIOS name of the device.

I'm a bit confused here. Can't NM just assume that an ifcfg-provided configuration is tied to a device, if a device name is specified? (Essentially, it's up to the admin to make sure that device is correct.)
Comment 14 Bill Nottingham 2011-04-25 10:41:25 EDT
(Especially in the case of anaconda, where we know that the configurations anaconda is writing map to the device state that existed when anaconda was booted...)
Comment 15 Narendra K 2011-04-25 13:08:24 EDT
(In reply to comment #8)
> Removing HWADDR breaks BOOTPROTO=ibft configuration as NetworkManager (ifcfg-rh
> plugin) needs this information to read ibft configuration using iscsiadm, see
> bug #696127.
> 
> Also, biosdevname feature is on by default only for specific dell hardware, no?
> 
> Is writing-out HWADDR actually breaking anything?

Passing 'biosdevname=0' during install time would prevent the new naming scheme coming into effect. But at run time, on a system with new naming scheme already in place, passing 'biosdevname=0' and rebooting the system will have no effect as the initscripts will take the HWADDR from the ifcfg-* and rename the interface to whatever 'DEVICE=' is set to. But if HWADDR is not present in ifcfg-* files, this rename based on HWADDR will not happen and make the behavior consistent during install time and run time.

On systems where biosdevname is off by default (systems where SMBIOS version < 2.6), 70-persistent-net.rules will be created which has the MAC address to DEVICE name mapping.
Comment 16 errata-xmlrpc 2011-05-19 08:40:00 EDT
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-0530.html

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