[syslinux] pxelinux efi64 boot woes on hyper-v gen 2

[Ady]

> Ady: You seem to be taking (copy$paste) parts and pieces from different resources.
> 
> Luke: Nope. The configuration works fine with PXE 2.01 clients, it's the UEFI PXE 3.2 that is having issues with the dhcp requests. The gospel is the Intel PXE 3 spec I'm RTFMing now. No copy and paste, I just started with someone elses configuration file that claims to support UEFI - or at least hopes to in the future.
> 
> Ady:You also seem to be assuming that all those resources are somewhat officially confirmed (proved) to be working, both individually and mixed together.
> Additionally, this email thread is getting slightly harder to read and to follow.
> As for the "arch 9 vs. arch 7" conflict, my comment was not in regard to the (conflicting) documentation. I mean it regarding your own conditional. You are starting with "if arch = 9" and then you react with a VCI stating that "arch = 7"; it doesn't make sense to me.
> 
> Luke: It's trivial Arch 9 isn't used here yet, it's a typo it only ever sent out the Arch 7 one. I am using wireshark to confirm what the DHCP is sending out and receiving in both cases. 
> The problem PXE-E99 is reported to be caused by MTFTP Failure (Dell our vendor & others) or Jumbo Frames on the Lan (IBM/Microsoft blogs). A different error usually reports incompatible DHCP options.
> 
> Ady: Regarding the "ISC DHCP 3.1" syntax, you "think" it works? 
> 
> Luke: I test the configuration works, and RTFM the Syslinux docs.  If it didn't work the dhcpd wouldn't start up.
> The configuration I inherited was less structured. I verify it works with a network analyser. DHCP requests are not that hard to read in wireshark now are they?
> DHCP Options should be defined in the global section, and used only in a class, scope,group.
> I am using site options for PXELinux (which work the default) and Vendor options for extra TFTPBoot options. The Vendor Class thing you took an issue with is to non-PXE devices that use DHCP option 43 to ignore the request. 
> 
> Ady: I would suggest simplifying your dhcp config and your network setup. 
> Once the basic UEFI case(s) are working, you could then add complexity.
> 
> Luke: Been there done that. I'm going to read the PXE 3.2 spec and work backwards and make fully compliant requests. Even your own website warns some legacy PXE 2.0 option roms don't like PXE requests that are not fully complaint  the specs, and are just using bootp style options (next server and filename + syslinux configuration).See the big long string of Vendor options required for some 2.0 PXE roms provided on Syslinux website and the html doc files:
> " DHCP Config - Encapsulated
>    option dhcp-class-identifier "PXEClient";
>    option vendor-encapsulated-options 09:0f:80:00:0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74:0a:07:00:50:72:6f:6d:70:74:06:01:02:08:03:80:00:00:47:04:80:00:00:00:ff;"
> 
> If the "conventional TFTP" configuration doesn't work on your clients, and setting up a PXE boot server is not an option, you can attempt the following configuration. It has been known to boot some configurations correctly; however, there are no guarantees:
> 
> I'll have to see if dhcp-isc can add the "ff" at the end of what I'm sending out as per the specs, or encode my own vendor options OR install an intel PXE sever.
> 
> Luke: I believe the path option you told me to use instead of configuration file is for the ROOT path or the path to APPEND to ALL filenames in Syslinux configuration files. This does not let you have a common configuration, but different root directories for EFI32,EFI64,Legacy BIOS pxe clients.
> I intend to use that to configure the root path later for use with lpxelinux.0 to be http://my.server.ip/tftpboot
> 
> Ady: I would also suggest searching for official documentation (e.g. about ISC DHCP 3.1 syntax, commands, config...), instead of almost-randomly copy&pasting from different resources that are not proven-to-work (specially when they are mixed altogether in a soup).
> 
> Luke: it makes perfect sense to me what it's all doing. I'm actually thinking that I might just bite the bullet and set up an intel PXE server instead of DHCP, but what I probably will do is emulate what works. See what options MS System Centre Configuration Manager is using with MTFTP turned off to make the DHCPD send the same responses.
> 
> Ady:Perhaps someone else in this Syslinux Mailing List might be so kind and post some dhcp config for UEFI clients that are known / proved to be working.
> 
> Luke: Yes, that's why I posted ;)
> The other issue here, if you read the link to the ibm document, is that you are going to need extra configuration when you don't have your tftpd on the same server as the pxe/dhcp server sending a bootfile - you may require extra configuration that I'm lacking. I'll try and set up a MTFTP server now just to prove a point that it can work if you specify where the MTFTP server is.
> 
> PXE 3.0 has a MTFTP discovery process built in that defaults to on that you may need to turn off. I'll set up a MTFTP atftpd server see if it appeases it. 
> Links:
> http://osdir.com/ml/network.dhcp.isc.dhcp-server/2003-01/msg00287.html
> Why use vendor class option: http://www.symantec.com/business/support/index?page=content&id=HOWTO7071
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg21247032
> Option 60 not set, option 43 not set didn't work - so I did try it simply first.
> 
> Will reverse engineer this: http://ccmexec.com/2013/05/configmgr-2012-uefi-and-pxe-boot-support/
> http://support.microsoft.com/kb/259670/en-us
> Microsoft says what breaks UEFI boot. Using bootfile name instaed  #67 - instead of filename in dhcpd.conf
> #60 = Client Identifier (set to "PXEClient") 
> #66 #67 = Boot Server Host/File Name
> https://jprudente.wordpress.com/2014/02/18/troubleshooting-pxe-booting/
> more on the above.
> 
> I'll update the list when I fixed it with the working configuration ok :)
> 

When I suggested to simplify the case, here is the basic idea...

You are used to have PXELINUX for BIOS clients only, with no UEFI, no 
different architectures/firmwares...

So, instead of having conditionals and what not, take a client that you 
fully know to boot in UEFI x86_64.

Check whether there is some firmware update (this is specially 
relevant, even if the firmware changelog doesn't mention NIC's or 
network changes).

Then check that the default boot priority of the UEFI x86_64 client is 
set to UEFI network boot; first and only boot priority, no second 
alternative ("NONE" or "DISABLED" or some equivalent). No "secure" 
anything, of course.

Prepare a network setup (including dhcp config) just for this UEFI 
client. No conditionals, no alternative options, no assumptions, no 
variations, no variables.

Once you get one (and only this one) UEFI(x86_64)-only setup working, 
only then add complexity, such as conditionals, multiple Architectures, 
Vendors and whatever else.

This approach is not the same as taking what others have (apparently, 
seemingly, but not proven nor officially) working, and it is not the 
same as adding (configs, conditionals, setups...) to a prior PXELINUX 
BIOS-only situation.

In spite the wording I just used, I am just humbly proposing such 
approach. I am not saying this is the way it should be, nor assuring 
that this will certainly work, nor claiming it is easy. I'm sure it is 
not.

If you find a way to make it all work, please post your results, so 
others can learn for future reference.

Thank you and Best Regards,  
Ady.