scbs29 wrote:
Thanks for your reply.
I dont think that I was all that clear in my previous.
The D drive is not a Windows 10 drive. It was the original C: drive
with a Windows 10 Home OS on it.
The SSD was added, made the C: drive and Windows 7 installed on it.
Win 10 was removed from the original C: drive. What was the original
C: drive is now D: with no OS on it. The only OS is the Win7 on C:.
The only thing that appears to be left on the now D: drive is the
Recovery partition, which seems to be for Windows 10. Is there any way
that I could confirm this ?

There are recovery partitions and there are recovery partitions :-)

My laptop has a 15GB partition, with (probably) a PowerQuest partition
type field marking it. It is normally not mounted by an OS. That's
big enough to hold a 12GB image of a C: with Windows OS present on it.
That is the factory restoration partition on an OEM (Dell/Acer/HP) computer

The 400MB style of Recovery, is a WinPE kind of boot material. Similar
to an emergency boot CD. It holds a kind of OS which is not a full
Windows, but is good enough to run a Command Prompt. It has a few
repair tools, bootsect, bootrec, bcdedit, chkdsk, dism, sfc maybe,
and so on. A 400MB partition is too small to contain a full
image of a C: partition, and cannot put any factory materials back.

That's how you tell the difference. A small partition cannot
possibly have a full image of an OS on it. It takes at least
3.5GB to 12GB of materials, to hold some sort of Windows OS.
3.5GB is enough to hold an OS installer WIM.

*******

The Windows boot components consists of:

440 bytes in the MBR. If the BIOS is "pointed" at a non-OS
disk, and you ask it to boot, it "loads" the boot code in
the MBR first.

For Windows OSes, the "boot flag" marks the desired partition
for the MBR to "jump to". If you remove the boot flag, the
MBR cannot try booting from a (presumed) OS partition.
Perhaps the boot flag is still asserted on a partition
on the data disk. On a GPT disk, the presence of a partition
marked as "ESP", that's probably the boot flag on those
systems, and that's the setup you have on your 2TB drive.
It has an ESP (100MB).

Inside the old C: partition, several sectors after the file system
header sector are used as a PBR or Partition Boot Record.
That's the next stage of booting. Perhaps then that goes
looking for an NTLDR or a winload.exe or... whatever.
I don't have all the details memorized.

*******

Then you have to ask yourself, what do we want to achieve exactly ?

1) The BIOS boot order is your first line of defense. The
first disk in the "boot list" in the BIOS setup screen,
should be a pointer to the disk drive you really want to
boot. This selects your "default" OS disk. Which I gather
in your case is Windows 7. If you did this right, there would
never be a reason for the BIOS to "sniff" the old drive.
That's the easiest way to stop the current problem.

2) If you insist on pointing the BIOS boot order at the
non-OS disk, then it's going to try to access the
facilities in the previous section. if you didn't
neutralize the 440 byte boot section, didn't remove
the boot flag or ESP, perhaps that would allow the BIOS to get
part way through some boot sequence. It sounds to me, like
the 2TB drive, the only "work" done to it, was deleting
the C: contents by formatting that partition. When you do that,
most of the boot facilities are there, and then it's going
to die when it tries to hand off to the (missing) C: materials.

If you fix the BIOS, as in (1), then there's really no reason
for the BIOS to get hung up on the data? drive.

If you leave the 2TB drive sitting like this, almost fully
formed, it could try to boot, if you attempt to hand off to
this disk.

Windows 10 HDD

Defacto Boot flag ? OS PBR deleted?
+-----+-----------------+--------------------+-------+-------------+
| MBR | Recovery 400MB | 100MB FAT32 (ESP?) | 16MB | D: 1862.4GB |
+-----+-----------------+--------------------+-------+-------------+

A UEFI BIOS probably knows a 0xEF partition is an ESP, so that
is the defacto "boot flag" on a non-MSDOS partitioned disk.
We'd have to delete the ESP to make a difference there.
Or, we could change the type from 0xEF to 0x07 or 0x0C as
appropriate. (You'd use 0x0C if the partition was FAT and
you still wanted to look in it, to see the .efi file in there.)

The MBR could have the boot code removed, like this.

dd if=/dev/zero of=/dev/sda bs=440 count=1

Since my command does not remove the 0xAA55 in bytes 511 and
512 of the first sector (MBR), the BIOS knows the partition table
is still valid. I suppose it can attempt to read the 440 bytes
of zeros I just injected, but it won't be able to jump to the
ESP on the GPT disk.

When the big partition on the end was reformatted, so you
could use it for data storage, that probably wiped out the PBR.

Now, if you did *squat* to neutralize the data drive, *of course*
it can attempt to boot. If you didn't format the big partition
on the end, and all the Win10 files are there (20GB worth), sure
it could boot.

So what do you want to do exactly ?

The BIOS setup screen is your friend, and for the most
part, simply setting the boot disk list so the Win7
drive is first, *should* have tamed this situation. I
can't see a complicating factor, other than an actual
malfunction in some aspect of the Win7 disk, which is
throwing it onto the Win10 disk instead. Either you
yourself *want* the 2TB disk to continue to be operational,
or you don't. You have to decide whether that second
disk is purely a data disk. If so, you could try
measures, such as changing the ESP partition to
another partition type - that should stop MBR handoff
to the ESP and from there, to the (missing?) Win10 OS.

But we wouldn't be in this mess, unless the BIOS
boot order said "Hey, go sniff that 2TB disk first,
will ya". As that's just asking for trouble. I think
that's probably what is happening. BIOS is asked
to boot the Win10 drive, materials on the drive
are partially damaged, and... eventually we end up
booting the Win7 disk. Eventually.

It's up to you to start, by at least verifying
the BIOS boot order. If you have the motherboard
manual, it might mention which key is used to
enter the BIOS.

The first step with any motherboard, is turning off
the mobo "splash screen" so you can see the text.
But that's a chicken versus egg situation, as you
won't know what key to press, unless you can read
the text at the bottom of the first screen. The
tie breaker for this, is reading the motherboard
user manual, which on an Asus board might mention
the del key is used to enter the BIOS.

Then select "Advanced" to see the full set of
edit menus. Look for a "Boot" section, find the
list of hard drives, and "push" the Win7 drive so
it is first in the list. The BIOS screen will use
the brand, model number, or maybe even size, as
indicators, so you must know the "identities" of
the disks, what's printed on the label of each drive,
to be assured of what to do in that BIOS screen.
Like, right now, my Test Machine has a 500GB,
a 2TB and a 4TB drive in it, so just the sizes
of the drives tells me which is which. The model
numbers of the drives (like "5007" hints at a
500GB drive), I can tell the difference between
them because each model number has a few digits
indicating a size: 500, 2000, 4000.

Any time you hammer the RESET button on the PC,
on an Asus motherboard, you run the risk of
triggering the Overclocker Restore function,
which puts some BIOS defaults back into place.
On modern boards, Asus finally figured this out,
and they *only* reset the CPU clock. Most other
BIOS parameters are unaffected, and that's how
they should have been doing that in the first place.
On older Asus systems, an "overclocker failure"
resets all sorts of ****, and can potentially
foul up the boot order. I've had occasions
where I've had to reprogram the entire BIOS setup,
over and over and over again :-) It's a maddening
feature, when you don't happen to want it...

Paul