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 690589 - RHEL 6.1 Beta: ifcfg-emN and ifcfg-pciXpY files should not contain HWADDR field
Summary: RHEL 6.1 Beta: ifcfg-emN and ifcfg-pciXpY files should not contain HWADDR field
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-24 17:53 UTC by Narendra K
Modified: 2011-05-19 12:40 UTC (History)
8 users (show)

Fixed In Version: anaconda-13.21.109-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 12:40:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0530 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2011-05-18 17:44:52 UTC

Description Narendra K 2011-03-24 17:53:51 UTC
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 Program Management 2011-03-28 21:19:44 UTC
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 12:06:03 UTC
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 20:41:24 UTC
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 11:21:48 UTC
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 15:34:15 UTC
Another possible malconsequence of HWADDR removal:
https://bugzilla.redhat.com/show_bug.cgi?id=696198#c5

Comment 10 David Cantrell 2011-04-13 19:59:03 UTC
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 16:39:37 UTC
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 16:45:37 UTC
Any thoughts on this Bill?

Comment 13 Bill Nottingham 2011-04-25 14:37:54 UTC
(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 14:41:25 UTC
(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 17:08:24 UTC
(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 12:40:00 UTC
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.