Can someone recommend an eSATA PCI host adapter that has a built in BIOS
that can be configured in a preboot environment to make the card the boot
device on the system?

Ideally the card should have four eSATA ports and supports multiple SATA
drives on each connection.

--
W


"Paul" wrote in message
...
W wrote:
I am trying to transfer the boot partition from a Windows XP SCSI drive
to a
RAID 5 SATA volume on an Addonics Compact RAID enclosure. I created a
large RAID 5 on the Addonics Compact RAID, and then I used a disk
partition
management utility to make an image copy from the boot partition on C:
to
the Addonics Compact RAID partition. I made the copy before Windows
boots, so there is no issue here about files on the source partition
being
locked or used. The image made was a perfect copy of the original.

After creating the new boot partition, I disconnected the SCSI drives
and
attempted to boot from the new partition. Even when I specify the new
partition explicitly as the boot device in the system bios, all attempts
to
boot from it give back the error that it is not a system disk, and the
boot
process for Windows never starts. Is there a trick to making Compact
RAID
the boot device on a Windows system? Perhaps some adjustment needs to
be
made into boot.ini? Perhaps I need to explicitly disble BIOS in the
Adaptec host adapter?

There is no BIOS boot environment for the eSATA card I am using, which
appears to be based on the Silicon Image 3124 chipset.


So you installed a driver for the Addonices, early on, while the SCSI
drive
was still the boot source and running the system ? You'd need that
driver in place, so you won't get something like an "Inaccessible Boot
Volume"
after the cloning of the partition is finished.

Other than that, you'd want to compare the source MBR and dest MBR. And
whether the same partition table entry was used. (If not, boot.ini might
need to be repaired, on the new array.)

In this example, in line #2 you can see the boot flag is set. So that
second partition is the one to boot from. This is a "Windows specific"
thing,
in that the MBR boot code installed by Windows, uses the boot flag info.
Other OSes, such as Linux, don't look for the boot flag. They have
another means of locating what to boot from.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

You'd also need the proper MBR code to be copied over (that's the 440
bytes of
the MBR, just before the partition table entries. The MBR is sector 0 of
the
disk. The MBR code can be installed by using the recovery console and
"FIXMBR".
The cloning (not just copying) of the partition, should have taken care of
the partition boot sector (which would otherwise be fixed by "FIXBOOT",
but
that really shouldn't be needed in this case).

If you just "copy" files from the original disk, to the RAID 5, that
would not include the partition boot sector. If you use a utility
that transfers the entire partition, then it should have covered the
partition boot sector. But if you're crafty enough, you could probably
manage to transfer files from the source disk to the dest array, and
avoid properly copying the partition boot sector. Partition managers
probably wouldn't miss such a step.

In the BIOS, you'd have to make sure the BIOS option that causes
option ROMs to load, is enabled. There are some motherboards, where
that is disabled and needs to be turned on. Lots of retail motherboards,
already have several non-chipset chips added, and the option is turned
on so those can work. But if the motherboard is stripped down, and
had a simplified BIOS, that option might be turned off. It is needed,
so the Extended INT 0x13 routine in the SIl3124 card EEPROM, gets loaded,
and then the BIOS will have code it can use to read the RAID 5.
Eventually,
the Windows driver for the RAID 5 takes over (that's the driver you
installed, before the cloning step).

Paul