You can read about how to boot a full XP from WIM here:
http://sanbarrow.com/phpBB2/viewtopic.php?t=1695
When you say "204 MB XP SP2 HDD image", do you mean complete with all necessary
files to ramboot? How stripped-down is it actually?
I have not yet dived into iSCSI booting, but will soon do. Btw, is that
possible to boot over WAN? Is your setup documented anywhere?
By "another stack", I meant downloaded from a booted xp (not pxe), either
host-host or guest-host. I cannot say if gPXE behaves differently from other
pxe stack, because my other tests with other stack have downloaded over tftp
only (built-in vmware). It is therefore not directly comparable.
Btw, I am the same Joakim that tested your winvblock driver a few months ago.
Joakim Schicht
Date: Mon, 30 Nov 2009 22:57:21 -0500
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [gPXE] Transfer speed with e1000 and pcnet32 in VMware
Joakim Schicht wrote:
I am fiddling with WAN (HTTP) booting of "Universal XP". By wimbooting xp, we
can enjoy great compression and faster image transfer (my rather complete XP
SP2 with all services intact, is only 209 Mb after finally being zipped).
Interesting. How exactly are you accomplishing this? What exactly are you
downloading via HTTP? I was under the impression that the entirety of XP could
not be in a .WIM file and be bootable, though you can attach a .WIM file at
some point during boot. If you have a relevant link to your setup over at the
Boot-Land forums, perhaps you would kindly reply with such a link here for
other interested gPXE Windows XP users?
For comparison, I have a 204 MB XP SP2 HDD image which I boot using MEMDISK and
WinVBlock. Each computer which boots this image is licensed for a single
installation of Windows XP SP2. The BOOT.INI menu offers all kernel and HAL
combinations, so the image will boot on any hardware platform with enough RAM.
256 MB is enough to run, but many programs cannot allocate memory and have
quirks; CMD.EXE is fine. In this scenario, I have gPXE attach to a read-only
SAN. That SAN has a FAT32 partition and SYSLINUX installed onto it. SYSLINUX
boots and loads MEMDISK along with the "RamXP" HDD image. The fact that gPXE
uses iSCSI to read this SAN results in significantly faster transfer times than
HTTP, but obviously is not quite as universal as HTTP allowances in the world.
But using another stack than gPXE in the same environment (even with no
physical nic connected) will not trigger this stall behaviour. Which leads me
to think that it could be some weird combination.
Using another stack, how are you downloading via HTTP?
Either way, it is definately a vmware-related issue.
If gPXE is really behaving differently than some other PXE stack which
accomplishes decent HTTP download behaviour, it would still be good to know why.
- Shao Miller
_________________________________________________________________
Windows Live™ Mail. Flere kontoer på ett sted.
http://download.live.com/wlmail_______________________________________________
gPXE mailing list
[email protected]
http://etherboot.org/mailman/listinfo/gpxe
