On 1/18/2011 12:33, Binh Thai wrote:
"So having said that, I'd like to ask: _why_ do you want the drive
numbers numbered in this way?"
èI have some unattended programs that capture and deploy OS images.
The user may boot a system from a CDROM/USB Drive and do the
capturing. Meanwhile, the deployment occurs from an iSCSI Windows
image, which currently changes the numbering of the internal hard
drives and this causes the captured images to be deployed to the wrong
drives. I can make the deployment program aware of the iSCSI drive but
I'm looking for a more thorough solution.
Could you please explain for me the relationship between gPXE iSCSI
boot and Windows iSCSI Initiator? When does gPXE end and Windows iSCSI
Initiator pick up?
gPXE (and iPXE) create the iBFT and mark it up in the memory map so it
is not overwritten before booting the SAN. gPXE (and iPXE) hook
INTerrupt 0x13 to provide INT 0x13 users (such as DOS, the Windows
boot-loaders, other boot-loaders) with access to the disk.
The Windows boot-loader(s) will use [the hooked] INT 0x13 to load the
OS. Once the OS begins operation, the OS no longer uses INT 0x13, so
gPXE's (or iPXE's) work is done; its code is never invoked again.
The Windows iSCSI initiator boot-mode driver searches for the iBFT in
memory. Once found, the driver will attempt to reconnect to the same
SAN that the hooked INT 0x13 had previously been connected to. If
successful (networking is sane), like other disk bus drivers, it creates
a disk object.
In Windows XP, the disk object is then driven by DISK.SYS. I believe
this driver is responsible for the creation of the \Device\HarddiskX\
object directories (you can see with WinObj.exe). I believe that it
creates the DRx and DP(x)... devices in those object directories, as
well as the symbolic links. I believe that it also creates the
PhysicalDriveX symbolic links under \GLOBAL??\. I believe that the
devices it produces are enumerated as STORAGE devices
(HKLM\SYSTEM\CCS\Enum\STORAGE\).
I think what happens is that after all boot drivers have been
initialized and all devices in the device tree have been walked (and
possible installed), the kernel checks all disks' MBR signatures and
creates the ARC name [symbolic link] for the boot disk based on
whichever disk matches. It can also thus choose which volume to boot from.
I hope this information helps you out. Perhaps you could adjust your
unattended processes to specifically look for the internal HDDs, perhaps
using a disk signature... That seems to be how Windows does it; perhaps
you could use the signature to _exclude_ the iSCSI disk from your processes.
- Shao Miller
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
