none
Windows 7 Setup - Cannot find/create a System partition (ARC path issue)

    Question

  • I'm running up against a bit of a wall.

     

    I'm trying to start the Windows 7 setup from a network location with an answer file I created using the Windows SIM (though I've tried not using my answer file as well, FWIW).

     

    I've taken a copy of the Windows PE as created by copype.cmd x86 <dest>, added a couple drivers using DISM, and set the san policy to 2.  I renamed winpe.wim to boot.wim, put it into the sources folder, and then copied them to a partition on a raw disk image, added bootmgr to the root of the drive, and ran bootsect /nt60 against the partition's drive letter.

     

    I'm using gPXE to download the raw disk image over HTTP and then booting it with MEMDISK.  Long story short, the WIM file and boot drive are being sourced from a RAM disk instead of a CD/DVD/USB/Whatever.  The difference here is that my source drive, the MEMDISK image, is overwritten when Windows PE switches to protected mode.

     

    For some reason, in spite of the fact that Windows Setup can see, partition, do whatever with my disk (and manually partitioning/marking as active with Diskpart didn't change a thing), setup complains that it can't find an existing System partition to modify and it can't create one.  Without being able to do this, of course, setup won't continue.

     

    The extremely damning thing is that I can't seem to find any way to get setup to ignore this and just image my drive anyway, much less find information about a fix that doesn't involve rearranging the BIOS boot order or file locations on the CD/DVD/USB stick that I'm not using.  Can I trick setup into whatever the conditions are that it wants to find my install target valid? Is there any way to do that?

     

    I can't seem to find a solid answer anywhere on why this error occurs, just what the [not-applicable-to-me] solutions are.

     

    I appreciate any ideas or information anyone can offer.

     

    Thanks,

    Andrew Bobulsky

    Friday, September 03, 2010 1:38 AM

Answers

  • Okay, so I figured out why this happened.

     

    When I was using gPXE and/or MEMDISK and/or GRUB4DOS, they work by hooking INT13 in the BIOS and assigning their disks as BIOS drive 0x80, which is the first hard disk in the system, and normally corresponds to ARC path multi(0)Disk(0)rdisk(0) (i think, could be slightly different).  Existing drives are shifted up by one number: i.e., disk 0x80 becomes 0x81, 0x81 becomes 0x82, etc.  My guess here is that BOOTMGR resolves the ARC paths in real mode and then passes them on to Windows once the processor switches into 32 or 64 bit modes.

     

    While BOOTMGR/Windows/Setup seem to be fully capable of resolving the ARC paths for any of the disks I'm mapping via the INT13 hook, Windows Setup can't resolve the ARC paths for any of the "shifted" BIOS drives (i.e., my real target System drive/partition).  That inability to resolve the ARC path for the target installation disk is the reason that Windows Setup gives the error stating that we should "check that the disk's controller is enabled in the BIOS."  Furthermore, the reason that I was able to install when the iSCSI disk was passed through to WinPE via the iBFT whereas when I wasn't able to install if I didn't pass the iSCSI disk through to WinPE was because the only disk that Setup could resolve the ARC path for was that iSCSI volume.  While Setup did consider the iSCSI volume as a "bootable" volume, it still generated a warning on my actual target installation disk ("Windows cannot be installed to Disk 0 Partition 1") but would proceed with the installation anyway, modifying the BCD on the iSCSI target as the "system" volume and the local disk as the "boot" volume (that terminology drives me insane to this day, dearest Microsoft =]).

     

    Anyway, the way I resolved the issue was by using GRUB4DOS or MEMDISK to instead map my disk image as an Optical drive ((hd32) in GRUB4DOS), corresponding to BIOS drive 0xA0.  This shifts any local CD drives (which are unimportant to me) up by one, which does indeed prevent Setup from resolving the ARC path for the local CD drive (which can be verified in X:\Windows\Panther\setupact.log).  Since the location of the local HD never changes, Setup never complains and I'm allowed to proceed with my installation unencumbered.

     

    ---------

     

    What really bites me here though, and I would love if someone who understands BOOTMGR or Setup better could comment on this, is that I can't understand why these ARC paths are necessary.  With NTLDR, ARC paths were obviously necessary for NTLDR to refer to bootable disks in a meaningful way, and I get that.  BOOTMGR, however, doesn't refer to ARC paths at all.  BOOTMGR uses NT-style device mappings, which I might add are ALL resolved correctly (In the event that none of my real mode INT13 hooked drives are passed through via any type of BFT/Driver combo, that is) by Windows Setup in each of the scenarios I've described in this thread.  I'm guessing here that BOOTMGR resolves ARC paths and also maps NT-style paths on its own in real mode.  So if BOOTMGR only needs NT-style paths (which are valid in 32/64 bit modes) to truly identify which disk it needs to read to boot Windows, then why in the ____ does Windows Setup require a valid ARC path for my boot volume?  I mean, I can understand why Setup should want to have a valid ARC path for that volume as this ensures that the volume is bootable, but why can't I tell setup to ignore this and just install anyway?!

     

    Just curious, of course.  While the solution that I'm using works well and is very fast, booting WinPE to a command prompt in roughly ~20 seconds, it would be much nicer to not have to pull my disk image into RAM and then extract the WIM image on this same disk again into RAM in order to boot when it's simply not necessary.  If I could just source my WIM file from an iSCSI volume I can skip the extra RAM usage and move straight to BOOTMGR from the INT13 hook, booting WinPE much faster (~10 seconds) and simplifying my boot process.

     

    Oh well, at least it works  :-P

     

    I hope this helps someone else.  The "why" here was really driving me up the wall.

     

    Cheers,

    Andrew Bobulsky

    • Marked as answer by Andrew Bobulsky Saturday, September 11, 2010 10:00 PM
    Saturday, September 11, 2010 9:57 PM

All replies

  • On your PE disk, does DISKPART see the SYSTEM partition? diskpart, then "list volume". You could assign a drive letter and run chkdsk on each.

    Monday, September 06, 2010 12:25 AM
  • I could give you the actual DISKPART output if I were at the office right now, but the answer is no.

     

    I've tried booting the client using a variety of methods. PXE > gPXE > PXELINUX > MEMDISK > bootmgr/SDI/WIM is what I was trying when I posted here.  I also tried using gPXE to boot from an iSCSI LUN without writing an iBFT to prevent passing the iSCSI target on to WinPE because I want to share that target as a boot disk for multiple clients (which is EXTREMELY fast I might add; WinPE is ready to rock in ~14 seconds from when bootmgr loads off the iSCSI LUN!).

     

    In any case, what I'm trying to do is present a single disk to Windows setup, and my boot methods are preventing WinPE from ever seeing the actual disk that bootmgr and the WIM file from which it was sourced.  This shouldn't matter because I'm booting the SDI/WIM combo from RAM in the first place, but Windows Setup is getting mad that there are obviously no currently bootable drives in the system for it to modify from its point of view.

     

    I also tried manually running DISKPART and creating/formatting partitions on the target machine, marking the 100MB volume as active, and then assigning C: to the second one, but that doesn't work either.  Can I trick it into installing by copying bootmgr to the "new" SYSTEM volume and then building a skeleton BCD?

     

    ----

     

    Otherwise speaking, I've sort of given up on this because our target deployment date has been pushed to this coming Wednesday as opposed to the middle of next month.  Gotta love vendors.  I have discovered that if I boot from an iSCSI LUN (that presents a snapshotted volume to each initiator) and actually allow it to write an iBFT to get the LUN through to WinPE, Setup complains that my target disk isn't bootable but installs anyway.  I assume it tries to modify the iSCSI target's BCD as the machine complains that BOOTMGR is missing when it reboots, so I'm writing a batch file to build the SYSTEM volume manually after the imaging is done to the target disk.... but it really shouldn't be this difficult :P

     

    I just hope this doesn't leave me wishing I had used WDS to begin with :-(

     

    Thanks,

    Andrew Bobulsky

     

    Monday, September 06, 2010 2:12 AM
  • Okay, so I figured out why this happened.

     

    When I was using gPXE and/or MEMDISK and/or GRUB4DOS, they work by hooking INT13 in the BIOS and assigning their disks as BIOS drive 0x80, which is the first hard disk in the system, and normally corresponds to ARC path multi(0)Disk(0)rdisk(0) (i think, could be slightly different).  Existing drives are shifted up by one number: i.e., disk 0x80 becomes 0x81, 0x81 becomes 0x82, etc.  My guess here is that BOOTMGR resolves the ARC paths in real mode and then passes them on to Windows once the processor switches into 32 or 64 bit modes.

     

    While BOOTMGR/Windows/Setup seem to be fully capable of resolving the ARC paths for any of the disks I'm mapping via the INT13 hook, Windows Setup can't resolve the ARC paths for any of the "shifted" BIOS drives (i.e., my real target System drive/partition).  That inability to resolve the ARC path for the target installation disk is the reason that Windows Setup gives the error stating that we should "check that the disk's controller is enabled in the BIOS."  Furthermore, the reason that I was able to install when the iSCSI disk was passed through to WinPE via the iBFT whereas when I wasn't able to install if I didn't pass the iSCSI disk through to WinPE was because the only disk that Setup could resolve the ARC path for was that iSCSI volume.  While Setup did consider the iSCSI volume as a "bootable" volume, it still generated a warning on my actual target installation disk ("Windows cannot be installed to Disk 0 Partition 1") but would proceed with the installation anyway, modifying the BCD on the iSCSI target as the "system" volume and the local disk as the "boot" volume (that terminology drives me insane to this day, dearest Microsoft =]).

     

    Anyway, the way I resolved the issue was by using GRUB4DOS or MEMDISK to instead map my disk image as an Optical drive ((hd32) in GRUB4DOS), corresponding to BIOS drive 0xA0.  This shifts any local CD drives (which are unimportant to me) up by one, which does indeed prevent Setup from resolving the ARC path for the local CD drive (which can be verified in X:\Windows\Panther\setupact.log).  Since the location of the local HD never changes, Setup never complains and I'm allowed to proceed with my installation unencumbered.

     

    ---------

     

    What really bites me here though, and I would love if someone who understands BOOTMGR or Setup better could comment on this, is that I can't understand why these ARC paths are necessary.  With NTLDR, ARC paths were obviously necessary for NTLDR to refer to bootable disks in a meaningful way, and I get that.  BOOTMGR, however, doesn't refer to ARC paths at all.  BOOTMGR uses NT-style device mappings, which I might add are ALL resolved correctly (In the event that none of my real mode INT13 hooked drives are passed through via any type of BFT/Driver combo, that is) by Windows Setup in each of the scenarios I've described in this thread.  I'm guessing here that BOOTMGR resolves ARC paths and also maps NT-style paths on its own in real mode.  So if BOOTMGR only needs NT-style paths (which are valid in 32/64 bit modes) to truly identify which disk it needs to read to boot Windows, then why in the ____ does Windows Setup require a valid ARC path for my boot volume?  I mean, I can understand why Setup should want to have a valid ARC path for that volume as this ensures that the volume is bootable, but why can't I tell setup to ignore this and just install anyway?!

     

    Just curious, of course.  While the solution that I'm using works well and is very fast, booting WinPE to a command prompt in roughly ~20 seconds, it would be much nicer to not have to pull my disk image into RAM and then extract the WIM image on this same disk again into RAM in order to boot when it's simply not necessary.  If I could just source my WIM file from an iSCSI volume I can skip the extra RAM usage and move straight to BOOTMGR from the INT13 hook, booting WinPE much faster (~10 seconds) and simplifying my boot process.

     

    Oh well, at least it works  :-P

     

    I hope this helps someone else.  The "why" here was really driving me up the wall.

     

    Cheers,

    Andrew Bobulsky

    • Marked as answer by Andrew Bobulsky Saturday, September 11, 2010 10:00 PM
    Saturday, September 11, 2010 9:57 PM