Windows 7: Installation on a 3TB Drive with a UEFI Motherboard

I bought a 3TB hard drive.  I did not realize that it would exceed a 2TB limit in the old MBR partitioning scheme.  It seemed that I would have to partition the drive using GPT instead of MBR.  The effort to do so ran into a problem with my motherboard.  It was a Gigabyte GA-880GMA-USB3.  There were two problems:  I needed a UEFI system to boot a GPT drive, and the old mobo was unable to boot most programs from a USB jump drive.  The latter incapacity caused problems for various maintenance purposes, including drive partitioning.  It appeared that a motherboard using UEFI instead of BIOS would resolve these issues.

So I switched to an ASRock 970 Extreme4 motherboard with UEFI BIOS.  I didn’t notice that the ASRock was larger.  It would not fit into my little computer case.  I ordered a new midsize ATX tower case to accommodate it.  The case arrived.  I installed the hardware.  The system booted.  It would run the programs on the USB multiboot drive.  So far, so good.

Now I tried installing Windows 7 on the new system.  I was installing from the x64 DVD.  When I clicked “Install now,” it said, “Setup is starting.”  I accepted the license terms and chose Custom rather than an Upgrade installation because it was a new hard drive.  I designated the partition I wanted to install Windows into.  Then I noticed an error message at the bottom of the screen.  It said, “Windows cannot be installed to Disk 0 Partition 1.”  I clicked on “Show details.”  It said this:

Windows cannot be installed to this disk.  The selected disk is of the GPT partition style.

Windows cannot be installed to this hard disk space.  The partition is an EFI system partition (ESP).

A search led to an indication that this problem was due to the attempt to install from the DVD.  I had put the Windows 7 DVD on my YUMI multiboot USB drive, so I booted the computer with that and tried installing from there.  This time, at about the same place in the installation process, I got this message:

Select the driver to be installed.

Load driver

A required CD/DVD drive device driver is missing.  If you have a driver floppy disk, CD, DVD, or USB flash drive, please insert it now.

Note:  If the Windows installation media is in the CD/DVD drive, you can safely remove it for this step.

A search led to various posts talking about BIOS settings.  It occurred to me that I had not yet run the CD supplied with my new motherboard.  I had assumed I would have to have Windows running first to install whatever drivers and software might be on that CD.  I booted the machine with that CD.  It asked, “Generate Serial ATA Driver diskette?”  A search led to the tentative conclusion that this was a PEBKAC problem, potentially resolved by RTFM.  Specifically, the manual suggested making an attempt to configure the BIOS (or, more accurately, the UEFI) before proceeding with installation.  I had gone through the UEFI setup option (F2 or DEL at boot), but had apparently missed some settings.  For this particular motherboard, it seemed that I needed to go into Advanced > Storage Configuration > SATA Mode > IDE Mode (as distinct from AHCI or RAID mode).  But it looked like it was already set to that.  After some fiddling in the UEFI, making sure to go through everything in the printed manual, I found myself back at that “Generate Serial ATA Driver diskette?” question.  I tried “No.”  It said, “Reboot system now.”  I pressed a key and it did exactly that, and in a few seconds I was once again back at the diskette question.  This time, I tried “Yes.”  This was apparently not a winning option either:  it said, “No supported rive found:  Floppy 1.44MB and USB drive!”  I plugged in a stray USB drive and tried “Yes” again.  This time, it found the USB drive and warned me that it was going to be wiped.  I said go ahead.  It gave me a reboot option again.  With the USB drive still plugged in, I was again looking at the diskette question.  I said No.  It rebooted.  I tried Yes.  It was looping, taking me again to the warning that the USB drive was going to be wiped.  I looked at the contents of the USB drive on another computer.  It contained a few files and folders.  One was readme.txt.  It just listed the contents of the USB drive.  The screen on the noncooperative computer was explaining that it needed to “Generate the RAID/AHCI diver [sic] diskette for AMD South Bridge Chipset.”  Why?  I had told UEFI not to do RAID or AHCI.

On the box that the motherboard came in, it said my model was 970 EXTREME 4/A/ASR.  I went to the ASRock download webpage and searched for that.  It said, “Sorry, No Data.”  I tried using the drop-down menus to choose motherboard model.  That led to downloads for 64-bit Windows 7.  But they all looked like ZIP files that, as usual, would be run in Windows.  I wasn’t seeing anything that seemed relevant to the problem of getting the system to install Windows.  I found a thread discussing problems that someone had when he forgot to plug in the hard drive, but that was not the problem here; I had already used GParted from my YUMI drive to verify that the motherboard was seeing the hard drives.  It occurred to me to unplug one hard drive, so as to avoid problems during installation, but that made no difference in the ASRock Driver Disk Preparer scenario.

I decided the ASRock installation CD was not helping.  I returned to the project of installing Windows 7 from the YUMI USB drive.  (Incidentally, I had discovered, at some point, that Acronis True Image Home 2011 would not work with the 3TB drive, whereas the free Macrium Reflect would.)  When the Windows installation got me to the point of that “Select the driver to be installed” error message, I clicked OK.  It said, “No device drivers were found.”  I clicked OK again.  I unclicked the box that said, “Hide drivers that are not compatible with hardware on this computer” and clicked Rescan.  It still found no drivers.  I wondered whether the problem was that I was trying to install from a multifunction USB drive.  This reasoning emerged from a Microsoft webpage saying that problems like this could result from a bad copy of Windows.  I had previously installed from that DVD, so I didn’t think that was the issue, but that left the question of the USB drive.  Using Universal USB Installer, I tried pretending that the Windows 7 ISO was actually an unlisted Linux ISO.  That failed, so I tried burning the ISO to the USB drive using ImgBurn.  ImgBurn wanted a DVD drive, so that didn’t work either.  Cued by a video, I dug out the Microsoft USB download tool and browsed to the Windows 7 ISO that I had installed onto the USB drive.  It gave me an error:

Invalid ISO File

The selected file is not a valid ISO file.  Please select a valid ISO file and try again.

So perhaps we were onto something here.  The ISO was valid enough to start the installation process from the YUMI drive, but perhaps not valid enough to finish it.  I wasn’t sure where I had gotten the ISO:  maybe I had downloaded it, or maybe I had used some utility to create it from the Windows 7 DVD.  How was I supposed to get a valid Windows 7 ISO?  It seemed that I had to download it.  It was a 3.1GB download; for my flavor, it was called X17-59465.ISO.  Firefox indicated that it would take four hours to download.  When it was done, I tried loading this corrected version onto my YUMI USB drive.  Since the YUMI drive already had a menu entry for it, I just had to replace the ISO in the YUMI drive’s ISOS folder.  Or perhaps not.  When I tried to boot with it, I got an error:

Error 60:  File for drive emulation must be in one contiguous disk area

Evidently the copied ISO went into a fragmented YUMI drive.  The general advice was not to defrag a USB drive, but apparently defragging was a necessary step in this case.  I had heard of defragmenters that were especially suited for USB drives, and maybe had even played with one, but a search seemed to suggest that plain old Smart Defrag would do the job.  So I tried that.  On a 32GB USB drive, this was not a fast process, even though there were only a couple of fragments.  It took 12 minutes, and it wasn’t worth it:  again, I got Error 60.  I tried WinContig.  It said yes, the Windows ISO on the YUMI USB drive was still fragmented.  I let it run.  It ran for probably an hour, and when it was done it still didn’t work.  Apparently I should have reinstalled the Windows ISO via YUMI rather than by just copying it over to the drive.

Meanwhile, I had been trying again with the Microsoft USB download tool, this time using the downloaded ISO.  This time, the Microsoft tool gave me the same errors as the Windows 7 DVD had given me previously (above).  It seemed that the faulty ISO had given me additional errors with the USB drive installation attempt, and that once those were out of the way, I was stuck at the same point as before.  The USB approach didn’t help.

It seemed that I should have just attempted to understand and resolve the error messages the installation DVD or USB drive were giving me.  The first error said that I could not install Windows 7 x64 on a GPT-partitioned drive.  A revised search led to the thought that I was having problems because my target hard drive was not completely blank.  Using the YUMI drive, I booted Ubuntu, ran GParted, and wiped out all partitions on that drive.  Ubuntu wouldn’t shut down, so I shut the machine off, waited 30 seconds, and then booted with the USB created by the Microsoft tool.  This time, I was looking at nothing but Disk 0 Unallocated Space.  I clicked on the Drive Options (advanced) and created a 150GB partition.  It created a 100MB Disk 0 Partition 1:  System Reserved space.  Being a purist, I deleted the 149.9GB remaining after that.  Now, after the 100MB reserved space, there were two separate unallocated spaces.  One was 2047.9GB (basically, 2TB, or 2048GB) and the other was 746.5GB (i.e., 747GB).  I didn’t want that.  I ran GParted.  It gave me this:

Libparted Warning

/dev/sda contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted — possibly by a program that doesn’t understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?

I wasn’t sure.  I clicked yes.  It showed me just one 2.73TiB unallocated space.  That looked good.  I rebooted into the Windows installer again.  It still showed the same thing:  100MB system reserved, plus two unallocated spaces.  I deleted the reserved space.  Still two unallocated spaces.  I tried a search.  It led to a Microsoft webpage indicating that these two separate unallocated partitions were a sign of MBR (not GPT) partitioning.  I would need to partition the drive as GPT.  Was that something I could do by plugging it into an external USB drive bay connected to the other (MBR) computer?

I tried that, running diskmgmt.msc on that other machine.  Disk Management saw it as (would you believe) a 746GB unallocated space.  I right-clicked on the grayed area for this drive, at the left side of Disk Management, and chose “Convert to GPT Disk.”  So now it was a 746GB GPT disk.  What have you done with my other 2TB?  We were getting nowhere.  I re-connected the 3TB drive to the otherwise driveless, nonfunctioning computer and looked at it in GParted.  Now that program, too, was showing only 746GiB unallocated, plus a 128MiB unknown space.  I tried deleting the latter.  That didn’t help:  still only 746GB left.  I ran SeaTools from my YUMI drive on this Seagate 3TB drive.  SeaTools wouldn’t see the drive in an external USB bay, so I had to shut down, put the drive back inside the computer, and try again.  Now SeaTools saw the drive.  I tried Seatools > Advanced Features > Set Capacity to MAX Native.  That looked like the only option that might reset it to use its full capacity.  It didn’t work.  I was still missing 2TB.

A search yielded some possibilities.  Per Seagate advice to one user, I rebooted with the Windows 7 System Repair disc (Control Panel > Backup and Restore > Create a system repair disc).  (I had made an ISO of that disc, and was able to boot it from the YUMI multiboot USB drive, though sometimes it then “repaired” itself in the target computer so that the YUMI drive would no longer boot.)  I went into the SysRepair disc’s Command Prompt option and typed Diskpart at the prompt.  That gave me a DISKPART prompt.  I typed “list disk.”  It reported only 746 GB.  It did show an asterisk under the Gpt heading on the right end, so I assumed this meant it saw the 746GB as a GPT partition.

I typed “exit” and rebooted with Ubuntu on my YUMI drive.  There, I did a search (top left button, in Ubuntu 13.04) for, and ran, Terminal.  It gave me a prompt.  The goal was to run gdisk.  To do this, I typed “sudo apt-get install gdisk.”  That installed it.  Then I typed “sudo gdisk.”  It asked for a device filename.  To get that, I went back to the search button (top left) and found and ran GParted.  It showed that my device was /dev/sda.  I typed that in response to the gdisk query.  It found a GPT partition.  I tried again with “sudo gdisk -o.”  It said, “You may need to edit /etc/fstab and/or your boot loader configuration!”  I had forgotten how to do that, and anyway was only using the live (i.e., uninstalled) Ubuntu.  Eventually I figured out that I was already in gdisk (getting a “Command (? for help)” prompt), and therefore just had to use individual gdisk commands.  I tried o.  Just a plain letter O.  Running P showed that O had not broken out of the 747 GB limit.  I typed X to get into the expert options, then ? to see a list of choices.  I tried S to resize the partition table.  That didn’t seem to help.  I tried expert option Z.  That didn’t help, and it dumped me back out into the main Terminal prompt. I went back into gdisk, back into expert mode, and tried R.  No joy.

There was another Ubuntu hard drive utility, hdparm.  Typing that at the prompt brought up various warnings.  An webpage led me to think these options were more likely to damage my disk (or my system) than to help it.  Then again, a Wikipedia page suggested that the only danger was to the data, of which there was no longer any on this system.  With the USB drive unplugged (i.e., Ubuntu running from RAM) and still no other drives connected, I decided to try the hdparm -w option.  (That was a lower-case w, not an upper-case W.)  Oddly, that just repeated the list of hdparm options.  Apparently I had to specify the device:  hdparm -w /dev/sda.  It said, “Permission denied.”  I tried again with “sudo hdparm -w /dev/sda.”  This time it said, “HDIO_DRIVE_RESET failed:  Inappropriate ioctl for device.”  A search suggested that about 87,000 brave souls had tried this before me, and had failed.  One answer, circa 2005, was that hdparm was only for ATA (apparently not including SATA) devices.  Had it been upgraded since then?

I rebooted with the YUMI drive and tried Parted Magic.  But no, that was the one that used GParted, which I had already tried.  I rebooted again and tried Partition Wizard.  It saw only the 747GB partition.  I shut down and tried EaseUS Partition Master, connecting the hard drive to the working Windows PC via external USB dock.  No joy.

Back in Ubuntu on the empty machine, I tried Testdisk:  “sudo apt-get install testdisk” as advised, but that said “Unable to locate package testdisk.”  In System Tools > Konsole, Knoppix 7 (installed on the YUMI drive) did give me the option of running TestDisk 6.13.  I chose the option for an EFI GPT partition and selected the Analyse option.  It said, “Bad GPT partition, invalid signature.”  I chose the Quick Search option.  It found evidence of my old partitions.  I wanted to know how to use TestDisk to change drive geometry, since that seemed to be the only useful option.  I ran a search for information on my particular drive, a Seagate 7200.14 ST3000DM001.  A Seagate document said it had 16,383 cylinders, 16 heads, 63 sectors per track, and apparently 4K sector size (4096 bytes per sector; “4K physical emulated at 512-byte sectors”).  I ran TestDisk’s Analyse – Quick Search sequence again.  It gave me warnings:  “Incorrect number of heads/cylinder 255 (NTFS)” and “Incorrect number of bytes per sector 512 (NTFS).”  That was confusing, as I had no NTFS partition on the drive.  But apparently TestDisk was detecting that I’d previously had NTFS partitions on it?  It detected, oddly, that I had MS Data and Mac HFS and also Unknown partition types.  TestDisk took maybe 15-20 minutes to do the bulk of its analysis.  Then it got hung up at 97% complete, cylinder 15935 of 16382.  This was after it had identified its second Mac HFS partition.  The hard drive was still running; it just wasn’t progressing past cylinder 15935.  TestDisk seemed to be trying to figure things out.  It was giving weird names to some of these partitions, like GWM-9M-$6M-= b~^dS for one of the MS Data partitions and ~Q^A for the Mac HFS partitions.  I feared TestDisk might be in a loop, defeated by a really screwy drive.  I gave it four hours.  It didn’t change.  I tried to kill it.  It wouldn’t die.  I ultimately had to unplug the USB cable from the external USB drive.  That was probably not good for it.

I should have thought to go directly to Seagate’s website.  I hadn’t tried their DiscWizard software.  But on closer inspection, that just led to SeaTools (above) and also to a SATA Hard Drive Troubleshooter, which led in turn to trivial advice that the available capacity of a hard drive can be slightly lower than the advertised capacity.  It seemed that I had gotten lost in the Seagate website’s labyrinth; Softpedia did give me the DiscWizard download.  I tried to install it on the other, working computer.  I had the impression that, once installed, it would let me create a bootable medium that I could use to test the Seagate drive on the nonworking computer.  Unfortunately, the DiscWizard installer gave me an error:

Installation Restrictions

Restrictions, which prevent the product installation, are detected.

To install the product, at least one Seagate/Maxtor device should be installed in your system.

No problem.  I cabled the 3TB Seagate drive, sitting in its external USB drive dock, to the working computer, and tried again.  Now DiscWizard was willing to install even though Disk Management (diskmgmt.msc) was showing the drive as consisting of 746.52GB unallocated.  Since I now had both DiscWizard and the defunct drive on the working computer, I decided to go at it right there.  I noticed that the Home tab in the DiscWizard interface had an Extended Capacity Manager option.  That sounded like a good place to start.  It steered me to the Add New Disc tool.  That tool led to a Properties option that said I had a 746.5GB MBR (not GPT) partition on the recalcitrant drive.  I proceeded with the Add New Disc Wizard to add a GPT partition in that 746GB space.  According to Disk Management, that’s exactly what it did.  In other words, no fix here.

I had previously run SeaTools in the bootable form, but now it occurred to me to try SeaTools for Windows.  I ran its Short Drive Self-Test on the Seagate drive.  It passed.  I ran the Drive Information test.  It seemed to indicate a somewhat screwy drive — saying, for instance, that SMART was not supported.  I clicked the Safe to File button.  It probably did save to file, but I had no idea where, and it wasn’t telling.

I seemed to have exhausted the possibilities for getting the 3TB drive to display an available 3TB.  I made one more try on the nonworking machine, but neither GParted nor other partitioning software were able to see anything more than 746GB.  I would have to RMA the drive.

It occurred to me to read user reviews for the 3TB drive.  It had a lot of bad reviews at Newegg and Amazon — but not, interestingly, at TigerDirect, where I had bought it.  The bad reviews had more to do with drives that were dead on arrival, or within weeks thereafter.  I decided I did not want this drive, so I decided not to RMA it to Seagate — especially after reading about hassles that others had experienced when attempting to do that.  I decided instead to return it to TigerDirect.  It appeared they would not charge a restocking fee, which I appreciated.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Windows 7: Installation on a 3TB Drive with a UEFI Motherboard

  1. Dave says:

    That sounds about right for a typical Windows 7 installation. I’ve been trying for 2 weeks to install W7 on to a GPT format 2 TB raid array. The problem is that Windows 7 x64 will only install to a GPT disk from an EFI booted DVD or else EFI booted USB. The microsoft X17-59465.ISO is faulty, and will not allow booting in EFI mode, at least on some motherboards, like the Gigabyte GA-970A-D3 rev 1.4 which has the error prone failure of the hybrid EFI+normal BIOS.

    Other problems include getting locked out and BSOD’s where Windows starts booting up, but then fails due to being unable to read the HDD, because the bios needs two trips into it, firstly to turn on the raid array, and a second time to set the hard disk booting order to have the Raid array as the first disk.

    Windows will not boot if a USB or External drive is set higher priority in the first boot device.

    One of my ISO’s did allow me to boot into GPT mode, but I’ve no idea why or how to get it do to that again. Usually I’ll get the Error message: “Windows cannot be installed to this disk. The selected disk is of the GPT paritition style.” That happens when using diskpart to clean the disk by deleting the partition table, then converting it to GPT, while booting from a W7 install DVD in normal Bios mode.

    Or else by modifying the install DVD to allow it to boot in EFI mode, then I’ll get the error message: “”Windows cannot be installed to this disk. This computer hardware may not support booting to this disk. Ensure the disks controller is enable in the computer’s BIOS menu.”

  2. Paul says:

    I noticed with interest where you wrote “It still showed the same thing: 100MB system reserved,
    plus two unallocated spaces. I deleted the reserved space. Still two unallocated spaces.”… I believe you will find that is the correct partitioning for GPT to run windows. This is because some legacy software relies on windows being on an MBR partitioned disk and is there to catch errors where the software calls to the system partition. It is a fake MBR setup designed to iron out errors and I think that is the point at which you went wrong. You believed this was wrong but it was the correct way

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s