Syslinux - Mar 2015 - Problems PXE booting syslinux.efi on HP EliteBook 2560p / 8460p

>_ There
>have been some patches already merged after 6.03. 
>Unfortunately, currently there is no _official_
>git repository *publicly* available /
> accessible that would contain such patches.
>
So bad; Any chance to get access to an updated git repository?
it takes long time debugging this kind of things. 
> _ The official Syslinux 6.03 uses a one-year-old (ATM) gnu-efi
>code. Updating the gnu-efi submodule to current latest gnu-efi 
>commit (2015Feb) might influence the results.
>
I really doubt it; the LibLocateHandle() answer is consistent with a 
missing Service Binding protocol, something that can be seen if the 
NIC EFI driver is not correctly implemented, but despite all this I'll 
give it a try.
 
>_ If similar newer HW can boot correctly,
>perhaps requesting from HP to 
>release updated firmware versions for those systems that 
>are failing might help?
>
I think we are aiming in the right direction here,
unfortunately HP (and other vendors) only update firmware bugs 
when either heavily impacting functionality or security.

>_ I guess that pcap reports might help for
>additional debugging (whether to find a
>workaround or to find a potential bug in Syslinux)?
>
In my case there is not a relevant pcap file;
syslinux.efi gets perfectly transferred and when it tries to get 
ldlinux.e64 it fails locating the Binding Service for UDP4, before 
aborting w/o generating any additional traffic.
>_ I am guessing that these
>systems are actually using UEFI x86_64. If 
>they are not, then this would be a potential reason for strange 
>behaviors regarding syslinux.efi and ldlinux.e64.
>
All my tests were conducted on 64 bit HP hardware using UEFI x86_64 firmware.

Best,
Patrick

>  
> >_ If similar newer HW can boot correctly,
> >perhaps requesting from HP to 
> >release updated firmware versions for those systems that 
> >are failing might help?
> >
> I think we are aiming in the right direction here,
> unfortunately HP (and other vendors) only update firmware bugs 
> when either heavily impacting functionality or security.
 
Not being able to boot should probably qualify as good reason for HP to 
update the firmware, IMHO.

To be clear, I am not discarding the possibility of a bug in Syslinux. 
Perhaps the specific HW and the specific firmware version is just 
triggering a bug in Syslinux, instead of suggesting a bug in the 
firmware version.

FWIW, the following statement can be found in HP's website with regards 
to some newer firmware version for some HP HW:

- Fixes an intermittent issue where a system with the LAN/WLAN 
switching feature enabled in the F10 BIOS menu stops functioning 
properly (hangs) at POST after a warm boot. 

Is it possible that the reported network boot behavior is different 
between cold-boot and warm-boot?

At any rate, and considering several reports about different HP 
hardware failing to boot syslinux.efi, I would tend to think that 
contacting HP and requesting an updated firmware release could be 
helpful.

FWIW, there are (recent) patches in gnu-efi that were originated by 
developers somewhat related to (or working for) HP. This might be 
another hint to both, using an updated gnu-efi submodule and/or needing 
an updated firmware from HP for these failing systems.
 
> 
> 
> >_ I guess that pcap reports might help for
> >additional debugging (whether to find a
> >workaround or to find a potential bug in Syslinux)?
> >
> In my case there is not a relevant pcap file;
> syslinux.efi gets perfectly transferred and when it tries to get 
> ldlinux.e64 it fails locating the Binding Service for UDP4, before 
> aborting w/o generating any additional traffic.
> 
 
Let's see what kind of info or tests the Syslinux's devs. would need 
for troubleshooting the particular hardware.
 
> >_ I am guessing that these
> >systems are actually using UEFI x86_64. If 
> >they are not, then this would be a potential reason for strange 
> >behaviors regarding syslinux.efi and ldlinux.e64.
> >
> All my tests were conducted on 64 bit HP hardware using UEFI x86_64
firmware.
 
I would guess that CSM mode is actually verified to be set to "off" 
(i.e. UEFI mode), among others ("secure boot", "fast boot",
"whichever
fancy name" boot...). Sometimes some minor setting that was overlooked 
can be the cause of wasting hours of troubleshooting.
 
> 
> Best,
> Patrick
 
 
Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

>  
> >_ If similar newer HW can boot correctly,
> >perhaps requesting from HP to 
> >release updated firmware versions for those systems that 
> >are failing might help?
> >
> I think we are aiming in the right direction here,
> unfortunately HP (and other vendors) only update firmware bugs 
> when either heavily impacting functionality or security.
 
Not being able to boot should probably qualify as good reason for HP to 
update the firmware, IMHO.

To be clear, I am not discarding the possibility of a bug in Syslinux. 
Perhaps the specific HW and the specific firmware version is just 
triggering a bug in Syslinux, instead of suggesting a bug in the 
firmware version.

FWIW, the following statement can be found in HP's website with regards 
to some newer firmware version for some HP HW:

- Fixes an intermittent issue where a system with the LAN/WLAN 
switching feature enabled in the F10 BIOS menu stops functioning 
properly (hangs) at POST after a warm boot. 

Is it possible that the reported network boot behavior is different 
between cold-boot and warm-boot?

At any rate, and considering several reports about different HP 
hardware failing to boot syslinux.efi, I would tend to think that 
contacting HP and requesting an updated firmware release could be 
helpful.

FWIW, there are (recent) patches in gnu-efi that were originated by 
developers somewhat related to (or working for) HP. This might be 
another hint to both, using an updated gnu-efi submodule and/or needing 
an updated firmware from HP for these failing systems.
 
> 
> 
> >_ I guess that pcap reports might help for
> >additional debugging (whether to find a
> >workaround or to find a potential bug in Syslinux)?
> >
> In my case there is not a relevant pcap file;
> syslinux.efi gets perfectly transferred and when it tries to get 
> ldlinux.e64 it fails locating the Binding Service for UDP4, before 
> aborting w/o generating any additional traffic.
> 
 
Let's see what kind of info or tests the Syslinux's devs. would need 
for troubleshooting the particular hardware.
 
> >_ I am guessing that these
> >systems are actually using UEFI x86_64. If 
> >they are not, then this would be a potential reason for strange 
> >behaviors regarding syslinux.efi and ldlinux.e64.
> >
> All my tests were conducted on 64 bit HP hardware using UEFI x86_64
firmware.
 
I would guess that CSM mode is actually verified to be set to "off" 
(i.e. UEFI mode), among others ("secure boot", "fast boot",
"whichever
fancy name" boot...). Sometimes some minor setting that was overlooked 
can be the cause of wasting hours of troubleshooting.
 
> 
> Best,
> Patrick
 
 
Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

> Not being able to boot should probably qualify
> as good reason for HP to  update the
> firmware, IMHO.
>
I agree but considering the problem appears when 
PXE booting an EFI image requiring the Binding Services
of the NIC well I'm not really sure if they would pay any attention.
BTW the same failing hardware has not problem booting
MS bootmgr.efi but analyzing its code I see bootmgr.efi
performs the TFTP transfers not relying on Binding Services
(probably using some PXE TFTP service)
 
> Is it
> possible that the reported network boot behavior is
> different between cold-boot and warm-boot?
>
Exactly the same behavior.
Please consider the environment never crashes,
syslinux.efi just bails because it cannot continue w/o the Binding Services, 
it properly returns control to HP firmware which displays a proper message 
of a failing booting image.

> At any rate, and
> considering several reports about different HP 
> hardware failing to boot syslinux.efi, I would
> tend to think that contacting HP and
> requesting an updated firmware release could be 
> helpful.
>
I agree that this looks like an HP problem.
I'm holding my doubts on HP willingness to fix this.
 
> FWIW,
> there are (recent) patches in gnu-efi that were originated
> by developers somewhat related to (or
> working for) HP. This might be another hint
> to both, using an updated gnu-efi submodule and/or needing
> an updated firmware from HP for these failing systems.
>
I'm going to take a look at this point
 
> Let's see what kind of info or tests the
> Syslinux's devs. would need for
> troubleshooting the particular hardware.
>
Trust me; in this case they won't need pcap files.
  
> I would
> guess that CSM mode is actually verified to be set to
> "off" 
> (i.e. UEFI mode), among
> others ("secure boot", "fast boot",
> "whichever 
> fancy name" boot...).
> Sometimes some minor setting that was overlooked 
> can be the cause of wasting hours of
> troubleshooting.
>
I'm booting "plain and simple" UEFI mode
  
Best,
Patrick