Bug 690589
| Summary: | RHEL 6.1 Beta: ifcfg-emN and ifcfg-pciXpY files should not contain HWADDR field | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Narendra K <narendra_k> |
| Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | borgan, dcantrell, dcbw, jordan_hargrave, linux-bugs, mganisin, notting, paniraja_km |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | anaconda-13.21.109-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-19 12:40:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Narendra K
2011-03-24 17:53:51 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. 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 I think system-config-network would still create HWADDR. Also, with HWADDR not being present, is 'DEVICE=' field required ? 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? Another possible malconsequence of HWADDR removal: https://bugzilla.redhat.com/show_bug.cgi?id=696198#c5 We will likely be reverting this patch and marking this bug as devel_ack- since it is causing bug #696127 and bug #696198 regressions. 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. Any thoughts on this Bill? (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.) (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...) (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. 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 |