I found that I could not load any OS to that drive. I had partitioned and
formatted it under both WinXP and Vista - no difference and never any signs
of any problems no matter how it was used in the system.
These prolly used the same broken access logic based on PnP
Finally got out an old Win9x / WinXP boot disk that has FDISK (for >64Gb
drives) on it and used it at a DOS prompt to delete the NTFS partition then
re-partition the drive.
This is prolly using an older logic based on BIOS
Tried one more time.... booted up using the Vista DVD and then used the
option in the Vista install to do a quick format on that drive and proceeded
with the install. It worked.....!
I naturally went and tried all the previous installs I tried before - WinXP
Pro, Vista x86 and x64 versions - they all loaded and ran fine.
So it appears as if the hubris of "to hell with what BIOS says, we'll
detect it ourselves" may be biting MS in the ass here.
OSs are guests of the system, and should take their cues from the
system, especially when it comes to boot devices. Else you'd have
difficulty setting up the system to work with different OSs sharing
the same system - and we wouldn't want that, eh?
This is even more so if the OS writes changes back to the system
level, e.g. PnP info in NVRAM, or "funny" MBR code, etc.
DOS is really dumb and takes BIOS at face value. If all OSs did the
same, then at least they'd all work in the same way, but it's tempting
to "roll your own" when BIOS has limitations, e.g. HD addressing
barriers, slow default modes of UDMA operation, etc.
OTOH, PnP is supposed to kick in only when the OS is already booted -
certainly way beyond MBR and PBR.
Low-level problems might arise if this logic is followed:
- can you see a standard IDE or other standard disk interface?
- if Yes, ASSume that's how we booted
- if no, prompt/use "special" drivers for boot disk interface
- remember answer above when writing back boot-access changes
In this situation, with no IDE HD present, the OS is forced to
conclude that S-ATA access is required, and will prompt for drivers if
it needs to, or at least know where to write back changes to the code
etc. that is used to boot the system.
The Asus mb uses the Silicon Image Sil3132 SATA controller for the external
(and one internal) SATA drive port on the A8N32-SLI Deluxe mb and I believe
it's the same on yours. The NVIDIA controller is for the 4 internal SATA
drives and uses the nForce4 chipset and nForce drivers.
OK, this is even more likely to fail than the standard IDE vs. S-ATA
clashes over merged identity spaces etc. because now you have a
"standard" S-ATA that may be ASSumed to manage all S-ATA, plus an
"extra" S-ATA that's there to provide RAID or just extra S-ATAs.
Ironically, this sort of problem is more likely to apply to hi-end
motherboards that extend the native chipset's facilities.
For example, at a time that mobo chipsets provide 4 x S-ATA but no
RAID, a hi-end mobo may add a Promise S-ATA RAID controller that
offers what can be used as an extra Master-only PATA, a pair of extra
S-ATA, or a RAID pair of S-ATA.
The problem is that it can be nebulous as to how these things fit with
the native motherboard's IDE and S-ATA, especially if the BIOS has no
knowledge of the extra controller, which relies on the controller's
own ROM to manage itself and its internal settings.
I had a Jetway motherboard like this; standard Intel chipset of the
time, plus extra chips to add FireWire and the Promise RAID etc. It's
a good way to make a high-end flagship mobo, especially for a
lesser-known board maker eager to get good reviews and ratings;
positioning a hi-featured board below the mid-feature price points of
established vendors is a good way to get noticed.
There are updates available on the NVIDIA site and on the Silicon
Image site for updating the drivers - AFTER - Vista is installed.
Smells messy - then again, anything RAID has always smelled messy to
me. As soon as you go RAID, you're into the "caveat jungle".
And if you aren't using the "special" add-on ports for RAID, then why
are you using them for the boot device, when there are perfectly good
native chipset S-ATA ports available?
The bottom line is to re-affirm best-practice: NEVER connect anything
other than boot HD and one optical drive at the time the OS is
installed, and either use standard native HD interface or do a LOT of
reading and testing to determine the caveats of add-on interfaces.
Any drive connected to the Sil3132 controller will not be seen
until after the first update or if you want - use the F6 key to install
the Sil3132 drivers during the Vista installation
That's what I was referring to. With no other HDs present, there's a
better chance the installation process will recognise the need for
this and prompt accordingly (i.e. not just the fleeting F-key
opportunity, but actually stop and say "drivers needed or Setup cannot
proceed further"). But if the installation process "knows" it booted
off S-ATA and can see a S-ATA HD over there, it's likely to take 1+1+1
and guess the Occam's Razon answer 2 and carry on from there.
if your drive is connected to that controller (red port on board). The
NVIDIA ports (4) are black colored and clustered together.
I can't explain why using the FDISK routine from a Windows boot disk worked
and partitioning from within WinXP or Vista install routines did not.
Different ways of deriving information, with FDisk being more
BIOS-bound and thus (in this case) more accurate.
One other thing to check is when you reboot and if it looks like it can't
find the hard drive, reboot into the BIOS and be sure the Boot Drive
settings are correct and that the drive is being seen by the BIOS. If you're
using a RAID configuration - that's a whole different setup but if not using
RAID, be sure it's turned off, that IDE drives are enabled and that the 4
NVIDIA SATA ports are enabled. Everything works with the default settings
and with RAID disabled. Did not have to use any tricks or work-around to
get Vista to install once that hard drive was FDISK'd at the DOS level.
OK. You've documented this well; have you submitted it to MS as a
bug? If you can spare the time and effort, it would be worthwhile IMO
Someone else made a post as to where you can find the boot disk
(
www.bootdisk.com). Look under "DOStools", "PARTITIONING" and you will see
"MS Fdisk for Hard Disks Greater Than 64Gig" which you'll need to place on
the boot floppy or CD that you make.
Such FDisk is still limited in ways that don't interfere with setting
active status and deleting "low" primaries - e.g. the capacity input
fields can't take values over 99G
--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
