[syslinux] Hyper-V Gen 2 waiting for ldlinux.e64

[James Clements]

On Wed, Oct 07, 2015 at 07:21:28AM -0400, Gene Cumm via Syslinux wrote:
> On Wed, Oct 7, 2015 at 6:40 AM, Clements, James via Syslinux
> <syslinux at zytor.com> wrote:
> > Hi,
> >
> > I am using a Windows Server 2012 R2 Hyper-V Generation 2 VM as a
> > PXE client (no physical machines available). This is a UEFI VM, and
> > as per instructions I've read I have disabled secure boot on this
> > VM for the installation of Linux. I am using the latest tftp-hpa
> > package with the following config:
> >
> > # /etc/default/tftpd-hpa
> >
> > TFTP_USERNAME="tftp"
> > TFTP_DIRECTORY="/var/lib/tftpboot"
> > TFTP_ADDRESS="[::]:69"
> > TFTP_OPTIONS="--secure --verbose"
> >
> > I was using the latest version of syslinux from here:
> > https://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.03.tar.gz
> > I then started testing with this version of syslinux: https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/syslinux-6.03-pre6.tar.gz
> 
> 6.03-pre6 is older than 6.03.  Numerous UEFI PXE issues should be
> addressed in my personal build.
> 
> > I had read in some archives that my issue was resolved for users
> > of the 6.03-pre6 version of syslinux but testing with this version
> > reveals the same issue for me.
> >
> > The problem I am experiencing is that when I attempt to PXE boot
> > my Hyper-V VM client, I can see it requesting the syslinux.efi
> > file from the tftp server. The initial request has options for
> > both tsize and blksize included, and the response packets from the
> > tftp server include both options as well. It appears as though the
> > file doesn't actually get transferred until a later packet request
> > (this time with only one option of blksize included) gets sent
> > from my VM client to my tftp server. When it does, I can see an
> > acknowledgement from my tftp server (with only the blksize option
> > this time) and the file transfer for syslinux.efi begins. I can see
> > that my VM client receives the file and is aware of its size. Once
> > this file is received, my VM client then requests ldlinux.e64 from
> > my tftp server. This request for ldlinux.e64 again has options for
> > both tsize and blksize included, and the response packets from the
> > tftp server include both options as well. At this stage, unlike wh!
>  en!
> >   syslinux.efi was requested, a second request (that includes only
> >   the blksize option) is never sent and thus ldlinux.e64 is never
> >   actually transferred. At this point the VM client just sits,
> >   waiting at the UEFI screen.
> >
> > I have tried this with both the syslinux-6.03.tar.gz and
> > syslinux-6.03-pre6.tar.gz syslinux releases. I have also modified
> > my tftp-hpa configuration to refuse tsize, blksize and both options
> > together. But I have not had any success in getting UEFI clients
> > to boot.
> >
> > I have a packet capture here (please excuse the 'noise') which
> > demonstrates the problem I am seeing here:
> >
> > https://dl.dropboxusercontent.com/u/102712992/capture.pcap
> 
> http://www.syslinux.org/archives/2015-October/024375.html
> 
> git://github.com/geneC/syslinux.git
> https://github.com/geneC/syslinux.git
> 
> Branch 1efipxe
> 
> 
> https://sites.google.com/site/genecsyslinux/sl604p0g18-x64.tgz?attredirects=0&d=1
> https://sites.google.com/site/genecsyslinux/sl604p0g18-bios.tgz?attredirects=0&d=1
> 
> Please try these binaries.  Thanks in advance.
> 

                                                                                                                       
Hi Gene,

Thanks for the quick reply. I have just tested the binaries from
sl604p0g18-x64.tgz and still have the same   issue. Here is another
capture using the new binaries, although to be honest the ldlinux.e64
behaviour looks much like the first:
                                                                                                                       
https://dl.dropboxusercontent.com/u/102712992/capture2.pcap                                                            
                                                                                                                       
Thanks,                                                                                                                
                                                                                                                       
James