> I use Syslinux 6.03 EFI64 on a VMware Workstation 10 VM on > 10.0.2 on Linux. >w/o any problem? >> correctly sends back w/o error the "corresponding" syslinux.efi >> "EFI BC" -> EFI64\syslinux.efi >> "EFI IA32"-> EFI32\syslinux.efi>I only send back 1 filename. >Me too, I just send the ""corresponding"" syslinux.efi >My VMs always request files.? I created a VMHW v10 VM >then added: >? firmware = "efi" >to the VMX and had no issues.> Are they actually transferring the syslinux.efi files?? >sure> What values are present in DHCP options 60 and 93?? I've found > feeding EFI32 binaries to my VMs results in hangs/failures. >This is perfect, both option provide the right info. if I replace syslinux.efi with MS bootmgfw.efi then the Microsoft boot manager perfectly boots it retrieves the BCD etc. etc that tells me it is not a VMware problem. >> any idea?> 6.03 as in the precompiled binaries.?That's what I use>I've successfully built EFI binaries on Debian 7 and built failing >EFI binaries on Ubuntu 12.04 (I suspect due to gcc 4.7 versus 4.6). >I also built EFI binaries with Ubuntu 14.04 (gcc 4.6.3) and failing "exactly in the same way"... Then the only way to build syslinux is using gcc 4.7 with debian 7? thanks Pat >? *** > FWIW, I still cannot reply to emails sent to the Mailing List when the > original sender comes from yahoo (the whole dmarc issue). I am manually > circumventing the problem this time, but I wish subscribers would > consider not using yahoo email addresses for this Mailing List. >? *** > > > In some cases, when the adequate ldlinux.{c32,e32,e64} is not found, > the behavior might seem as if there is no additional (re)action (i.e. a > "real failure" would look very similar). > > So the first natural question would be, where are your > ldlinux.{e32,e64} located, in relation to your EFI{32,64}/syslinux.efi > files? > > You mentioned "EFI BC" (architecture type 07). Have you tried with EFI > x64, architecture type 09? in option 93, type 0x07 is actually used for EFI64 VMs that I've seen? > Have you tried testing only one architecture at a time, without mixing > EFI IA32 with EFI x64? I mean, not mixing (and not conditioning) them > in config files nor in the actual Syslinux-related files in the server; > testing isolated configs and files for EFI IA32 _only_ and then > isolated configs and files for EFI x64 _only_. > > Perhaps you could post your TFTP/DHCP/whatever configuration files? > > Is there some setting in the VMWare products to configure which exact > type of firmware (BIOS / EFI IA32 / EFI x64) is being used/expected by > the VM? And how are you switching between EFI IA32 and EFI x64? > A packet capture might be helpful. > > I assume we are talking about Syslinux 6.03 official upstream binary > files, downloaded from kernel.org (as oppose to some package or > rebuild). -- -Gene
On Sat, Jan 10, 2015 at 5:44 AM, Patrick Masotta <masottaus at yahoo.com> wrote:>> I use Syslinux 6.03 EFI64 on a VMware Workstation 10 VM on >> 10.0.2 on Linux. >> > w/o any problem?Yes.> Me too, I just send the ""corresponding"" syslinux.efi>> Are they actually transferring the syslinux.efi files? > > sure > >> What values are present in DHCP options 60 and 93? I've found >> feeding EFI32 binaries to my VMs results in hangs/failures. > > This is perfect, both option provide the right info. if I replace > syslinux.efi with MS bootmgfw.efi then the Microsoft boot manager > perfectly boots it retrieves the BCD etc. etc that tells me > it is not a VMware problem.First, I was looking for the actual values. For a VM with (among other values): config.version = "8" virtualHW.version = "10" ethernet0.virtualDev = "e1000" guestOS = "rhel6-64" firmware = "efi" I see: option-93 = 0x07 option-60 = "PXEClient:Arch:00007:UNDI:003016" and present it efi64/efi/syslinux.efi and it boots. I also only have 1 NIC in this VM. This level of detail is what it takes for someone else to reproduce your issue. Second, don't eliminate but merely discount the probability a "working" system as the source of the issue. I've seen people try to use "perfectly working" desktops/laptops with VMware Player/Workstation and ESXi only to see the system fail miserably due to extremely minor hardware faults.> >> any idea? > >> 6.03 as in the precompiled binaries. > That's what I use >>I've successfully built EFI binaries on Debian 7 and built failing >>EFI binaries on Ubuntu 12.04 (I suspect due to gcc 4.7 versus 4.6). >> > I also built EFI binaries with Ubuntu 14.04 (gcc 4.6.3) and failing "exactly in the same way"... > Then the only way to build syslinux is using gcc 4.7 with debian 7?No, I'm stating that binaries built with gcc-4.6 will likely fail and that gcc-4.7+ is likely needed. One example of a system is a build VM I have with Debian-7 that I use to build some of my test binaries.> > Is there some setting in the VMWare products to > configure which exact > > type of firmware (BIOS / EFI IA32 / EFI x64) is being > used/expected by > > the VM? > > And how are you switching between EFI IA32 and EFI x64?> Bios vs EFI is done adding a switch to the VM conf file > EFI IA32 v EFI x64 is automatically set by VMware considering the VM's target OS architectureThanks for the info! The VMX guestOS setting is really a hint to the platform indicating what you expect to use (hence the term "guestOS hint").> > A packet capture might be helpful.> You will only see how a perfect TFTP transfer delivers syslinux.efi. That's it.> > I assume we are talking about Syslinux 6.03 official > upstream binary > > files, downloaded from kernel.org (as oppose to some > package or > > rebuild).> 6.03 official binaries...As in extract binary/source archive and copy (without running make)? OK, that's good. -- -Gene
>First, I was looking for the actual values.? >For a VM with (among other values):> config.version = "8" > virtualHW.version = "10" > ethernet0.virtualDev = "e1000" > guestOS = "rhel6-64" > firmware = "efi"> I see:> option-93 = 0x07 > option-60 ="PXEClient:Arch:00007:UNDI:003016"OK I take binaries (w/o recompiling) from https://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.03.zip\efi32\efi\syslinux.efi config.version = "8" virtualHW.version = "9" ethernet0.virtualDev = "e1000e" guestOS = "windows8" firmware = "efi" option-93 = Client System Architecture: EFI IA32 (6) option-60 =Vendor class identifier: "PXEClient:Arch:00006:UNDI:003016" I've performed a deeper analysis and this is what's going on. The client get's its IP from VMware DHCP server, the ACK includes NextServer=192.168.62.254 (the DHCP Server IP) The client gets PXE parameters from a proxyDHCP NextServer=192.168.62.1 (the PXE Server IP) While the NBP syslinux.efi is correctly retrieved considering the PXE parameters given by the proxyDHCP (192.168.62.1) the TFTP request of the file ldlinux.e32 is performed with the data included in the DHCP answer (192.168.62.254) instead. That's why the PXE server never receives the ldlinux.e32 TFTP request. Also I see ldlinux.e32 is requested plain, w/o any path component. I think this is a bug in syslinux.efi retrieving its components w/o considering proxyDHCP scenarios. If using the same DHP+proxyDHCP scenario I boot MS bootmgfw.efi the MS boot manager correctly detects who is the real PXE server and conducts its further TFTP requests correctly.> No, I'm stating that binaries built with > gcc-4.6 will likely fail and > that gcc-4.7+ > is likely needed.? One example of a system is a build VM > I have with Debian-7 that I use to build some > of my test binaries.What OS is used by syslinux maintainers??? Best, Patrick