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
_______________________________________________
gPXE mailing list
[email protected]
http://etherboot.org/mailman/listinfo/gpxe
