[gPXE] I need a little ram disk after gPXE boot and before AoEsanboot

[Shao Miller]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20100122/460bf4cb/attachment-0001.html