I don't know if I've ever located a third party tool, to take the
place of FIXMBR or FIXBOOT. (Like, a user friendly tool.)
If I was stuck, and needed to "repair" the MBR, I know I could copy
sector 0 from one drive to another, with the port of "dd". But doing
so, could wipe out the partition table if I was careless.
http://www.chrysocome.net/dd
The article on this page, they seem to think you can write a fraction of a sector.
(Note - there should be no "#" in front of the command.) The sample command
here, is copying 446 bytes of data, implying fractional sectors works.
http://www.cyberciti.biz/faq/howto-copy-mbr/
dd if=/tmp/mbrsda.bak of=/dev/sdb bs=446 count=1
The syntax for the Windows "dd" port is a bit different than
it would be for Linux. First, you do this, to get the disk names.
dd --list
You can compare the output of dd --list to the Disk Management
labeling scheme, and the two methods should correlate. (I.e.
You could predict the names, with a little practice.)
On my machine, I have two disks. And these would be the
references of interest, out of the dd --list output.
\\?=Device\Harddisk0\Partition0
\\?=Device\Harddisk1\Partition0
These would be references to the entire disk, starting at sector 0.
Say I needed to copy the boot code, from the MBR of disk0 to disk1.
First, I backup the disk1 MBR, in case I make a mistake. The MBR is
512 bytes total, and I want to save all of it just in case. The
"bs" stands for block size, and the "count" is a count of blocks.
dd if=\\?=Device\Harddisk1\Partition0 of=C:\disk1mbr.bak bs=512 count=1
Then, I copy the first 446 bytes, from one disk to the other.
dd if=\\?=Device\Harddisk0\Partition0 of=\\?=Device\Harddisk1\Partition0 bs=446 count=1
That would be the equivalent of FIXMBR, using a "good" chunk of
sector 0 boot code from disk0, for disk1. Naturally, if
disk0 had a Linux install, and disk1 had a Windows install,
this wouldn't work. I can only do it with confidence, because
I know the exact same OS is on each disk, and the MBR boot code
required is the same.
You're using an array, but the array will still be referred as a volume,
so it should be of the form \\?=Device\Harddisk1\Partition0 and you can
compare how Disk Management labels things, to the dd --list output.
Disk Management should be referring to your array as a virtual volume
as well.
You run "dd" from the command prompt. It's not a GUI tool. It's
quite powerful, and accepts "seek" and "skip" parameters as well,
allowing a source block of data, to be written anywhere on a
second drive (or file, if you use file syntax). I've even used the
tool, as a crude "disk editor", snipping gigabyte chunks one at
a time, and examining a gigabyte of data with my hex editor.
Loads of fun.
*******
When you start the computer, see if you can determine the key to
press, to enter the BIOS setup. On my Asus motherboard, it's <DEL>.
On my Asrock and my laptop, it's probably <F2>. Usually, the
key to press, is printed on the first screen full of text, down
near the bottom of the screen.
Look for a page that mentions "Add-On ROM", and that may help
the EEPROM on the SIL3124 load during POST.
Add On ROM Display Mode [Force BIOS] <--- Display array status during POST ???
Interrupt 19 Capture [Enabled[ <--- Should enable option ROMs, like SIL3124...
19 decimal is the same as 0x13 hex, and
they used decimal just to confuse matters.
The add-on ROM is Extended INT 0x13 routine.
The last setting in particular, would affect the ability to boot
from the array, but would not prevent the SIL3124 from being
detected as a "data array" by an OS driver.
If you have too many controller cards on a server, and the
Add On ROMs all load, you can exhaust the tiny memory area
reserved for them. In such a case, you'd need to disable
the unused controllers, so the RAM can be freed up for the
controller being used to boot. (Otherwise, it is a first come
first serve scheme, and the card you want to load, is always the
one that got screwed out of space to load to.) Once the system
is booted, that RAM area is no longer of concern. The RAM area
allocated is only 128KB, and it's down in the "640K" region.
*******
If you have a hex editor, you can examine the backup copy of the
MBR first, and see if it has a "standard" 446 bytes of code.
Each Windows OS could have slightly different code there.
There is at least one web page, that gives a breakdown
of what that code is actually doing.
HTH,
Paul