UEFI 10G Intel X710/XL710 Hang Windows Splash Screen

[renato]

(2016-11-07 21:38)NiKiZe Wrote:  Could you try a a packet dump on the interface and see if there is anything weird/re-transmissions going on.

One think I can think of is that when using the TCP stream (such as http) instead of UDP (in tftp) then it can't close the connection directly after completed transfer and something goes wrong.

What if you add pause as an option to wimboot.
or maybe using ifclose before boot does it make any difference?

It booted with ifclose followed by dhcp. Thank you, Is this a iPXE bug? is there anything I can do to test/debug?

---

(2016-11-15 21:57)jrrowan Wrote:  I am having a very similar issue but my scenario fails about 80% of the time with one WinPE error or another. In my case a pause does not help.

Is there suggested workaround. Should I use TFTP or chain load bootx64.efi? If the later, could someone describe how to do it?

you could do it for testing or if you want to check if it is the same problem I am having. You could also try the solution directly just add ifclose, dhcp. That worked for me.

Code:

#!ipxe
kernel wimboot
initrd boot/bcd         BCD
initrd boot/boot.sdi    boot.sdi
initrd sources/boot.wim boot.wim
ifclose
dhcp
boot

here are some instructions to boot winpe over ipxe
http://ipxe.org/howto/winpe
http://ipxe.org/wimboot

just when chaining your menu
use for tftp

Code:

chain menu

use for http

Code:

chain http://boot.ipxe.org/menu

you can also set bootmgfw.efi as the dhcpd filename (for UEFI) to bypass ipxe. However, beware that there are some character remapping you would need to do in order for it to work if you are using linux (xinet), I did that a couple years ago, I don't know if that still holds true. You can use tftpd32 for testing. just google it, there is plenty of information.

in my case ifclose/dhcp worked.

---

(2016-11-16 22:32)jrrowan Wrote:  I noticed that I am getting this error message. The WIM is created from Windows ADK.

...found WIM file boot.wim
Can't handle unknown compression scheme 0x00020082 for <address> chunk 0...

please check http://forum.ipxe.org/showthread.php?tid=7987