W wrote:
"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.
Yes, the Addonics was installed and working while the source volume was
still the active boot device.
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).
I will try to schedule FIXMBR, but is there any utility that I could run
while Windows is booted on the source volume to patch the MBR of the
destination volume under Windows?
I despise booting from the repair CD. It's a non functional environment,
slow, etc.
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.
I used Acronis Disk Director 2011, which appears to have done a mirror copy
of the boot partitions. I explicitly checked that the new boot volume was
marked Active in Windows Disk Manager.
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).
You might be onto something there. My eSATA card is a four port host
adapter, and not native on the motherboard. Since I don't have a BIOS
environment user interface for managing that board, I don't really know what
capability it does or doesn't have to become a boot device.
--
W
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