#1
Posted 18 September 2012 - 02:03 PM
POPULAR
I've developed a new way of network-booting WinPE which allows you to get the speed advantages of iPXE's HTTP downloading (200MB image in ~2 seconds) without wasting any RAM (as would be the case with e.g. iPXE+memdisk).
Documentation is at http://ipxe.org/wimboot and http://ipxe.org/howto/winpe, source code (GPL) is at http://git.ipxe.org/wimboot.git and prebuilt binaries are available from http://git.ipxe.org/...boot-latest.zip.
For anyone who's interested in the technical details: this works by emulating INT 13 at the bootmgr.exe callback level (rather than at the BIOS level, as with memdisk or iPXE's SAN-booting). The pages of memory occupied by the RAM disk are known to Windows, and so can be reused after the kernel starts.
The INT 13 disk image (including the FAT32 filesystem) is constructed on-the-fly, so you can use the raw boot.wim image; there's no need to wrap the .wim image inside a disk image before booting.
Michael
- Sha0, joakim and Libertarian like this
#2
Posted 18 September 2012 - 02:21 PM
#3
Posted 18 September 2012 - 02:28 PM
Michael
#4
Posted 18 September 2012 - 02:58 PM
Nice !Hi all,
I've developed a new way of network-booting WinPE which allows you to get the speed advantages of iPXE's HTTP downloading (200MB image in ~2 seconds) without wasting any RAM (as would be the case with e.g. iPXE+memdisk).
On a Gigabit lan it must be a missile!
Wonko
#5
Posted 18 September 2012 - 09:19 PM
Could you quickly explain the correct command (ie without script) to reach wimboot from the ipxe prompt. In my current setup I either memdisk boot the ipxe.iso through pxelinux.0, or just throw undionly.kpxe on dhcp. But I cannot figure out the command to chain further..
#6
Posted 18 September 2012 - 09:33 PM
@mcb30
Could you quickly explain the correct command (ie without script) to reach wimboot from the ipxe prompt. In my current setup I either memdisk boot the ipxe.iso through pxelinux.0, or just throw undionly.kpxe on dhcp. But I cannot figure out the command to chain further..
iPXE scripts are just sequences of iPXE commands, so you can just type in the contents of the script, if you prefer, e.g:
iPXE> kernel wimboot iPXE> initrd bootmg bootmgr iPXE> iinitrd boot/bcd BCD iPXE> initrd boot/boot.sdi boot.sdi iPXE> initrd sources/boot.wim boot.wim iPXE> boot
I would think it would be easier to create the "boot.ipxe" script as described on http://ipxe.org/wimboot; you can chain to the boot.ipxe script using:
iPXE> chain http://my.web.server/boot.ipxe
Michael
- Libertarian likes this
#7
Posted 18 September 2012 - 10:02 PM
#8
Posted 18 September 2012 - 10:07 PM
#9
Posted 19 September 2012 - 12:25 AM
Sorry, my mistake. Not all the files where actually available over http (only over tftp). Works fine now.
Glad you got it sorted out!
For future reference: iPXE errors (as shown in your screenshot) include an error URL which will provide further information. For example, your error message includes http://ipxe.org/2d0c613b, which takes you directly to a page explaining that the web server is returning a 404 Not Found.
Michael
#10
Posted 19 September 2012 - 05:57 AM
The transfer speed is great. Comparing the same boot with TFTP and HTTP reveals a very noticeable difference. Simply put, it boots fast over the network.
#11
Posted 21 September 2012 - 12:18 PM
#12
Posted 21 September 2012 - 08:42 PM
#13
Posted 21 September 2012 - 11:25 PM
Can I chainload wimboot in any way over gpxelinux.0 from syslinux?
Yes, but you won't get the speed advantage. gPXE (and hence gpxelinux.0) are based on a very old version of the iPXE codebase, and can't manage anywhere near the 1000Mbps speeds you can get from the current iPXE.
#14
Posted 22 September 2012 - 06:40 AM
There seems to be something strange going on when bootgmr of Windows 8 is used. My test case uses version 6.2.9200.16384. As soon as boot.wim is fully extracted and transfer of execution is to be passed to winload.exe, the machine reboots instantly without any error message. Maybe worth noting that my setup uses VMware Player version 4.0.2. The fonts are in place too.
Using Windows 7 versions of bootmgr and boot.wim succeeds.
Using Windows 8 bootmgr and Windows 7 boot.wim fails similarly as when Windows 8 version of both bootmgr and boot.wim are used.
There is no difference using x86 or x64 version WinPE.
Has wimboot been verified working on this latest version of Windows 8?
#18
Posted 22 September 2012 - 08:18 AM
Thanks,
Michael
#19
Posted 22 September 2012 - 09:20 AM
Thank You for this. Since Iam an absolutely linux noob, I have no clue about compiling undionly.kpxe. Is there a website which do that for me or where I can always get the latest compiled binaries? Why are compiled binaries not available on ipxe.org? In worst case: Could someone compile the latest source for me please?Yes, but you won't get the speed advantage. gPXE (and hence gpxelinux.0) are based on a very old version of the iPXE codebase, and can't manage anywhere near the 1000Mbps speeds you can get from the current iPXE.
#20
Posted 22 September 2012 - 09:27 AM
#21
Posted 22 September 2012 - 10:07 AM
So it therefore seems that:
- the wimboot code does not handle checked builds of bootmgr good enough.
- the wimboot code does not handle decompression of bootmgr correctly.
#22
Posted 23 September 2012 - 09:17 AM
Easy, thank You! But why is this not mentioned on the website? Or am I just blind?fuxxi: you can get the latest binary for undionly.kpxe from http://boot.ipxe.org/undionly.kpxe
#23
Posted 24 September 2012 - 06:14 AM
Yes, Iam blind. Its right here:Easy, thank You! But why is this not mentioned on the website? Or am I just blind?
http://ipxe.org/howto/chainloading
#24
Posted 26 September 2012 - 10:56 AM
What I've found is that my bootmgr 6.2.9200 (latest release of Windows 8) was from a checked build. Switching to a non-checked build of bootmgr from the same version works fine.
So it therefore seems that:If boot.wim is taken from a checked build, it still works fine as long as bootmgr is not from a checked build. Note that the errors with previous versions of bootmgr Windows 8, all came from non-checked builds. So it is the handling of bootmgr that seems to be the issue.
- the wimboot code does not handle checked builds of bootmgr good enough.
- the wimboot code does not handle decompression of bootmgr correctly.
joakim: if you are able to e-mail me copies of the failing versions of bootmgr, I will fix up wimboot to handle them correctly. There's a heuristic involved in locating the compressed bootmgr.exe within the bootmgr binary, and it sounds as though this heuristic is breaking on the checked builds.
Thanks,
Michael
#25
Posted 26 September 2012 - 12:21 PM
Also tagged with one or more of these keywords: http, winpe, ipxe, wimboot, ramdisk
Boot methods & tools →
Boot from USB / Boot anywhere →
WinPe 2024 LazesoftStarted by fi-zilal , 4 weeks ago winpe, boot.wim, iso, ventoy and 5 more... |
|
|
||
Groups →
Windows Extreme →
Windows PE →
Windows 11 PE AudioStarted by MetallicWheat , 05 Mar 2023 winpe, winpe11, audio |
|
|
||
Groups →
Windows Extreme →
Windows PE →
Windows 11 PE AudioStarted by MetallicWheat , 05 Mar 2023 winpe, winpe11, audio |
|
|
||
Groups →
Windows Extreme →
Windows PE →
Windows PE 11 - 22621.1 WOW64 SupportStarted by MetallicWheat , 17 Feb 2023 winpe, windows pe, windows 11 pe and 1 more... |
|
|
||
Groups →
Windows Extreme →
Windows PE →
TeamViewer (TV 15.35.9.0) in a Winpe System sessionStarted by noel , 22 Nov 2022 teamviewe, winpe |
|
|
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users