diskless XPE

  • Thread starter Thread starter zx1620
  • Start date Start date
Z

zx1620

hi all

i need to implement booting XPE remotely (PXE/RPL) without local disk.
remote boot service is not acceptable because it eats up too much of memory.
any idea or direction is appreciated.

Nick
 
You are kidding right?

1a. Add more memory.
1b. Reduce image size.
2. Give up on this idea.
3. Spend months creating your own driver.
4. Find some other way probably unknown to me.

If you want hypothetical approach to number 3.

Make SDI that will contain only drivers and your driver. This need to
contain files that are loaded before volume C: is mounted.

Your driver need to communicate with your server and to expose virtual disk
device. Or maybe even better you should expose partition C: forced export
(without mount and anything else).
In first case you should be able to create virtual disk device.
In second case you will have virtual volume that is not mounted.
You could go even so far that you could store information's back to server,
so you would not need to use EWF either.

In case that this is possible, what would happen is you loose connection to
server for few moments during read or write, your device would crash, is
this what you really want?


Regards,
Slobodan
 
thx, Slobodan!
3. Spend months creating your own driver.
Click to expand...
i'd like this one. a good chance to get into the system.
This need to contain files that are loaded before volume C: is mounted
Click to expand...
i know that this is the key to the success, if this issue gets passed,
the left things may be easier. but now, i have no idea on how to get this
done.
what would happen is you loose connection to server for few moments during
Click to expand...
read or write, your device would crash
sorry, are you sure about that?

Nick
 
Nick,

I think that I overestimated the problem, this should not be so hard to do.

1. You should make only one SDI image with bootable disk image.
2. Use DDK example of ramdisk and modify it with following adjustments.
- You should use NDIS (it is easy) for accessing network, or there are third
party socket support for drivers (I prefer NDIS it is cleaner).
- You create virtual disk, not volume.
- For all read request directed to your disk you should read requested info
from SDI file stored on server.
- For all write request RAM EWF should protect you from getting this type of
request.
- If you loose connection with server and you have read request pending then
you could block your device and wait until connection is reestablished (very
bad).

Process of boot:
1. BIOS map your disk from SDI file, and makes it accessible trough int 13.
2. ntldr. start booting device using int 13 like on local HDD.
3. When all required OS drivers are loaded (including your driver) system
will try to continue boot from partition and logical volume.
- Since your driver is loaded and it represents only disk device in your
system. XPe will continue boot process trough your driver.


I don't know if this is enough but it should cover most of the problems.

Regards,
Slobodan
 
Slobodan
thanks a lot!
you give out most useful information i need. so what i should do is:
1. create a NDIS-Disk driver that does following work:
FS IO <--> NDISDISK <--> Remote Server
what's the best solution at server side? a virtual disk, right?

2. provide a bootable SDI image of mini-footprint and a target image(virtual
disk on server).
WAO!!!! no need to care about pxe .
component of windows ram disk is also not used anymore.


3. get NDISDISK loaded in a proper way so it could be recognized as the only
disk in system.
is there any special thing to pay attention at this point?

4. all things are working in my way

Regards

Nick
 
Nick,


You never said do you need info made on client to be persistent after
reboot. But as you draw connections I concluded that you want to use server
to store information that are made on client.
If you don't want to store changed info on server then you should use RAM
EWF on client side.
Something like: FS <=> EWF <= Partition <= NDISDISK <=...= Remote Server
(Your app or driver that will serve required image data.)
This requires you to have SDI file and DiskImage file on your server.
I use < and > for disk data direction.

Also there is alternate solution for two way communication:

FS <=> NDISVolume <=...=> Remote Server (Your app or driver.)
Client side driver could be derived directly from ramdisk sample from DDK in
previous case you would need to simulate storage device.
On server side you must have SDI file with content of XPe partition one file
for all clients. It will be used during the boot and for data read.
Also you will need one file per each client that will persistently contain
changes made to volume on client side.
When you give read request from client first you will try to read info from
this file (associated to client), and if requested info is not found in it
then you will send info that you read from SDI file.
Basically this would be simulation of Disk based overlay from EWF, but it
would happen on server side.
You must create program on server side that will handle all this requests.

Third and probably the most compact solution if you only need to read data
from server would be:
FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
needed).

1. You would need to integrate functionality similar to RAM EWF.
2. You need to expose volume C: this you should be able easily to create
using ramdisk sample.
3. You should use NDIS and make support for TFTP so you can read info from
same SDI file that you used for initial boot.

This is the most compact solution and probably easiest to accomplish. You
have to maintain only one file on server side. No need for extra support on
server side.


Your choice.


Regards,
Slobodan
 
I was carried away with my last post, but in my first post I stated with a
reason why boot SDI file must be small.
Since ntldr will load whole sdi file to memory, it should be as small as
possible.
And it appear that you will need to have at least one file besides this SDI
file.

But you can still use TFTP to fetch data from server, without additional
need for server side application.


There might be probably another way so you can use only one SDI, but this
you will need to investigate.

1. To persuade ntldr using the PXE or (custom ASM int 13 handler that will
simulate local disk) so ntldr. would think that it is loading from HDD.
2. To check complete PXE TFTP specification and to see what support is
offered by these recommendations.

Regards,
Slobodan
 
Slobodan
thx!
yes, if i don't keep change, i could use RAM EWF at client side or a own
implement at server side.if RAM EWF used, how can i get it to work because
there is no EWF volume existing.
FS<=> Integrated_RAMEWF_NDIS_Volume <=..= Remote server (no application
needed).
Click to expand...
i choose this mode at the beginning if RAM EWF works.
here's coming some more detailed issues, could you help me to analyse.

1.the bootable sdi is loaded into memory thru DHCP/PXE/TFTP, but how can i
know which server to contact with after my NDisk driver got loaded? there is
no parameters or settings tell me the server address.

2.which is the best way to call NDIS from my driver, calling TDI , binding
to a miniport or any other?

3 at server side, for bootable sdi footprint, nothing neeeded. however, i
need to implement a file disk driver that hold the target image. also i need
a server app to listen all disk redirect request from client and pass them
to the file disk driver. it would be like:

disk i/o request-->network disk--(calling
NDIS)-->Server--(DeviceIOControl)-->file disk
is there any problem?

here is another question?
during boot progress, at which point, no INT 13 is called anymore? im
trying to get answer using windbg and softice, no result yet.

Nick
 
RAM EWF can be configured and can work without EWF volume.
You can find and read my doc and component on www.xpefiles.com.

If you use EWF, then you probably wont be able to create virtual volume but
you will need virtual partition or virtual disk.

1.
You can use TCP/IP with DHCP server (default behavior) to obtain your IP
address.
Also trough NDIS you can simulate same network packets that BIOS do for PXE
boot. So you can access file you want on server using TFTP.
Much simpler implementation would be to use fixed IP address of server that
has your application, and to use direct TCP connection between your driver
and your server application.
Drawback to this is that this requires you to have your app on server side.

2.
There is no best way.
TDI is much easier and direct way to use various kind of network protocols
like TCP/IP, etc.
But if you want to use TFTP you will need to write NDIS protocol driver or
to use some third party driver.
In normal circumstances you should export upper side of your driver so it
can be accessed trough TDI. But since it is your single purpose driver you
can make another way of direct control.

3.
If you can manage to use TFTP then you can access file on server trough it,
no need for extra app on server side.
This is one way only.

If you want server app, then easiest for implement would be to use TCP/IP
for communication.
And you can use ReadFile to read requested data from file. One option.
Better option is to map view to file in memory. So you can use virtual
memory manager to handle read and write accesses to your file. Much faster
and easier, you access file like any other piece of memory.

4. use /SOS option in boot.ini you will see list of all drivers that are
loaded by ntldr. trough int 13 after this load is done I think that int 13
is no longer used and that XP start executing.

Regards,
Slobodan
 
zx1620 said:
hi all

i need to implement booting XPE remotely (PXE/RPL) without local disk.
remote boot service is not acceptable because it eats up too much of memory.
any idea or direction is appreciated.

Nick
Click to expand...
Take a look at BXP, from Venturcom (www.vci.com).
Only needed files are transfered, so memory requirement is reduced.

Romuald Thiéry
 
Slobodan
You can find and read my doc and component on www.xpefiles.com.
Click to expand...
you are a talent! how did you get that!
1
Click to expand...
i need to care about the deployment, so to implement DHCP/PXE client by
calling NDIS may be the only choice
2
Click to expand...
still no idea
3 after boot-start drivers get loaded by ntldr, later drivers are not
Click to expand...
loaded by INT 13, but thru ide/scsi driver. In my network disk driver, i
could only get raw disk data requests from upper driver, so TFTP doesn't
make sense then. and i must provide a server app to recieve the raw disk
requests and pass them to my virtual disk driver transparently.
am i right?
4
Click to expand...
i made a deep trace into the boot progress of XP. what i know now is:
NTLDR loads all boot-start drivers using INT13, after the NTOSKNL.exe
get control, it loads other drivers by making call to ide/scsi

Regards!

Nick
 
Nick,

First you must force all network drivers and protocols that you are planning
to use to be loaded by ntdlr.
Also this includes your netdisk driver.

If you are planning to write application on your server side, then you don't
need to bother yourself with DHCP,PXE,TFTP and TCP/IP.

I'm using for our remote data system direct access to lan trough NDIS from
within our main storage driver. Modification of this technique can be
applied to you as well.

Depending on your network topology (My network has direct visibility between
all devices on my network):
You can write simple discovery protocol that will give you MAC address of
your server.
Discovery Protocol:
- Broadcast question from client "Server Respond"
- Server direct response to client MAC address that send request.

All other communication can be done trough your simple protocol based on MAC
addresses.

You will need two types of requests from client:
1. Read x bytes of data from position y.
2. Write x bytes of data to position y.

Take in account that for most networks max packet size is 1536 bytes, so you
will need to make multiple packet stream to make efficient use of network.

Take a look at ndisuio sample driver from DDK you will require to implement
similar functionality on both client and server side to access network.

Regards,
Slobodan
 
Back
Top