Syslinux - Mar 2016 - Updated status on UEFI compliant version of the pxechn-module

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?)?


Best regards,


   Jan-Frode

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

Hi,

Ok, when can we then anticipate pxe-chaining to be possible with syslinux under
the UEFI architecture? Are there any plans to implement both correct interfacing
to UEFI as well as the issue of arbitrary UEFI images? Haven't tried to read
the UEFI-specification as it is sub 3000-pages long, so I am a bit in the dark
as to the changes in architecture from BIOS to UEFI. It has been "fun"
enough to read the PXE 2.1-specification and see how it manifests its horror in
actual PXE ROM implementations and its impact on the PXE boot-process on various
hardware (Microsoft and others blame unworking features of the DHCP options, but
in actuality the fault seems to lie the rather vague specification of PXE 2.1 as
far as I can see).

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).

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...

   Jan-Frode

________________________________________
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