So if I, as you said above, disconnect the IDE drive and boot off
the
Windows CD it will make the SATA drive bootable? The install will
re-wirte the boot.ini? Or can I just edit the boot.ini with
wordpad?
You boot from the install CD, select Recovery Console mode, and use
the bootcfg utility to alter the boot.ini file. You will use Recovery
Console mode for the first instance of Windows, the one on the IDE
drive, because that is where you need to edit the boot.ini file. It
is a text file (but with hidden file attribute) so you could use a
text editor but I don't recall if Recovery Console mode has one. I
doubt you will have access to wordpad.exe (or notepad.exe). In
Recovery Console mode, you would "attrib -h boot.ini" to make the file
unhidden, edit it with a text editor, then "attrib +h boot.ini" and
reboot. With bootcfg, you would run:
bootcfg /copy (make backup copy of boot.ini)
bootcfg /scan (to see what it finds)
bootcfg /rebuild (includes in boot.ini each instance of
Windows that it finds)
bootcfg /list (show what got put into boot.ini)
bootcfg /delete /id <value> (get rid of the old entry for Windows
on the IDE drive)
Because you have 2 Windows installs, one on the IDE drive and another
on the SATA drive, the boot.ini will list both so you'll have to
select the one on the second hard drive. Start -> Help and Support
has a lot more info on bootcfg. Once you boot using the SATA drive,
you could then go edit the boot.ini over on the IDE drive to remove
the ARC path listed for the instance of Windows over on the IDE drive.
You could also significantly reduce the size of the Windows partition
on the IDE drive since all you are using over there is the loader and
boot.ini files (i.e., you don't need the rest of Windows on the IDE
drive). The assumption is the booting into Recovery Console mode
means bootcfg can see the SATA drive (i.e., no drivers needed).
Of course, after I make the SATA drive bootable I still have the
issue
of there being no SATA controller in the "boot sequence" of the
BIOS.
I'll have to check with Dell support on this.
You cloned the IDE drive to the SATA drive. That means the boot.ini
on the SATA drive is identical to the one on the IDE drive. If you
disconnect the IDE drive, the SATA drive becomes the first physical
drive that can be detected, so the boot.ini on it should work - EXCEPT
that your BIOS doesn't let you boot from a SATA controller on that
motherboard. If your BIOS let you boot from the SATA controller, you
could boot from the SATA drive as it is currently cloned as long as
you never connected a hard drive to any of the IDE ports (while they
are enabled in the BIOS). To fix for now, one solution would be for
you to add a SATA controller card that has the option in its BIOS to
boot from connected a SATA drive connected to it. Then do not attach
an IDE drive to the IDE ports, disable the IDE ports (probably not an
option if you have CD/DVD drives), or see if one of the boot sequences
in the BIOS does *not* list [IDE] hard drives.
The problem with above is that you lose your IDE drive. You could get
an IDE controller card to use with the IDE hard drive because the
system BIOS won't use it as a boot drive (and make sure the IDE
controller isn't configured to boot from any drives connected to it).
This gets to be a mess of having to add 2 controller cards: one for
the SATA drive (so you can boot from it) and another for the IDE drive
(so the system BIOS won't see it on a mobo IDE port).
What FG is getting to is having an install of Windows on the IDE drive
(connected to an IDE port on the mobo) and use it to load the rest of
Windows on your SATA drive. You could even reduce the size of the
partition on the IDE drive since all you would need there is space for
the partition's boot sector and the loader files for Windows. What
you would have then is: the BIOS completes its POST, it finds the
first physically detectable hard drive (your IDE hard drive) on a mobo
IDE port, it loads the bootstrap program in the MBR (1st physical
sector) from that IDE hard drive and passes control to it, the
bootstrap program then reads the partition table in the MBR to find
which is the "active" marked partition and loads that partition's boot
sector (first one) and passes control to it, and the partition's boot
sector is the OS loader which reads the boot.ini file. That partition
boot sector loader reads the boot.ini file to find where is the rest
of the operating system. You would have to edit the boot.ini to point
to the second hard drive, the SATA drive, which would be disk(1), the
second hard drive, to load the rest of the OS from there.
Windows' loader can be on one drive (which Microsoft calls the system
partition) but the rest of it can be on the same or different
partition or drive (called the boot partition). See
http://support.microsoft.com/kb/100525/en-us. Because of limitations
in your BIOS, you would have the BIOS load the Windows loader on the
IDE drive which then loads the rest of Windows on the SATA drive.
Obviously this chaining is susceptible to a loss of your IDE drive. I
personally don't like this chaining. You are slicing the OS across 2
drives: loader on the IDE drive and rest of the OS on the SATA drive.
A bit cleaner would be to step back one step in the boot process and
replace the MBR bootstrap program with a multi-boot manager program.
Rather than have the standard MBR bootstrap program which can only
read from partitions on the same drive (which is the first physically
detected drive by the system BIOS), use a multi-boot manager because
they can load partition boot sectors that are on different drives,
plus they can load partition boot sectors in logical drives in
extended partitions (whereas the standard MBR bootstrap can only load
boot sectors for primary partitions). The GAG Boot Manager (at
http://gag.sourceforge.net/) is free. In fact, you could leave
Windows installed on both your IDE and SATA drives and switch between
them (until you decide to get rid of one of them). The only change
you would have to make is to edit the boot.ini on the SATA drive so
the ARC paths listed in it point to the SATA drive which would be your
second drive so disk(0) would change to disk(1). I believe it even
has a drive mapping feature which means it will boot from the SATA
drive, the second drive, but make it look like the first drive so you
don't even have to edit the boot.ini file. I haven't explored that
feature. With GAG, you don't even need it to replace the MBR
bootstrap program since you can boot from its bootable floppy and run
that boot manager from there, but it is more convenient to copy it to
the hard drive's MBR bootstrap area rather than have a floppy in the
drive on each boot (but it permits you to configure the bootup
sequence on the floppy and then copy it anytime later should the MBR
bootstrap area get overwritten). Nothing of GAG resides in any
partition so it is completely independent of any OS. That means you
can delete, wipe, resize, move, or whatever to your partitions and
never touch GAG.
So you have lots of solutions (read the last one first; I thought
about it after all the rest):
#1: Lose the IDE drive. Get a SATA controller card and use it to boot
from the SATA drive. Since the SATA drive will be the first physical
hard drive, the boot.ini on it (cloned from the IDE drive when it used
to be the only drive) should work okay. You end up getting a
controller card.
#2: Keep the IDE drive but use an IDE controller card for it.
Configure that IDE card to *not* boot using any drives connected to
it. You get the keep the IDE ports on the mobo enabled to use for
your CD/DVD drives but the system BIOS has no hard drive from which it
can boot. You might want to see if one of the BIOS boot drive
sequences does *not* include hard drives so you don't waste time
waiting for the BIOS to try to find one when none are connected to the
mobo's IDE ports. Get a SATA controller card for the SATA drive and
configure that card's BIOS to boot from the SATA drive. Since it is
likely that the IDE card's drives will be detected first, you will
need to edit the boot.ini on the SATA card to the ARC paths point to
the second drive, the SATA drive; i.e., change disk(0) to disk(1).
See
http://support.microsoft.com/kb/291980/en-us. You end up getting
2 controller cards and having to edit the boot.ini file on the SATA
drive.
#3: Keep the IDE drive on an IDE port on the mobo. Keep the SATA
drive on the SATA port on the mobo. The BIOS boot drive sequence uses
the IDE drive's MBR bootstrap program. That looks in the partition
table to find the active primary partition (i.e., your old Windows
install on the IDE drive) to load that partition's boot sector (which
has the OS loader). That loader reads the boot.ini file to find the
rest of the OS, so you will need to edit the boot.ini file to have the
loader look on the SATA drive for the rest of the OS. Change disk(0)
to disk(1). You can then delete all but the root directory files in
the Windows partition on your IDE drive and resize it (to make
smaller) because you won't be using all of that OS over there. You
just need its loader and boot.ini files. I believe all the required
files are in the root directory but haven't verified that yet. The
boot.ini isn't used on the SATA drive because it was used on the IDE
drive. You end up with no extra controller cards but do have to edit
the boot.ini file on the IDE drive to point at the SATA drive, and you
use the IDE drive to boot from the SATA drive. If you lose the IDE
drive and remove it, the SATA drive becomes disk(0) so the boot.ini
that was left over there would work (because you are back to #1
above).
#4: Keep the IDE drive on an IDE port on the mobo. Keep the SATA
drive on the SATA port on the mobo. Replace the standard MBR
bootstrap program with GAG or another capable multi-boot manager (GAG
doesn't reside in any partition, however, so whatever you do with the
partitions won't affect the operation of GAG). Because you are no
longer using the remnant of Windows on the IDE drive (to use its
loader to read that boot.ini file), you could blow away that
partition, reformat it, merge it, or whatever you want. Configure GAG
to boot from the SATA drive. GAG will be in the MBR (first sector) of
the IDE drive but this eliminates from the chain of having to then
load a partition's boot sector (to use the Windows loader to read that
boot.ini). You end up with no extra cards and you might not have to
edit the boot.ini file on the SATA drive. However, I do see a flaw
with this setup: the SATA drive must be visible from a DOS shell. The
GAG boot manager needs to be able to see the SATA drive, its
partitions, and read into those partitions. It doesn't actually use
an OS to run itself (the BIOS loads it into memory to run) but it also
won't have any SATA drivers included. If you can see the SATA drive
from a DOS bootable floppy (get one at
http://www.bootdisk.com) then
GAG can see it, too.
#5: The easiest solution: Check with Dell if they have a BIOS flash
update for your model which would add the SATA item to the boot drive
sequence. Then all you would have to do (after the BIOS flash), and
assuming you keep the IDE drive connected to a IDE port on the mobo,
is to edit the boot.ini file on the SATA drive since it would be the
second physical drive; i.e., change disk(0) to disk(1). You could
even boot from your IDE drive for now so you could edit the boot.ini
file (on an NTFS partition, if you used NTFS) and then change the boot
sequence to the SATA drive whose boot.ini is now correct; else, you
need to boot into Recovery Console mode (to load the OS on the SATA
drive) to use the bootcfg command to update the boot.ini. You end up
flashing the BIOS, change the boot drive sequence in BIOS, and edit
the boot.ini on the SATA drive. Dell lists a BIOS update dated
3/17/2006 (
http://tinyurl.com/nxk4q, but YOU should make sure this is
the right one). Could be the update includes SATA support.
Definitely check if a BIOS update will eliminate all the headaches by
adding SATA to the boot drive sequence option in BIOS. Then all
you're left with is having to edit the boot.ini file on the SATA drive
(and you don't need to keep anything of Windows on the IDE drive so
all that space gets recovered).
You do have backups, right?