M.L. wrote:
> I can't get my XP Pro system to boot the RAID drive.
>
> Specs: Powerspec B647, Intel Core 2 Quad, 4 GB RAM, two 500 GB
> mirrored RAID hard drives (RAID controller drivers integrated into XP
> via nLite).
The only "nLite" that I have know of is used to assist in creating
bootable installation CDs for Windows. Any drivers included in the
customized (or slipstreamed) install CD that you create were added by
you; i.e., you can have nLite add drivers to the install CD so you don't
have to, for example, have to hit F6 during the install startup to
specify a driver for a mass storage device (needed for Windows XP
original to add SATA drivers). nLite doesn't include drivers. *YOU*
give the drivers to nLite which can tell nLite to incorporate into the
slipstreamed install CD.
Integrating drivers using nLite into a customized installation CD for
Windows XP doesn't mean those drivers will actually get installed.
They'll get installed if the install program does a hardware scan and
can detect the RAID controller to then attempt to load the driver types
for it. Do you actually have RAID hardware? If not, a software-only
RAID "driver" means you have to initiate some installation program.
If using software-only RAID, you didn't need to install a driver.
Windows already includes software RAID support. However, you cannot
include the OS partition for Windows in the RAID setup with the
software-only RAID support included in Windows. If you want the Windows
partition included in a RAID setup, you need to have RAID hardware, the
drivers for that RAID hardware designed for your version (and 32/64-bit
version) of Windows, and the software manager to control the RAID setup
(although the separate RAID BIOS for the RAID hardware may be sufficient
if you don't want a GUI interface inside of Windows).
> The RAID BIOS setup utility shows the following:
> Boot: N/A
> Status: Healthy
> Vendor: Nvidia
> Array: Mirror
> Size: 465.76G
Does this mean that you have an actual RAID controller or daughtercard
to do the RAID functions in hardware? Since "nVidia" is mentioned, my
guess is that you have some mobo with a RAID controller on it.
> When I boot to Safe Mode: computer reboots repeatedly after the *.sys
> enumeration list completes.
> When I boot to normal mode: got BSOD 0x000000BE with "An attempt was
> made to write to read-only memory."
You sure that you installed the correct drivers for your RAID hardware
(which you have yet to identify either by naming the brand and model of
RAID card or the motherboard that might include [minimal] RAID support
via a controller chip)? You sure the driver you slipstreamed into your
Windows XP install CD using nLite is actually for Windows XP? Does
"Windows XP Pro[fessional]" mean you are using the 32-bit or 64-bit
version of it? If the 64-bit version, you MUST use a 64-bit version of
drivers.
If the RAID controller is onboard the mobo, did you get the RAID drivers
from nVidia's web site? Or did you get them from the mobo maker's web
site? Just because a mobo maker uses a RAID controller that may be
common to other mobo brands doesn't mean the generic driver from the
RAID controller maker will work on that mobo. The mobo maker can still
make customized configs of the chip (they may use ancilliary support for
extended functions or often don't employ all functionality available in
the chip). First try the RAID controller driver from your unidentified
mobo maker even if the RAID chip maker has a later version of their
generic driver.
> I performed a chkdsk /r in Recovery Mode and no errors were found.
> I performed a fixmbr in Recovery Mode and got some scary warnings as
> follows so I decided not to go through with it:
>
> 1.) "This computer appears to have a non-standard or invalid master
> boot record."
Did you install backup software that usurps the bootstrap code in the
MBR on the first hard disk detected by the BIOS? Some will replace the
bootstrap code with their own "rescue/recovery manager" to let you
perform a restore from you backups when the OS won't boot or is
unusable, like the Recovery Manager available with Acronis TrueImage.
If you are using a multi-boot manager then it, too, usurps the bootstrap
area (first 446 bytes) of the MBR. If you are using an old mobo with a
BIOS incapable of exceeding the old 137GB partition size limit, you
might have installed a disk manager that replaces BIOS functions to
permit partitions larger than 137GB. There are LOTS of tools that will
usurp (and vie for) the MBR bootstrap area (they conflict since only one
can do this) and which replace the standard bootstrap code added by
MS-DOS/Windows.
> 2.) "Fixmbr may damage your partition tables if you proceed. This
> would cause all partitions on the current hard disk to become
> inaccessible."
While possible that this is performed by some good utilities, there is
malware that will replace the bootstrap code in the MBR along with
moving around the position of the partition table entries so they are at
non-standard offsets in the MBR. This means you MUST have that
particular bootstrap code which knows where to find the non-standard
offset partition table entries. Replacing the bootstrap code with the
standard code means it expects the partition table entries (each one
describes the start and extent of each partition) at standard offsets
but it will screw up because those entries are not at their standard
offsets. It may also be possible that some whole-disk encryption
utilities might use non-standard partition table offsets; i.e., not only
do they encrypt the partitions (so you must enter a boot-time password
to access the partitions) but they could move the partition table
entries around to thwart anyone that attempts to replace the bootstrap
code (with the encryption program) with standard code. Without knowing
the history of your hard disk(s), tis difficult to know what might've
replaced the bootstrap code and possibly moved around the partition
table and its entries in the MBR.
> Can someone make sense of the next steps I should take to get XP to
> boot properly? Thanks.
Have you tried installing Windows *without* the RAID support that you
slipstreamed into the install CD? That is, slipstream another CD using
nLite that does NOT have whatever RAID drivers/software that you
slipstreamed in before. Just see if you can get Windows to boot from
your non-RAID setup. If you are using SATA drives, and if the gold
(original) version of Windows, then you still need to slipstream in the
SATA drivers. I forget which but recall that SATA drivers might've been
included in SP-2. Even if using hardware RAID on the mobo, if you are
using SATA drives then you need to use the mobo maker's SATA RAID
support. It's possible they have a separate driver for IDE versus SATA
for RAID support. My old Abit NF7-S v2 is like that. It can be
confusing as to which driver you are supposed to install, an you even
have to watch out for the non-v2 versus v2 mobo differences for drivers.
Software-only RAID means you don't include the Windows partition. That
is, you first had to install WIndows and then you can RAID the *other*
partitions. It's possible the RAID BIOS available with the onboard RAID
chip may let you setup a RAID 1 config; however, that is probably
something you should do after you first get Windows working. First do a
Windows install *without* doing anything RAID. Make sure that works
before you then later attempt to mirror using RAID 0 (which would have
to be done in the RAID BIOS or with a RAID manager GUI utility
separately ran in Windows since Windows itself doesn't support RAID 0
for sofware-only RAID). I don't know if you really want to edit system
files, as noted in:
http://www.vttoth.com/mirror.htm
Most onboard RAID controllers don't have full RAID functionality; i.e.,
they're crippled controllers that assist in software-only supported RAID
functionality. You may need to get a real or full RAID controller card
so you can use its boot-time manager (RAID BIOS) to include the Windows
partition in a RAID configuration. The software-only RAID support
available in Windows only supports RAID 0 (striping) and won't include
the Windows partition. That's because Windows must be installed before
RAID 0 gets setup, but that means the Windows partition already exists
and cannot be included in a striping setup. It is possible with decent
hardware RAID to then take that Windows partition and included it in a
RAID config; however, some less-than-capable RAID controllers will end
up destroying the contents of the partitions when you add them into a
RAID config (I don't remember if this is true for striping but have seen
this when using RAID 3/5, so you needed a RAID controller that would
preserve the content of the partitions/volumes when added to a RAID
setup).
It's been a long time since I experimented with RAID with non-server
versions of Windows. The workstation versions just don't have decent
software-only RAID support. As I recall, when considering a non-server
version of Windows to include its OS partition in a RAID setup meant
having to carefully consider what RAID controller I would add to the
computer since the onboard RAID controller were incapable or resulted in
destroying the contents of the volumes when added to a RAID setup. The
onboard RAID controllers just couldn't do real hardware-level RAID
support (and even some add-on cards simply reuse these same elemental
RAID controllers).
http://www.pcstats.com/articleview.cfm?articleid=830&page=5
Even if you identified your mobo and its RAID hardware, it's likely that
I don't know its specific capabilities or how that mobo maker happened
to extend or disable (not use) some of the RAID chip's functionality.
The best place to ask is in the mobo maker's forums to see what other
users have done with that same model mobo and ask what drivers they used
and with what type of hard disks. My first guess is that you simply
slipstreamed in the wrong drivers for both SATA and probably for RAID,
too.
There can also be problems if you have mixed both IDE and SATA hard
disks inside the same computer. The BIOS may not detect the SATA drive
before the IDE drive even if you change the drive boot order in the
system BIOS. In my setup and to get SATA working even with the SATA
driver slipstreamed into the install CD, I had to set the BIOS boot
drive order to find SATA devices before IDE devices but also had to
disconnect power from the IDE drive so the SATA drive actually got used
for the Windows install. There's too much unknown about your hardware
setup. Also, I don't know if you are attempting to use software-only
RAID support included in Windows XP (which will be slow, only supports
RAID 1 striping) or are using hardware RAID support.
In a reply to your own original post (rather than burying it under this
subthread) so others know the actual details of your setup, identify the
following:
- Make and model of motherboard.
- RAID controller chip on the mobo, or RAID controller card (make &
model).
- Are all hard disks IDE or are all SATA? Is there a mix of IDE and
SATA hard disks?
- Where you got the SATA drivers (if using SATA drives).
- Where you got the RAID drivers (mobo maker or RAID chip maker).
- If Windows was already installed and then you tried using RAID. Get a
non-RAID version of Windows working first before adding RAID. Do
mirroring afterward (as long as the mobo or chip maker state that
doing so is non-destructive, or you want to experiment on a fresh
install of non-RAIDed Windows with no user data to lose to do the
destructive checking yourself).
- Which service pack level for Windows on the install CD.
- Are you relying on just the software-only RAID support included in
Windows, or a RAID manager app provided by the mobo maker, or relying
just on the RAID BIOS settings?
- If using hardware-level RAID (i.e., in a RAID BIOS or a Windows GUI
utility that interfaces with the RAID BIOS).
- Does Windows install successfully if not using any RAID config?
- After installing Windows (in a non-RAID config), did you ever install
the chipset drivers provided by the mobo maker?
You do realize, right, that mirroring is only for hardware recovery, not
for data recovery? Anything you do to your data on the primary drive
will get reflected on the mirrored drive. So if you lose your data on
the primary drive (delete it, malware corruption, accidental format,
etc) then it is also lost on the mirrored drive. Mirroring is NOT used
for data recovery. It is merely to provide hardware recovery where you
can remove the defective primary drive and slide in the mirrored drive
in its place to get your host immediately working again. You will still
have to do backups if you want data recovery.
If you use imaging backup programs then do you really need to use RAID
mirroring? Acronis TrueImage, for example along with others, will let
your do logical file backups but it also lets you do image backups of
your partition(s). Rather than do sector-by-sector (physical) images,
it can do logical images so you can do full or incremental image
backups. Incrementals take a lot less space. You could then use your
2nd hard disk as a backup location for your full/incremental images.
Then when your primary hard disk fails, you can boot using the Acronis
install CD or a rescue CD to recover the image from your backup drive
onto your new hard disk used to replace your defective old hard disk.
So not only do you have the availability of backups for file or image
restores but you can also use those image backups to re-image a
replacement hard disk. Yes, the restore of an image would take longer
than simply swapping the mirrored drive to be the primary drive but
mirroring doesn't give you any data backups.
Mirrored drive: For hardware recovery only. You get a replacement drive
that has exactly whatever the old (but now defective) primary drive had
on it at the time of its failure. You have no means of recovering old
versions of files or deleted/corrupted files. Whatever is on the
primary drive is what is also on the mirrored drive. Mirroring is only
for hardware recovery. It is not usable for data recovery.
Image backups: For both hardware and data recovery. You have both data
backups and a means to restore an image onto a replacement drive;
however, you will lose changes to files made since your last full or
incremental image backup. If you, say, do a monthly full image backup
and daily incremental backups then you would, at most, lose a [partial]
day's worth of changes. In case the latest image is not what you want,
you can select an earlier image. For example, you might've installed
something that so corrupted Windows as to make it unusable. Mirroring
will make the copy of Windows on the mirrored drive just as unusable.
With imaging, you can elect to restore the latest image backup or an
earlier image backup to get back a working copy of Windows.
Mirroring doesn't make sense on a workstation. Image backups make more
sense. Servers have many users accessing them so hardware recovery is
important to maintain up-time for the server. A workstation is in use
by just one user at a time so there is no concurrent multi-user demand
for that host and up-time is not nearly as critical as for a server.
Imaging gives you both data and hardware recovery albeit slightly slower
hardware recovery than when using mirroring. Mirroring gives you no
data or file recovery. Whatever gets screwed up on the primary drive
gets mirrored to the other drive. If Windows won't boot or you lose
data on the primary drive, the same symptoms will exist on the mirrored
drive.
Rather than run daily incremental image backups and having to worry
about losing and data that was created or changed before the next daily
image backup, simply schedule the incremental image backup to run every
hour or even every 10 minutes. At such short intervals, the incremental
image will be very short-lived because little has changed in that time.
Of course, you'll need more space on the backup drive. Also, make sure
to use a *different* physical disk on which to save your backups, like
another hard disk (for speedy backup time). After all, if the primary
hard disk fails then any backups save in the same or different
partitions on that same hard disk are lost. Since you are considering
mirroring, you already have another hard disk. Although image backups
are compressed, the backup disk should have a capacity that exceeds the
size of the partition(s) that you are imaging so you can store a history
of images from which to restore (for hardware recovery) or from which to
extract files (for data recovery).