Syslinux - Dec 2009 - [gPXE] Chain Grub4Dos over HTTP?

Cross-posting to the Syslinux mailing-list.

Joakim Schicht wrote:
> But part of the question is also about "memdisk raw" vs
"memdisk iso".
"raw" and "iso" are not mutually exclusive.  I think that
perhaps you
meant "HDD versus El Torito emulation."  One can do:

LABEL ramwin
  KERNEL memdisk
  APPEND raw iso
  INITRD ramwin.iso
> Lets say you have a ramboot windows (winvblock, firadisk, ms ramdisk, 
> wimboot, disklessangel, etc) and you will boot this over HTTP. What 
> would be the ideal way, utilizing resources most, to do this, of the 2 
> mentioned methods?
Again, assuming you are asking about an HDD image versus an .ISO image, 
the ISO9660 filesystem is read-only by design, so don't expect to save 
anything on it, regardless of whether it's a RAM disk or a real CD/DVD.  
For that reason, I prefer HDD images.  Some OSs have "live CD"
versions
which expect to boot from such a filesystem; Some flavours of Windows PE 
would be examples of this.  I know of several Linux distros which offer 
"live CD" .ISOs.  For these, you'll want to use "iso"
with MEMDISK.
Whether you use "raw" or not might be a matter of experiment with your
particular hardware platform, if you experience difficulties.
> If I have understood it correct the usage of "memdisk iso" on
such a
> setup will result in a lost/wasted ram equivalent to the size of the 
> iso (not being able to use it until next reboot)..
Correct.  If the bulk of the .ISO image is an embedded RAM disk image 
(such as a squashfs or .WIM file) and that image is _again_ loaded into 
RAM by some process, you would need roughly twice the RAM, which is 
redundant.
> Now would it not be more wise in terms of resource utilization, to 
> boot with "memdisk raw" and winvblock (because then all ram is 
> utilized)? Or is it possible to recover the ram used by "memdisk
iso"?
Assuming you meant "memdisk HDD emulation" rather than "memdisk
raw",
you need an OS driver to find and provide the MEMDISK to the OS.  
WinVBlock is an example of this.  Currently, WinVBlock _only_ supports 
HDDs, so there's little choice about it.  That will change sooner or 
later.  Why, just last night a patch for MEMDISK was submitted towards 
furthering OS driver support for MEMDISK.

Taking Windows out of the picture altogether, MEMDISK works by hooking 
[at least] INTerrupt 13h.  Any OS using this method for disk I/O will 
thus be intercepted by MEMDISK.  "Proper OSs" such as Linux, *BSD, 
Windows, etc. do not use INT 13h, but use drivers for disk I/O.

gPXE can download the RAM disk image as MEMDISK's "initrd" via
HTTP.  At
this time, WinVBlock is the only "proper" OS driver which can find an 
use the same RAM disk image in RAM, and it can only perform HDD emulation.

- Shao Miller

Sorry for being unlear. Yes I meant  "HDD versus El Torito emulation".
And Thanks for manifesting my beliefe about memory usage.

It will thus by definition be nonsense to use use El Torito emulation for ie
chained images based on SDI/ramdisk.sys or firadisk, as they will
"waste" the ram equivalent to size of iso. Meaning they could instead
be memdisk HDD emulated and include winvblock and then reuse the
"kicker" as a large secondary ramdisk (at least use the ram for
something). Maybe it's safe to say that for Windows;

1. It should be better to use HDD emulation and use El Torito emulation as a
last option (at least for ramboots).
2. Winvblock is superior to firadisk, at least on HTTP booting (not considering
any possible performance difference discovered lately).

That said, do you know if winvblock can recognize its original disk past second
and third hook (ie nested HDD emulation)? I mean if inner rambooted image with
winvblock can find the outer mapped image that was mapped at previous 1 or 2
steps...?

(I just came to think about how winvblock would behave in coexistence with
firadisk - if it can distinguish between disks in a nested ramboot)

Joakim Schicht





Date: Mon, 7 Dec 2009 14:31:13 -0500
From: Shao.Miller at yrdsb.edu.on.ca
To: jonny49 at live.no
CC: gpxe at etherboot.org; syslinux at zytor.com
Subject: Re: [gPXE] Chain Grub4Dos over HTTP?






  
  


Cross-posting to the Syslinux mailing-list.



Joakim Schicht wrote:

  But
part of the question is also about "memdisk raw" vs "memdisk
iso".


"raw" and "iso" are not mutually exclusive.  I think that
perhaps you
meant "HDD versus El Torito emulation."  One can do:



LABEL ramwin

  KERNEL memdisk

  APPEND raw iso

  INITRD ramwin.iso




Lets say you have a ramboot windows (winvblock,
firadisk, ms ramdisk, wimboot, disklessangel, etc) and you will boot
this over HTTP. What would be the ideal way, utilizing resources most,
to do this, of the 2 mentioned methods?

  


Again, assuming you are asking about an HDD image versus an .ISO image,
the ISO9660 filesystem is read-only by design, so don't expect to save
anything on it, regardless of whether it's a RAM disk or a real
CD/DVD.  For that reason, I prefer HDD images.  Some OSs have "live
CD"
versions which expect to boot from such a filesystem; Some flavours of
Windows PE would be examples of this.  I know of several Linux distros
which offer "live CD" .ISOs.  For these, you'll want to use
"iso" with
MEMDISK.  Whether you use "raw" or not might be a matter of experiment
with your particular hardware platform, if you experience difficulties.




If I have understood it correct the usage of "memdisk
iso" on such a setup will result in a lost/wasted ram equivalent to the
size of the iso (not being able to use it until next reboot)..


Correct.  If the bulk of the .ISO image is an embedded RAM disk image
(such as a squashfs or .WIM file) and that image is _again_ loaded into
RAM by some process, you would need roughly twice the RAM, which is
redundant.




Now would it not be more wise in terms of resource
utilization, to boot with "memdisk raw" and winvblock (because then
all
ram is utilized)? Or is it possible to recover the ram used by "memdisk
iso"?

  


Assuming you meant "memdisk HDD emulation" rather than "memdisk
raw",
you need an OS driver to find and provide the MEMDISK to the OS. 
WinVBlock is an example of this.  Currently, WinVBlock _only_ supports
HDDs, so there's little choice about it.  That will change sooner or
later.  Why, just last night a patch for MEMDISK was submitted towards
furthering OS driver support for MEMDISK.



Taking Windows out of the picture altogether, MEMDISK works by hooking
[at least] INTerrupt 13h.  Any OS using this method for disk I/O will
thus be intercepted by MEMDISK.  "Proper OSs" such as Linux, *BSD,
Windows, etc. do not use INT 13h, but use drivers for disk I/O.



gPXE can download the RAM disk image as MEMDISK's "initrd" via
HTTP.
At this time, WinVBlock is the only "proper" OS driver which can find
an use the same RAM disk image in RAM, and it can only perform HDD
emulation.



- Shao Miller

 		 	   		  
_________________________________________________________________
Nye Windows 7: PCen som passer for deg. Finn ut mer.
http://windows.microsoft.com/shop

> gPXE can download the RAM disk image as MEMDISK's "initrd"
via HTTP.  At this
> time, WinVBlock is the only "proper" OS driver which can find an
use the same
> RAM disk image in RAM, and it can only perform HDD emulation.
> 
> - Shao Miller
If he wants to boot a Windows iso over HTTP (before ISO emulation is implemented
in WinVBlock),
he can use gPXE to download the iso via HTTP and use grub.exe of grub4dos for
mapping
the initrd to a virtual CD drive.
You need the Firadisk driver inside the iso, to let Windows find the iso mapped
by grub4dos.

Try:
LABEL ramwingrub4dos
  LINUX grub.exe
  INITRD ramwin.iso
  APPEND --config-file="map (rd) (hd32); map --hook; root (hd32);
chainloader (hd32)"


Or (it can be that (rd) needs to be changed to (rd)+1 according to the grub4dos
documentation):
LABEL ramwingrub4dos
  
LINUX grub.exe
  
INITRD ramwin.iso
  
APPEND --config-file="map (rd)+1 (hd32); map --hook; root (hd32);
chainloader (hd32)"

- Gert Hulselmans

Joakim Schicht wrote:
> ...
I don't want to hijack gPXE and Syslinux mailing-lists to discuss 
WinVBlock, though the boot-scenario involves both gPXE and MEMDISK.  If 
you have another option (such as a Boot-Land forum thread) for 
discussion, please e-mail me in private with that option.

Thanks to those patient readers out there who might have been starting 
to feel a little spammed. :)

- Shao Miller