Probably useless 'advice', but if MS would kindly detect the existance of and use iPXE's http/ftp capable APIs, that'd be the best solution.
On Wed, Jun 8, 2011 at 5:15 AM, <[email protected]> wrote: > Dear iPXE developers, > > I'm having the following problem with iPXE; I'm using the bootable ISO that > I burned to a CD-ROM. > > I'm booting WinPE over PXE. This works when I'm using a DHCP server on a > local subnet (on which I can set the correct scope options), but due to > security policies I cannot set DHCP scope options on the rest of the > network. So the objective is to boot iPXE from CD-ROM or USB-key with an > embedded script that simply executes: > > dhcp > set next-server x.x.x.x > imgfetch /Boot/pxeboot.n12 > boot pxeboot.n12 > > I tested this and it works well. It doesn't work anymore though when I > increase the TFTP block size within the BCD config (so Microsoft's > bootmgr.exe will request bigger chunks of data from the TFTP-server). > > Our TFTP-server must be reached over a WAN (cross-country), so > TFTP-throughput is very slow (inherent of the protocol, since it's UDP and > every packet needs to be acknowledged). On all of our PC's on the local > subnet (using DHCP scope options and the BOOT ROM of the NIC, so not iPXE) > it works well when I increase tftpblocksize to 8K and download time of a > standard WinPE image drops from 10 minutes to 1,5 minute; which is great. > But iPXE is unable to handle this kind of TFTP-traffic. > > Here's the script that I use to create the BCD config: > > set BCD-File=C:\TFTP-ROOT\Boot\BCD > del %BCD-File% > Bcdedit /createstore %BCD-File% > Bcdedit /store %BCD-File% /create {ramdiskoptions} > Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisksdidevice > boot > Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisksdipath > \boot\boot.sdi > ---> Bcdedit /store %BCD-File% /set {ramdiskoptions} > ramdisktftpblocksize 1432 > Bcdedit /store %BCD-File% /set {ramdiskoptions} > ramdisktftpwindowsize 2 > Set guid={10000000-1000-1000-1000-100000000000} > Bcdedit /store %BCD-File% /create %guid% /d "WinPE PXE-boot image" > /application osloader > Bcdedit /store %BCD-File% /set %guid% systemroot \Windows > Bcdedit /store %BCD-File% /set %guid% detecthal Yes > Bcdedit /store %BCD-File% /set %guid% winpe Yes > Bcdedit /store %BCD-File% /set %guid% osdevice > ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions} > Bcdedit /store %BCD-File% /set %guid% device > ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions} > Bcdedit /store %BCD-File% /create {bootmgr} /d "Lite Touch > Installation" > Bcdedit /store %BCD-File% /set {bootmgr} timeout 1 > Bcdedit /store %BCD-File% /set {bootmgr} displayorder %guid% > > This works, but is very slow. So I replace line 7 with: > > Bcdedit /store %BCD-File% /set {ramdiskoptions} > ramdisktftpblocksize 8192 > > Now it still works on pc's using the internal NIC's PXE-boot code (and it's > much faster), but it doesn't work anymore with iPXE. > > My guess is that iPXE cannot handle TFTP-responses that are spread over > multiple ethernet frames. 1432 bytes works well because with overhead it's > lower than the MTU (1500 bytes). But when the TFTP-server sends 2 or more > UDP packets (to send a bigger block of data, requiring less > acknowledgements), these somehow get lost. > > Any ideas? Thanks a lot in advance. > > *Best regards,* > *Bien à Vous,* > > * Tom Lauwers* > DIGIT A.2-002 Desktop, Peripherals & Mobile Solutions > Siemens > * Office: B-28 03/030* > * Tel.** (+32-2)[29]51649 - Fax. (+32-2)[29]50164* > * E-mail: [email protected]* > > > > _______________________________________________ > ipxe-devel mailing list > [email protected] > https://lists.ipxe.org/mailman/listinfo/ipxe-devel > >
_______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
