[syslinux] pxelinux.0 not fully booting in EFI 64 mode...not requesting ldlinux.e64 via TFTP...

[Don Cupp]

Spike,

There are multiple binaries that come with syslinux. I would highly recommend that you start with the official syslinux pre-built's of pre-7 on kernel.org. You will find inside an syslinux.efi in a 64 bit folder and one in an 32 bit folder.
These are the files that you need to point your clients to for efi booting. pxelinux.0 is for bios booting only.



On Sunday, March 9, 2014 4:07 PM, Spike White <spikewhitetx at gmail.com> wrote:
  
All,

I was excited to hear about EFI boot support in pxelinux >= 6.00.  So I
tried it.  Not working.  I've tried 6.02 (from source), 6.02 (from RPM),
early 6.03 (from RPM) and even pulled/compiled latest source from git.
6.0.3-pre7.  No love.

My boot client can boot/image fine in legacy PXE mode.   My dhcpd.conf
looks like this:

# In initial DHCP DISCOVER packet, PXE client sets option 93 to its arch.
#    0000 == IA x86 PC (BIOS boot)
#    0006 == x86 EFI boot
#    0007 == x64 EFI boot
option arch code 93 = unsigned integer 16;

...
     #if option vendor-class-identifier =
"PXEClient:Arch:00000:UNDI:002001" {
     if option arch = 00:00 {
       filename "bios/pxelinux.cfg/pxelinux.0";

       # option 67. A string. full path to NBP.
       option bootfile-name "bios/pxelinux.cfg/pxelinux.0";

     #} elsif  option vendor-class-identifier =
"PXEClient:Arch:0007:UNDI:003016" {
     } elsif  option arch = 00:06 {

       filename "efi.x86/pxelinux.cfg/pxelinux.0";

        # option 67. A string. full path to NBP.
        option bootfile-name "efi.x86/pxelinux.cfg/pxelinux.0";

     } elsif  option arch = 00:07 {

        #filename "efi.x64/pxelinux.cfg/bootx64.efi";
        filename "efi.x64/pxelinux.cfg/pxelinux.0";

        # option 67. A string. full path to NBP.
        #
        # PROBLEM! w/ Intel NIC's boot UEFI code.  I've seen this before, on
        # RealTek NIC's legacy PXE boots.
        #
        # Intel UEFI PXE boot agent gets confused by this string, even
though
        # it's FF-terminated. Per RFC.  So it thinks it's pxelinux.0\377 !
(where
        # \377 is the FF).
        #
        #option bootfile-name "efi.x64/pxelinux.cfg/pxelinux.0";

     } else {
       filename "UNKNOWN_VCI";
       option bootfile-name "UNKNOWN_VCI";
     }

in legacy PXE mode, wireshark confirms it  successfully TFTPs
bios/pxelinux.cfg/pxelinux.0, followed by (in order, all from
bios/pxelinux.cfg/ dir):
    ldlinux.c32
    <tries other config files>
    pxelinux.cfg/default
    vesamenu.c32  (referenced by pxelinux.cfg/default)
    libcom32.c32
    libutil.c32

In EFI PXE mode, wireshark confirms it TFTPs
efi.x64/pxelinux.cfg/pxelinux.0  (which is a symlink to
bios/pxelinux.cfg/pxelinux.0).

Next, it should attempt to TFTP over efi.x64/pxelinux.cfg/ldlinux.e64.  But
it never even requests that.  Instead, there's some error message on the
screen (can't read it, EFI shell messages immediately refresh screen).

I'm able to read on the EFI boot client's console:

   Check for media present...
   Media detected...
   Downloading ????
   ??????

I'm able to EFI PXE boot if I specify
   filename "efi.x64/pxelinux.cfg/bootx64.efi";

in my dhcpd.conf file and set up a GRUB2-compatible efidefault file.

But I'm not really interested in GRUB2!!  I prefer the richer syntax of the
SYSLINUX-based menuing system.

What could be wrong?  Oh, I've also tried lpxelinux.0 and gpxelinux.0.  EFI
boot client has Intel NIC, very new notebook.

Spike
PS As far as using an "arch-007" config file vs  a dhcpd.conf file that
specifies different boot trees per ARCH -- I'm flexible.  I do not manage
the DHCP servers at work, but I have input into their PXE settings, for our
VLANs.  And I have total control of the TFTP image servers.

Either approach works.  It's good to have both choices, for orgs with other
spans of control.
_______________________________________________
Syslinux mailing list
Submissions to Syslinux at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.