I wrote:
The Mad One wrote:
Well, i hope this was clear enough & wasn't out of topic.
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.
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. :)
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.
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.
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.
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?
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.
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.
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.
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.
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:
DEFAULT get_san
LABEL get_san
KERNEL gpxe.lkrn
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:
#!gpxe
ifopen net0
sanboot aoe:e1.1
and you could compile your gpxe.lkrn like this:
cd gpxe/src/
make EMBEDDED_IMAGE=~/my_script.gpxe bin/gpxe.lkrn
where my_script.gpxe is in your home directory and has the contents
already mentioned a little bit above.
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:
[Boot Loader]
Timeout=5
Default=C:\GRLDR
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"
/noexecute=optin /fastdetect /sos
C:\GRLDR="GRUB4DOS"
where we see that GRUB4DOS will automatically be booted after your
embedded script in your gpxe.lkrn does its SAN-boot.
Then GRUB4DOS will look for a MENU.LST file, perhaps something akin to
the following:
# Grub4DOS menu created for me by me on some date
color light-gray/black white/black
timeout 0
title DOS RAM disk
map --mem /dos.vfd (fd0)
map (fd0) (fd1)
map --hook
root (fd0)
chainloader /io.sys
title Reboot the Workstation
reboot
title Power Off the Workstation
halt
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.
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!
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!
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.
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.
I certainly hope this helps.
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.
- Shao Miller
_______________________________________________
gPXE mailing list
[email protected]
http://etherboot.org/mailman/listinfo/gpxe
