Bug 1270309

Summary: iPXE: ${mac} macro not necessarily points to the MAC of the NIC we are booting from
Product: Red Hat OpenStack Reporter: Lucas Alvares Gomes <lmartins>
Component: openstack-ironicAssignee: Lucas Alvares Gomes <lmartins>
Status: CLOSED NOTABUG QA Contact: Toure Dunnon <tdunnon>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: mburns, rhel-osp-director-maint, sbaker, srevivo
Target Milestone: ---Keywords: ZStream
Target Release: 8.0 (Liberty)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-19 10:42:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lucas Alvares Gomes 2015-10-09 14:46:48 UTC
Description of problem:
The iPXE macro ${mac} not not necessarily points to the MAC of the NIC we are booting from (see attachment). The machine is booting from a NIC ending with "95:1a" but the ${mac} variable is returning a MAC address from another NIC.

While rare, this situation can happen and we need to make sure our iPXE script is prepared to deal with it, my propose would be to loop over all NICs in order and try to boot from the first one that works

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


How reproducible:
Random

Steps to Reproduce:
1.
2.
3.

Actual results:
If the big happens the machine will fail to boot

Expected results:
Machine booting correctly

Additional info:

Comment 2 Steve Baker 2016-04-10 23:35:05 UTC
It could be that the iPXE images in ipxe-bootimgs-20160127-1.git6366fa7a don't have this problem with ${mac}. Some testing with this image may show the problem is gone.

Also the solution which loops over all nics won't work on the old gitc4bce43 images because they don't have the inc function.

Comment 3 Lucas Alvares Gomes 2016-05-19 10:42:15 UTC
Thanks Steve,

Yes it was a problem with iPXE and has been fixed already.