<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<tt>I wrote:</tt>
<blockquote type="cite" cite="mid:4B5A0439.5070108@YRDSB.Edu.On.Ca">
<title></title>
<tt>The Mad One wrote:</tt>
<blockquote type="cite" cite="mid:718971.83894.qm@web27905.mail.ukl.yahoo.com">
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td valign="top" style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;">
<div id="yiv2131472051">
<p><tt>Well, i hope this was clear enough & wasn't out of
topic.<br>
</tt></p>
</div>
</td>
</tr>
</tbody>
</table>
</blockquote>
<tt><br>
The network-booting aspects are on-topic. NTFS DOS drivers creep a
little off-topic, in my humble opinion, though I understand the
utility. Perhaps you might be interested in looking at boot.kernel.org.</tt></blockquote>
<tt><br>
Just to clarify: I am in no way an authority for what's on-topic or
off-topic. That decision only rests with gPXE's Project Leader, Marty
Connor. So to you and any other readers, feel free to ask away and
contribute your subject matter. :) I'm absolutely sure that Marty
would let anyone know if they were off-topic. I don't think I recall
even seeing that happen. :)<br>
<br>
Hopefully my opinion hasn't scared you or anyone else away... It is
clear that you are looking for a means to utilize gPXE as part of some
goal. For me, I'd be happy to provide you with some possibilities, if
you'd kindly provide some more detail. This request is simply part of
the feedback loop. Request -> Possible Resource -> Query Missing
Detail -> Further Detail -> Possibilities.<br>
<br>
NTFSPRO is a DOS read/write utility for NTFS filesystem access. It
could be on a DOS floppy disk image, which you could use as a RAM disk
with MEMDISK or GRUB4DOS. It costs money, if it's still available from
its vendor, who I believe is part of Microsoft now.<br>
<br>
The normal SAN-boot process for gPXE attempts to boot the MBR of a SAN
immediately after attaching. If that MBR returns to gPXE in its MBR
boot code or because it's not a valid bootable MBR, then SAN connection
can be maintained by using the 'keep-san' option, as documented on the
Etherboot (& gPXE) projects(') wiki.<br>
<br>
If you have one of the Syslinux suite or GRUB4DOS installed on the SAN
itself, then you could boot the SAN and then boot your RAM disk, which
would still have access to the SAN. Do you have the ability to put one
of these boot-loaders on the SAN?<br>
<br>
You could boot a RAM disk, then that RAM disk could load gPXE, then
that gPXE could attach (and boot) a SAN, but I'll bet that would defeat
the purpose of your RAM disk, since execution would land with the SAN
instead of with your utilities on the RAM disk for working with the
SAN. I could be wrong, but you might need custom hacks to gPXE in
order to attach a SAN and then boot a RAM disk while maintaining the
SAN connection.<br>
<br>
When a SAN is attached to a system, gPXE is in the background,
providing the disk I/O with its networking support. If you then try to
use UNDI or even an actual specific DOS driver for your NIC, you take
the chance of interfering with this networking (obviously) which is
critical for the SAN's availability. And so my experiments for such
have failed.<br>
<br>
If you are after some sort of client-specific, dynamically generated
file(s) for putting on the SAN with your read/write NTFS support, you
might have good luck by dynamically generating your RAM disk image on
the server so that it already contains your client-specific file(s).
That's if you have found a way to boot that RAM disk with your SAN
attached.<br>
<br>
Note that if you boot a RAM disk, which then boots gPXE, which then
boots a SAN, which then boots something like DOS, that final, booted
DOS should have access to the original RAM disk and the files therein.
So in a round-about fashion, you could transfer control back to your
RAM disk after the SAN is attached. If you have your client-specific
file(s) and your NTFSPRO available, that seems to satisfy your goal.<br>
<br>
For example, suppose your RAM disk image is a 1.44 MB floppy disk image
with a FAT12 filesystem and SYSLINUX installed. Your SYSLINUX.CFG file
could look like this:<br>
<br>
DEFAULT get_san<br>
LABEL get_san<br>
KERNEL gpxe.lkrn<br>
<br>
and you could have some other DOS tools on there, too, such as
NTFSPRO. You'd need to have gpxe.lkrn on there, perhaps with an
embedded script to boot your SAN. The script might go:<br>
<br>
#!gpxe<br>
ifopen net0<br>
sanboot aoe:e1.1<br>
<br>
and you could compile your gpxe.lkrn like this:<br>
<br>
cd gpxe/src/<br>
make EMBEDDED_IMAGE=~/my_script.gpxe bin/gpxe.lkrn<br>
<br>
where my_script.gpxe is in your home directory and has the contents
already mentioned a little bit above.<br>
<br>
On your SAN, you might have a single NTFS partition. If it were
Windows XP, that'd mean you have NTLDR and a BOOT.INI file. Your
BOOT.INI file might look like this:<br>
<br>
[Boot Loader]<br>
Timeout=5<br>
Default=C:\GRLDR<br>
<br>
[Operating Systems]<br>
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"<br>
/noexecute=optin /fastdetect /sos<br>
C:\GRLDR="GRUB4DOS"<br>
<br>
where we see that GRUB4DOS will automatically be booted after your
embedded script in your gpxe.lkrn does its SAN-boot.<br>
<br>
Then GRUB4DOS will look for a MENU.LST file, perhaps something akin to
the following:<br>
<br>
# Grub4DOS menu created for me by me on some date<br>
<br>
color light-gray/black white/black<br>
timeout 0<br>
<br>
title DOS RAM disk<br>
map --mem /dos.vfd (fd0)<br>
map (fd0) (fd1)<br>
map --hook<br>
root (fd0)<br>
chainloader /io.sys<br>
<br>
title Reboot the Workstation<br>
reboot<br>
<br>
title Power Off the Workstation<br>
halt<br>
<br>
In the above, we see that your NTFS partition would have a DOS.VFD
floppy disk image file. In the MENU.LST, we load this file as the
first floppy disk drive, and map the old RAM disk established
originally, way back, as the second floppy disk drive.<br>
<br>
When you boot your DOS.VFD floppy disk's IO.SYS (which is DOS), you
might enjoy using an AUTOEXEC.BAT file which redirects the startup
process to some batch file on your B: drive, which, if you recall, is
the original RAM disk with gpxe.lkrn on it, along with some other
files, possibly. Voila!<br>
<br>
But wait! How do you boot that original RAM disk in the first place?
Well, if you are going to generate that image file dynamically, you
might be booting it over the network, which implies gPXE or your native
PXE stack -> PXELINUX -> MEMDISK. That's not too hard, though!<br>
<br>
Something else you might be interested in is the fact that WinVBlock is
a driver which will allow your Windows XP/2003 (or possibly others, but
untested) to access your gPXE-booted AoE SAN _as_well_as_ any
previously loaded RAM disks loaded by either MEMDISK or by GRUB4DOS,
during the same booted session. Thus you could load client-specific
data as a RAM disk and tell your Windows to use it, since it will find
that RAM disk as a disk drive.<br>
<br>
Additionally, if you are familiar with Windows PE environments, such as
Windows PE CDs/DVDs, you might be interested to know that MEMDISK and
GRUB4DOS are capable of booting such an .ISO image file, and WinVBlock
will once again provide access to that RAM disc so that the PE can
truly boot. Using this strategy, your SAN need not be booted itself
(files in use by the installed OS) and yet you can manipulate its
contents. Multiple RAM disks are allowed.<br>
<br>
I certainly hope this helps.<br>
<br>
Disclaimer: All claims and opinions are solely those of myself and do
not and should not be perceived as representing the Etherboot nor the
gPXE projects in any way. Thank you for your understanding.<br>
<br>
- Shao Miller<br>
</tt>
</body>
</html>