@Wayne-Workman Thanks Wayne.
Switching the path to i386-7156-efi/ipxe.efi or snponly.efi did not make a difference in the behavior.
Understanding the way it decides to send the 32bit or 64bit boot files did help though. It continued to send the 64 bit files, which led to the chainloading failure. However, from within the ipxe shell, I manually loaded the bzImage32 and init_32.xz files and was able to get it to boot.
(I used this command from the ipxe shell:)
kernel http://[FOGServer]/fog/service/ipxe/bzImage32 loglevel=4 initrd=http://[FOGServer]/fog/service/ipxe/init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=[FOGServer]/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch http://[FOGServer]/fog/service/ipxe/init_32.xz
Following this, I specified the Host Kernel and Host Init options for that Host’s config, and I’ve now been able to start capturing an image.
I think it boils down to the cpuid command, ultimately. This tablet is a Dell Venue 11 5130 (32bit), but has a 64bit processor. So only the 32bit boot files work, but cpuid determines its an x86_64 processor and loads the 64bit bzImage and init.xz.
Since this is clearly an exception to the norm, I’m not too worried about it.
However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?
