iPXE discussion forum

Full Version: wimboot MDT generated WinPE 5 with wimboot
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi everyone,

I'm using Microsoft Deployment Toolkit (MDT) to generate Litetouch wim files. I utilize wimboot for PXE purposes. This all worked great until the latest version came out. MDT 2013 create WinPE 5 wim files based on Windows 8.1. The first problem is the decompression of bootmgr. That I've fixed by replacing it with an extracted version as per the instructions on the FAQ page. It now tries to boot into the wim file but that results in a BSOD with the error: A required device isn't connected or can't be accessed (0xc000000f).

The funny thing is that MDT also creates an ISO using the same wim file and bootfiles that I used for wimboot and when I use memdisk to boot the ISO all works fine.

Thoughts anyone?
Hmm. This is odd. You're saying memdisk works, but wimboot doesn't. Have you tried to sanboot the ISO (just like memdisk does). That should also work, as it is more or less the same as memdisk, but the entire ISO isn't loaded into memory at once, it is loaded as it is requested.

The error message does seem to indicate that the PE wants to read something else from the ISO outside the .wim file. If that is the case, you _might_ be able to trick it by adding additional lines in your wimboot ipxe script to load those files into the emulated fat drive wimboot creates. That is highly untested territory, though, so it might fail miserably. Also try to enable boot logging during WinPE startup, to see where it hangs.
(2014-01-20 08:46)robinsmidsrod Wrote: [ -> ]Hmm. This is odd. You're saying memdisk works, but wimboot doesn't. Have you tried to sanboot the ISO (just like memdisk does). That should also work, as it is more or less the same as memdisk, but the entire ISO isn't loaded into memory at once, it is loaded as it is requested.

Hi Robin,

I tried sanbooting the ISO and it works. However it's very slow so I get to stare at the blue Windows logo for a long time without any progress indication. This makes it look like it's hanging. Wimboot is also slow on our iPXE server. I can't explain it. The wim takes about 2 minutes to load instead of the usual 3 seconds! Once the PE has booted up it deploys a 4 GB Windows OS in roughly 4 minutes, so it's not the network connection that's slow. The iPXE server was setup by a colleague of mine but he can't find the cause either. Do you have any thoughts on this, or should I open a new thread for that?
Quote: it's very slow so I get to stare at the blue Windows logo for a long time without any progress indication. This makes it look like it's hanging. Wimboot is also slow on our iPXE server. I can't explain it. The wim takes about 2 minutes to load instead of the usual 3 seconds! Once the PE has booted up it deploys a 4 GB Windows OS in roughly 4 minutes, so it's not the network connection that's slow. The iPXE server was setup by a colleague of mine but he can't find the cause either. Do you have any thoughts on this, or should I open a new thread for that?

Would this be Physical or Virtual?
(2014-01-20 23:09)MultimediaMan Wrote: [ -> ]Would this be Physical or Virtual?

It's a VMware vSphere 5 VM.
(2014-01-20 23:34)MicaH_Z Wrote: [ -> ]
(2014-01-20 23:09)MultimediaMan Wrote: [ -> ]Would this be Physical or Virtual?

It's a VMware vSphere 5 VM.

What kind of vNIC for the VM?
(2014-01-21 21:32)MultimediaMan Wrote: [ -> ]What kind of vNIC for the VM?

VMXNET 3
(2014-01-22 11:19)MicaH_Z Wrote: [ -> ]
(2014-01-21 21:32)MultimediaMan Wrote: [ -> ]What kind of vNIC for the VM?

VMXNET 3

Can you try it with the E1000?

I'm pretty sure this is a bug in the VMware VMXNET3 driver (not sure which one). I'm not sure where the bug is, however. If you look at packet traces of conversations with various iPXE kernels you will see that the MTU changes when unidonly switches to the Native Kernel (if you chain the native) and changes again when the PE Kernel starts.

IMHO, it's almost as if the WinPE kernel is specifying a default MTU which is more geared for TFTP.
(2014-01-22 11:57)MultimediaMan Wrote: [ -> ]Can you try it with the E1000?

I'm pretty sure this is a bug in the VMware VMXNET3 driver (not sure which one).

I asked around. My colleague who created the iPXE server set it to VMXNET3 a week ago to check if that would solve the slow wimboot. The VM had an E1000 card before that and it was equally slow, I'm afraid. Thank you for your input though, it's appreciated. Anything else you can think of? It's driving me crazy.
Is the client machine a VM, and is it using the E1000 or VMXNET3? This is where I saw the problem.
(2014-01-24 11:00)MultimediaMan Wrote: [ -> ]Is the client machine a VM, and is it using the E1000 or VMXNET3? This is where I saw the problem.

The client machines we use are VM's as well as HP servers. Both are equally slow. There's not much difference between a vm with e1000 or VMXNET3. Both take a long time to load.
What is your webserver application? Apache, IIS, or other?
(2014-01-24 11:09)MultimediaMan Wrote: [ -> ]What is your webserver application? Apache, IIS, or other?

It's Apache.
Reference URL's