Bug 1479496

Summary:	RHEL 7.4 uEFI PXE incorrectly adds a '-' to tail end of mac address
Product:	Red Hat Enterprise Linux 7	Reporter:	Øystein Bedin <obedin>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED DUPLICATE	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	jbastian, jkonecny
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-19 14:43:42 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 Øystein Bedin 2017-08-08 16:14:34 UTC

Description of problem:
When PXE booting with a RHEL 7.4 image (using PXE files found in 'EFI/BOOT/' as part of the RHEL 7.4 iso), then PXE booting a physical host using uEFI, it looks for a file name with an added '-' at the end. This is new with RHEL 7.4 and it used to work fine with RHEL 7.3. This seems like a breakage as it shouldn't have the '-' at the end from what I'm gathering (see TFTP server trace below). 

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

How reproducible:
Set up a PXE environment and use a uEFI physical host to PXE boot. In our case, we're PXE booting with a Lenovo Flex x240 blade server (running the latest uEFI version). 

Steps to Reproduce:
1. Setup a PXE environment based on RHEL 7.4 with host specific grub.cfg based on MAC address
2. uEFI PXE boot a physical host 
3. Observe that the host fails to obtain the host specific grub.cfg

Actual results:
PXE boot failing to pick up the host specific grub.cfg based on MAC address.

Expected results:
uEFI PXE should work as it used to with RHEL 7.3 (and I believe per the standards it shouldn't add a '-' at the end of the filename)

Additional info:
Here's a verbose trace from the TFTP server:

Aug  8 11:51:01 util-3 in.tftpd[29880]: RRQ from ::ffff:192.168.49.12 filename pxelinux/bootx64.efi
Aug  8 11:51:01 util-3 in.tftpd[29880]: tftp: client does not accept options
Aug  8 11:51:01 util-3 in.tftpd[29881]: RRQ from ::ffff:192.168.49.12 filename pxelinux/bootx64.efi
Aug  8 11:51:01 util-3 in.tftpd[29881]: Client ::ffff:192.168.49.12 finished pxelinux/bootx64.efi
Aug  8 11:51:02 util-3 in.tftpd[29882]: RRQ from ::ffff:192.168.49.12 filename pxelinux/bootx64.efi
Aug  8 11:51:02 util-3 in.tftpd[29882]: Client ::ffff:192.168.49.12 finished pxelinux/bootx64.efi
Aug  8 11:51:02 util-3 in.tftpd[29883]: RRQ from ::ffff:192.168.49.12 filename pxelinux/grubx64.efi
Aug  8 11:51:02 util-3 in.tftpd[29883]: Client ::ffff:192.168.49.12 finished pxelinux/grubx64.efi
Aug  8 11:51:02 util-3 in.tftpd[29884]: RRQ from ::ffff:192.168.49.12 filename /pxelinux/grub.cfg-01-00-0a-f7-57-de-50-
Aug  8 11:51:02 util-3 in.tftpd[29884]: Client ::ffff:192.168.49.12 File not found /pxelinux/grub.cfg-01-00-0a-f7-57-de-50-

Comment 2 Øystein Bedin 2017-08-08 16:31:01 UTC

Just for the record: We worked around the issue by creating symlinks in the directory (i.e.: ln -fs grub.cfg-01-<MAC> grub.cfg-01-<MAC>-), but this shouldn't be necessary.

Comment 3 Jiri Konecny 2017-08-09 08:41:44 UTC

This issue is happening before Anaconda or Dracut is loaded.

Changing component to grub.