[syslinux] Updated status on UEFI compliant version of the pxechn-module

Jan Frode Jæger jan.frode.jaeger at ntnu.no
Tue Mar 15 23:58:41 PDT 2016


Hi,
________________________________________
From: Gene Cumm <gene.cumm at gmail.com>
Sent: Wednesday, March 16, 2016 00:56
To: Jan Frode Jæger
Cc: syslinux at zytor.com
Subject: Re: [syslinux] Updated status on UEFI compliant version of the pxechn-module

On Tue, Mar 15, 2016 at 9:32 AM, Jan Frode Jæger
<jan.frode.jaeger at ntnu.no> wrote:

Without trying to figure out where data is stored or the possibility
of calls to manipulate the data, I can't speak for the possibility of
implementing anything that manipulates the options like pxechn.c32 for
UEFI.  I'd like to get UEFI chaining working first.

The shear length comparison speaks a lot for the differences.  Yes,
I've read through most of the PXE spec as it relates to the boot
process.  As bad as you think PXE is, consider how UEFI has been a
moving target in some respects.

What do you expect to PXE chainload?  If you could provide details on
what you hope to achieve, someone might be able to offer a suggestion
or workaround.

I understand. Just let me say that I appreciate all the work that has been done on syslinux and that it is a great tool. I was only wanting to hear what your plans were.

As goes the PXE chainloading - I am trying to redirect from a PXELINUX menu to a WDS boot server with SCCM. So the option in my menu looks like this:

***SNIP***
label sccmserver
   menu label SCCM-server
   kernel /mods/pxechn.c32
   append 1.2.3.4::boot\x86\wdsnbp.com
***SNIP***

The IP here is of course just changed for this example. I have also tried to add the "-W" parameter to pxechn, but without any change in result. It always says "Error: Unable to retrieve first packet" and then "Could not unpack packet". 

> I just compiled up the 6.04-prerelease and can see that the pxechn-module has been removed from the two efi-trees. As a sidenote: the NEWS-file in the 6.04-prerelease is missing information about changes introduced in it (seems to be the file from 6.03).

NEWS has NOT been updated yet.

> As another sidenote and possible separate thread: since I couldn't get UEFI to boot pxelinux 6.03 properly before I saw your dhcp options fix (vendor encapsulated options), I implemented a simple PXE boot server ack-packet UDP server in perl (the PXE client basically tries to perform a PXE boot server discovery procedure). Works like a charm without the dhcp options under all the Intel Boot Agent versions I tried - only need to set the mtftp-server address as per recommendations in the PXE 2.1 spec. Is there any interest in me publishing this boot server ack-packet script for others to use? Microsoft and others want us to drop DHCP options and instead implement iphelpers in the router (if clients and servers are on separate subnets), but shouldn't be necessary as far as I can see. The origin of all this mess is again the PXE specification in my opinion...

Intel Boot Agent?  Really?  I've NEVER seen mention of "Intel Boot
Agent" on UEFI.

I'd certainly be interested in this Perl script.

Sorry, misspeak - I have been working on this issue for an intensive period.... Of course the Intel Boot Agent (IBA) is under BIOS. Under UEFI PXE-boot I developed the aforementioned boot server script to deal with the boot server discovery being attempted by the UEFI PXE agent. It is based on some tcpdumps of the network traffic between the tftp-server and an ack-packet from a WDS boot server. Stripped away the proprietary dhcp options from the WDS boot server though and used the definiton of an ack-packet in the PXE 2.1 specification as soon as I understood what was going on. It is a very rudimentary script and was only made to see if I could get the UEFI client to accept my Linux tftp-server and its image-file (which was the syslinux.efi file for efi64 from version 6.03). How do you want the script - send it to your private email address?

Best,

    Jan-Frode

--
-Gene

> ________________________________________
> From: Gene Cumm <gene.cumm at gmail.com>
> Sent: Tuesday, March 15, 2016 13:42
> To: Jan Frode Jæger
> Cc: syslinux at zytor.com
> Subject: Re: [syslinux] Updated status on UEFI compliant version of the pxechn-module
>
> On Tue, Mar 15, 2016 at 3:51 AM, Jan Frode Jæger <syslinux at zytor.com> wrote:
>> Hi,
>>
>>
>> I have browsed through your syslinux archives and see that the issue of an UEFI compliant version of the pxechn-module has come up several times:
>>
>>
>> http://www.syslinux.org/archives/2014-August/022611.html
>>
>> http://www.syslinux.org/archives/2015-March/023320.html
>>
>> http://www.syslinux.org/archives/2015-September/024231.html
>>
>>
>> Now the issue as I understand it is that the original pxechn-module has been written to interface with legacy BIOS and not UEFI. It also seems that Patricks update as of March 2015 gave positive indications that a general fix for com32-modules were possible.
>>
>>
>> It would have been nice to receive some update on both com32-module compliance for the UEFI architecture as well as for the pxechn-module in specific. We have a setup at my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot.
>>
>>
>> Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)?
>
> No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32.
>
> More importantly, Syslinux can't load arbitrary UEFI images yet.
>
> --
> -Gene



More information about the Syslinux mailing list