Threaded Mode | Linear Mode

kfortner · 2014-09-15, 15:16

(2014-09-12 21:42)jwillis84 Wrote:
Quote:What I am trying to accomplish is to PXE boot into a WinPE environment to then run a set of code that deploys the operating system to the target system from the WinPE environment. Today this works great on PCI based NICs, but for USB NICs the undionly.kpxe does not seem to work. I am dynamically building the iPXE boot script using a PHP script and the iPXE web call to determine what WinPE deployment environment to use. Is there a way to use the ISO build of iPXE to make the same call to my PHP and then chain boot to WinPE from the ISO of iPXE?

That's a scenario I can test.

It would be helpful to know which WinPE version, or the target OS.

We are up to WinPE version 5.1 which spans Thirteen "released" versions.

As a Guess I'll look at testing WinPE 3.0 or WinPE 3.1 since Microsoft seems to be "burning" anything Win Eight related and taking chisel and hammer to all the monuments. If your using something post 3.1 please let me know.. and you have my condolences.

I'm guessing some people already have access to WinPE 6.0 but I do not.. should be available with two weeks however. I can't wait to dig into it.

[As for boot from ISO over http and then chain load?] Yes I do think that will work.. but you would still need something local, in ROM, NVRAM, SD card, USB or a USB DVDROM to bootstrap the whole process.. and at that point why not just boot PXE and load WinPE into a ramdisk and continue from there.

Like I said.. I got the USB image booting in VMware.. it just took an extra step.. and was trivial to do.. i didn't want to bog down the focus on USB support in the Git repo to address the USB image issue.. I felt it was some one elses problem

the BIOS looks at the USB MMD devices like NVRAM, USB Flash or SD Cards and either supports them as bootable or not.. they load iPXE which loads a USB host controller driver and then probes for attached USB Ethernet devices.. if it finds one.. that loads an iPXE USB Ethernet device driver..

.. and then I presume if properly configured.. iPXE loads the next stage boot loader from the network (WinPE ntloader?) into RAM.. then releases its memory and jumps to the ntloader.. which boots from its ramdisk, looks for the iPXE undi device driver signature in memory, and loads the WinPE undi device driver.. they mate.. and become the UNDI driver for WinPE that just happens to be attached to a USB Ethernet device already started.. and continue to pass traffic

I don't really know if the current undionly.kpxe support is completely in 32 bit space, or if somehow it expects the replacement kernel to "adopt" the iPXE driver code and provide runtime cycles for it.. the old 16 bit version kind of left it running in 16 bit space as a Terminate Stay Resident stub that got calls and woke up to process network traffic and went to sleep while the 32 bit OS was running.. it was more a high load "polling" mechanism flipping back and forth to catch and resend missed packets. I feel almost certain they do it a different way now.

You would almost need a kind of virtual machine environment that shared the environment back and forth.. the new OS in one vm, the old UNDI driver code running in a second.. and they mtually communicate through the UND Interface.. I just don't know .. but its intensely interesting (of course that Apes or Mimicks the original TSR model and used the DOS and Windows environment as virtual machines.

I will look into it.

I am currently using WinPE 5.1, and from my experience on the ASIX USB, undionly.kpxe will load, and pull an IP, but either the http file transfer or wimboot process will fail out.