Hello Shao, Binh,<br /><br />I was in a similar situation some months back: I wanted to boot WinPE from iSCSI yet have Windows consider the local HDD to be Drive 0 instead of Drive 1.  I wrote about the problem I had and the solution I used, though it wasn’t quite what I desired, it ended up working.  Linky: http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/cea6177e-9cb2-420e-bbc0-0cac487e51e2<br /><br />Anyway, one thing I recall was that I tried using an encapsulated option to make gPXE map the iSCSI drive as 0x81 instead of 0x80… but gPXE seemed to ignore the config.  I recompiled the source to use 0x81 by default, but that didn’t boot.  Neither did MEMDISK when configured for 0x81.  Still not sure why.<br /><br />Something about the BIOS of my target system didn’t let Windows see a remapped BIOS drive as a drive that’s available through BIOS because it destroyed the ARC path to NT drive relationship for the remapped disk, which Windows *requires* for installation.  I did find that I could map to GRUB4DOS’s “hd32” (CD-ROM) and boot that way; I still nuked the ARC path from the CD drive’s object, but that didn’t matter for what I was doing.<br /><br />Also, for BCD entries when booting from BOOTMGR, the ARC path syntax (e.g. multi(0)disk(0)rdisk(1)partition(1)) is irrelevant.  The Windows Boot Manager actually resolves ARC paths to NT disk objects prior to starting WINLOAD, but it does use BIOS INT 13h to work with hard disks.  Now, whether it maps the disk it was loaded from as \Device\Harddisk0 or if it just sequentially enumerates BIOS drives to \Device\HarddiskX as they’re found… your guess is as good as mine :P<br /><br />In regards to your question, Binh, you might like to read this: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/windows-nt-6-boot-process.html<br /><br />It may not cover precisely what you’re looking for, but it is a very informative read if you’re curious about the inner workings of the Windows boot process ;)<br /><br />Cheers,<br />Andrew Bobulsky<br /><br /><br />On Jan 18, 2011 12:00pm, Shao Miller &lt;Shao.Miller@yrdsb.edu.on.ca&gt; wrote:<br />&gt; <br />&gt; <br />&gt;   <br />&gt;     <br />&gt;     <br />&gt;   <br />&gt;   <br />&gt;     On 1/18/2011 11:42, Binh Thai wrote:<br />&gt;     <br />&gt;       <br />&gt;       <br />&gt;       Hi Shao,<br />&gt; <br />&gt;          <br />&gt; <br />&gt;         Thanks for your<br />&gt;             reply.<br />&gt; <br />&gt;          <br />&gt; <br />&gt;         I forgot to<br />&gt;             mention that I meant “drive 0” in the context of Windows<br />&gt;             disk drive numbering.<br />&gt; <br />&gt;     <br />&gt;     <br />&gt; <br />&gt;     Oh, ok.<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     <br />&gt;     <br />&gt;       My goal is to boot a system from an iscsi target<br />&gt;             without disrupting the disk drive numbers of the internal<br />&gt;             hard drives. For example, if I have one internal hard drive,<br />&gt;             I want to see it detected as Disk 0 whether I boot from it<br />&gt;             or from the iscsi target. If I boot from the iSCSI target, I<br />&gt;             want to see the iscsi target as drive 1, not 0. Currently,<br />&gt;             the iSCSI drive would become Disk 0 and push the internal<br />&gt;             drive to Disk 1.<br />&gt; <br />&gt;          <br />&gt; <br />&gt;         I think the PnP<br />&gt;             enumeration process in Windows has some relationship with<br />&gt;             the BIOS drive numbering. Could you please point me to some<br />&gt;             in-depth documentation regarding the BIOS drive numbering<br />&gt;             and how int13 is used?<br />&gt; <br />&gt;         <br />&gt; <br />&gt;     <br />&gt;     <br />&gt; <br />&gt;     I do not believe that BIOS drive numbers and Windows drive<br />&gt;       numbers have any correlation.  Use Microsoft&#39;s SysInternals&#39;<br />&gt;       LoadOrd.exe to check your driver load order.  If you ensure that<br />&gt;       the drivers responsible for the internal storage adapters are<br />&gt;       loaded before the iSCSI driver, then I think your odds are better<br />&gt;       for the iSCSI HDD getting a higher number than the internal<br />&gt;       HDD(s).<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     However, it might be the case that the startup protocol<br />&gt;       hands an MBR signature from boot-up to the drive number assignment<br />&gt;       routine; in this case, whatever drive is used for booting (your<br />&gt;       iSCSI HDD) will be drive 0 no matter what.  You can use<br />&gt;       Microsoft&#39;s SysInternals&#39; WinObj.exe to check the mapping of the<br />&gt;       ARC names (\ArcName\) to the drive numbers (\Device\HarddiskX).<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     I can only think of a convoluted way to push the boot drive<br />&gt;       up and away from Windows drive number 0:<br />&gt; <br />&gt;     - Boot the iSCSI drive<br />&gt; <br />&gt;     - Have GRUB4DOS on the drive<br />&gt; <br />&gt;     - Have GRUB4DOS remap the drive number from 0x80 to 0x81<br />&gt; <br />&gt;     - Chain-load the Windows boot-loader<br />&gt; <br />&gt;     - Have BOOT.INI/BCD attempt to boot<br />&gt;       multi(0)disk(0)rdisk(1)partition(1) instead of rdisk(0) (0x81<br />&gt;       instead of 0x80)<br />&gt; <br />&gt;       - If the iSCSI drive is \Device\Harddisk1 then hopefully Windows<br />&gt;       would also further connect it as multi(0)disk(0)rdisk(1). <br />&gt;       ARC _and_ HDD numbers would then be 1 instead of 0.  (Untested.)<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     So having said that, I&#39;d like to ask: _why_ do you want the<br />&gt;       drive numbers numbered in this way?<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     - Shao Miller<br />&gt; <br />&gt;       <br />&gt; <br />&gt;     <br />&gt;   <br />&gt; <br />&gt; <br />&gt;