Unable load winpe.iso

[Quazz]

@zingaro

kernel ${macrium-url}/wimboot
initrd ${macrium-url}/bootmgr bootmgr
initrd ${macrium-url}/Boot/BCD BCD
initrd ${macrium-url}/Boot/boot.sdi boot.sdi
initrd ${macrium-url}/sources/boot.wim boot.wim

as example.

Wimboot requires you to indicate which file is which, capitalization is important for the alias.

[george1421]

@george1421 The instructions are for pxe booting the MDT wim file, but also applies to any generic wim file.

When I say the alias I’m referring to these in the parameters section.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot

Specifically the line
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD

Notice that after the file to load there is BCD in upper case characters. Those are the alias values I’m talking about.

[Tom Elliott]

@george1421 I feel I should point out the boot.wim line has the -n boot.wim portion as well. This tells it the name.

Does this work?

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd -n BCD http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd -n boot.sdi http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot

[george1421]

@tom-elliott Let me confirm. I should have worked, or I wouldn’t have documented it in 2015

It may take me a bit to setup that environment again.

[george1421]

@tom-elliott Confirmed the menu entry does work. You MUST PAY ATTENTION to the case of your path and file names (you can test with a browser to confirm you have it right). That tripped me up this time (yet again). There is the menu I used to pxe boot the WIN10 MDT LiteTouch install image.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/Boot/BCD BCD
initrd http://${fog-ip}/mdtboot/${arch}/Boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot

[george1421]

@george1421 This method failed. By removing the alias name and using the -n instead. Wimboot threw an error and failed to boot.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd -n BCD http://${fog-ip}/mdtboot/${arch}/Boot/BCD
initrd -n boot.sdi http://${fog-ip}/mdtboot/${arch}/Boot/boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim
boot

[zingaro]

SOLVED !
I have add the variables at the end of the strings command,
now starts correctly !

regards

[zingaro]

Hi,
could you indicate how extract win10 64bit files to exec with wimboot the same start but
into UEFI BIOS ?

i tried all the steps but the systems return can’t start,
wimboot load and patch all files but when finish display:

read BOOTX64.EFI
load BOOTX64.EFI
could not start BOOTX64.EFI
could not boot BOOTX64.EFI

[george1421]

@zingaro Are you trying to use FOG to PXE boot the MDT image for uefi?

[zingaro]

Hi,
finally i start winpe 10 x64 iso image with wimboot into vmware machine and work fine with
legacy bios.
I have a problem with the vmware is set with UEFI Bios…
the start process works fine but when the wimboot has loaded and patched all files, the vmware machine restarts…
I tried the boot with a real pc and the boot end the start process corretly ( reboot the second time and starts winpe ).
There are the difference with VM Machine ?

I noted with winpe10 x64 after the boot process does not have the IP address correct ( 192.168.1.x 255.255.255.0 192.168.1.1 ) , but has a diffrent IP 256.218.111.x 255.255.0.0 )

[Sebastian Roth]

@zingaro said:

There are the difference with VM Machine ?

Well, VM is not hardware and vice versa and also hardware is not equal to all other hardware. We do see many issues related to slight differences in the UEFI firmware and such things. Causing a lot of trouble sometimes. There is no easy answer to your question. You’d need to get into debugging the problem on your VMware to see why it doesn’t work.