[gPXE] Change drive number of the iscsi boot drive?

[Shao Miller]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20110118/66a96c24/attachment.html