<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<tt>Cross-posting to the Syslinux mailing-list.<br>
<br>
Joakim Schicht wrote:</tt>
<blockquote type="cite" cite="mid:SNT102-W202EFC6041B879523FD3C8B2900@phx.gbl">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style><tt>But
part of the question is also about "memdisk raw" vs "memdisk iso".</tt></blockquote>
<tt><br>
"raw" and "iso" are not mutually exclusive. I think that perhaps you
meant "HDD versus El Torito emulation." One can do:<br>
<br>
LABEL ramwin<br>
KERNEL memdisk<br>
APPEND raw iso<br>
INITRD ramwin.iso<br>
<br>
</tt>
<blockquote type="cite" cite="mid:SNT102-W202EFC6041B879523FD3C8B2900@phx.gbl"><tt>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?<br>
</tt></blockquote>
<tt><br>
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.<br>
<br>
</tt>
<blockquote type="cite" cite="mid:SNT102-W202EFC6041B879523FD3C8B2900@phx.gbl"><tt>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)..</tt></blockquote>
<tt><br>
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.<br>
<br>
</tt>
<blockquote type="cite" cite="mid:SNT102-W202EFC6041B879523FD3C8B2900@phx.gbl"><tt>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"?<br>
</tt></blockquote>
<tt><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
- Shao Miller<br>
</tt>
</body>
</html>