B
BobbyM
Understand - sorry if I confused you.
J
Juan Wei
BobbyM has written on 8/24/2013 7:41 PM:
And then won't the SSD be assigned its own unique letter? (Mine is M:.)
Don't I need to have both drives connected during the cloning process?
And then won't the SSD be assigned its own unique letter? (Mine is M:.)
B
BobbyM
Of course they both have to be connected during the cloning process but
when it's over, you need to choose which is going to remain connected.
P
Paul
To re-iterate this advice...BobbyM said:
When you copy a disk, like Disk 0 to Disk 1...
+-----+------------+
| MBR | C: | Disk 0
+-----+------------+
+------------------+
| | Disk 1
+------------------+
And it comes time to boot Disk 1. Then Disk 1 should
be connected all by itself. Disk 0 should be disconnected
during the first time that Disk 1 is booting. This
prevents drive letter confusion. If you don't do this,
a drive can end up with the system on D: .
+-----+------------+
| MBR | C: | Disk 1 Booting by itself the first time.
+-----+------------+
Later, if you shut down and reconnect Disk 0
(after Disk 1 has booted at least once by itself),
that's OK. This would be safe later, to boot either
Disk 0 or Disk 1. You could select Disk 0 or Disk 1, using
the BIOS setup screen and boot order selection. Amongst
other methods. The one that boots will be C:, the
other one will have some other letter (as the other
one isn't the system partition at the moment,
that isn't important).
+-----+------------+
| MBR | C: | Disk 0
+-----+------------+
+-----+------------+
| MBR | C: | Disk 1 (Has booted at least once, by itself)
+-----+------------+ (Now safe to use next to Disk 0)
HTH,
Paul
T
Timothy Daniels
"Juan Wei" needs more info:
boot process -
First, the BIOS runs the hardware-finding process, and eventually
it goes down the boot priority list looking for a device with an MBR
(Master Boot Record).
When it finds a valid MBR, it passes control to it.
The MBR inspects the partition table on the device to see which
primary partition is marked "active".
The MBR passes control to the boot sector of that primary partition.
The boot sector has a boot manager which looks at the boot menu
to see where the OS is that should be booted.
The boot manager passes to the loader the location (or identity) of
the partition that contains the OS to be booted, and the loader loads
and launches the OS.
In your case, you cloned the OS-containing partition contents to
the new partition in the SSD, and there aren't any boot files there to
boot it because it doesn't have a boot sector and the SSD probably
doesn't have an MBR. You also probably haven't designated the SSD
as having the highest boot priority, so control still goes to the MBR
on the HDD, which still points to the 100MB system partition on the
HDD. Somehow, it's smart enough to look around and see the SSD
and to put it on the boot menu - if I understand you correctly - but
that partition on the SSD still doesn't have a boot sector, so it doesn't
boot when you choose it manually for booting.
So, after you cloned the OS-containing partition on the HDD to the
new partition on the SSD (or even after you created the new partition),
you should have marked that partition on the SSD "active". Then you
should have done the following 2 procedures (order being unimportant):
1) restarted and entered the BIOS and either disabled the HDD
or set the SSD as the highest priority drive in the boot priority.
2) Used the utilities in the Win7 installation DVD to place an MBR
at the head of the SSD, and to make a boot sector in the new
partition with boot files in it. There are a couple automatic processes
that are available on the installation DVD, but when they run you don't
know what they're doing. It's best to run the Command Prompt utility
and to then run explicit command line utilities yourself. You may have
to experiment a little bit, but that's OK because mistakes here are not
destructive. Utilities to try are:
"bootrec /fixmbr" to put an MBR in the highest priority drive (which is
at this time the SSD), or . . . into the only drive enabled (I don't know
which condition is necessary)
"bootrec /fixboot" to put a boot sector and its files in the partition
that is marked "active".
You could also use "bootsect" to do the latter, or
"bcdboot" to set up the BCD's boot menu - you'll have to experiment.
You could also could have used "diskpart" to create the new partition
on the SSD and to mark it "active" - as usual, there are several ways to
do everything. When in doubt, use the /help option with the command
to get help with the syntax.
Once you got the OS on the SSD running for its first time in
isolation (i.e. without a view of its "parent" OS), you can shutdown and
re-enable the HDD (if it had been disabled), assuring that the SSD is
at the highest boot priority, and then letting the clone OS on the SSD
boot up. In such a scenario, the "parent" OS will not be running, and
will be viewed by the clone as just a hierarchy of files. It helps at this
time put folders on the desktop of each OS with names that tell which
OS it is since both will look identical and each will think of itself as the
"parent" of the other. And remember that when each runs, it will call
its own partition "C:".
If you want to run the 2 OSes in a dual-boot situation, you can run
BCDedit from the OS command prompt (as administrator) to build the
boot menu, but that's a tutorial for another thread. Otherwise, you can
choose which OS to run simply by controlling the drive enablement or
the drive boot priority in the BIOS during startup. (Remember that
having other devices with media - e.g. optical drive, USB drive - can be
confusing, so leave those unoccupied.)
*TimDaniels*
It helps a lot to know the boot process, at least the legacy BIOSTimothy Daniels has written:
Well, I restarted the computer and got a boot menu. I then selected the
SSD and it did boot.
I would certainly volunteer all those things if I had enough knowledge
to recognize them without having them pointed out to me.
Thanks.
boot process -
First, the BIOS runs the hardware-finding process, and eventually
it goes down the boot priority list looking for a device with an MBR
(Master Boot Record).
When it finds a valid MBR, it passes control to it.
The MBR inspects the partition table on the device to see which
primary partition is marked "active".
The MBR passes control to the boot sector of that primary partition.
The boot sector has a boot manager which looks at the boot menu
to see where the OS is that should be booted.
The boot manager passes to the loader the location (or identity) of
the partition that contains the OS to be booted, and the loader loads
and launches the OS.
In your case, you cloned the OS-containing partition contents to
the new partition in the SSD, and there aren't any boot files there to
boot it because it doesn't have a boot sector and the SSD probably
doesn't have an MBR. You also probably haven't designated the SSD
as having the highest boot priority, so control still goes to the MBR
on the HDD, which still points to the 100MB system partition on the
HDD. Somehow, it's smart enough to look around and see the SSD
and to put it on the boot menu - if I understand you correctly - but
that partition on the SSD still doesn't have a boot sector, so it doesn't
boot when you choose it manually for booting.
So, after you cloned the OS-containing partition on the HDD to the
new partition on the SSD (or even after you created the new partition),
you should have marked that partition on the SSD "active". Then you
should have done the following 2 procedures (order being unimportant):
1) restarted and entered the BIOS and either disabled the HDD
or set the SSD as the highest priority drive in the boot priority.
2) Used the utilities in the Win7 installation DVD to place an MBR
at the head of the SSD, and to make a boot sector in the new
partition with boot files in it. There are a couple automatic processes
that are available on the installation DVD, but when they run you don't
know what they're doing. It's best to run the Command Prompt utility
and to then run explicit command line utilities yourself. You may have
to experiment a little bit, but that's OK because mistakes here are not
destructive. Utilities to try are:
"bootrec /fixmbr" to put an MBR in the highest priority drive (which is
at this time the SSD), or . . . into the only drive enabled (I don't know
which condition is necessary)
"bootrec /fixboot" to put a boot sector and its files in the partition
that is marked "active".
You could also use "bootsect" to do the latter, or
"bcdboot" to set up the BCD's boot menu - you'll have to experiment.
You could also could have used "diskpart" to create the new partition
on the SSD and to mark it "active" - as usual, there are several ways to
do everything. When in doubt, use the /help option with the command
to get help with the syntax.
Once you got the OS on the SSD running for its first time in
isolation (i.e. without a view of its "parent" OS), you can shutdown and
re-enable the HDD (if it had been disabled), assuring that the SSD is
at the highest boot priority, and then letting the clone OS on the SSD
boot up. In such a scenario, the "parent" OS will not be running, and
will be viewed by the clone as just a hierarchy of files. It helps at this
time put folders on the desktop of each OS with names that tell which
OS it is since both will look identical and each will think of itself as the
"parent" of the other. And remember that when each runs, it will call
its own partition "C:".
If you want to run the 2 OSes in a dual-boot situation, you can run
BCDedit from the OS command prompt (as administrator) to build the
boot menu, but that's a tutorial for another thread. Otherwise, you can
choose which OS to run simply by controlling the drive enablement or
the drive boot priority in the BIOS during startup. (Remember that
having other devices with media - e.g. optical drive, USB drive - can be
confusing, so leave those unoccupied.)
*TimDaniels*
T
Timothy Daniels
Timothy Daniels said:
This where I get hazy on my understanding of what you observe.
The boot sector of the 100MB system partition on the HDD originally
directed the loading and launching of the OS which resided in the
big partition on the HDD. Are you sure that this is not still happening,
i.e. that the OS on the HDD is not the one running?
The reason I ask is that if the 100MB system partition on the HDD
has found the OS on the SSD and has added it to the boot menu
in the boot sector of the 100MB system partition, the clone partition
on the SSD won't need a boot sector to be loaded and launched
successfully. So do you know which OS is really running?
C
Char Jackson
I only skimmed your reply, so I hope I got the jist of it. I think you're
saying that resizing a partition (making it smaller) during a clone
operation is more risky than not doing so, and perhaps that's true in an
academic sense. In real terms, however, nearly every cloning program has
been doing it by default for nearly as long as I can remember, which
probably wouldn't be the case if issues were at all common.
C
Char Jackson
Macrium is far from unique when it comes to shrinking while cloning. This
has been a common cloning software feature for a very long time now, pretty
much across the board.
P
Paul
The example I found, that did not support resizing, is this one.Char said:
http://www.runtime.org/driveimage-xml.htm
Paul
B
BobbyM
I really think you may be mixing & confusing terminology. Usually
backing up, copying, imaging, & cloning are not synonymous. With just a
quick glance, Driveimage does not appear to be capable of cloning.
P
Paul
"Copy directly from drive to drive".BobbyM said:
On the web page.
Paul
J
Juan Wei
Paul has written on 8/24/2013 10:07 PM:
However, with both drives connected -- one internal and the SSD
USB-connected -- I booted to a boot menu and selected the SSD to boot
from (just to see what would happen). It seemed to have been successful
although it wasn't nearly as fast as what I had expected.
So did it really boot from the SSD, or from some combination of what was
on the SSD (dosk 2) and the internal one (disk 0)?
Thanks for that.
However, with both drives connected -- one internal and the SSD
USB-connected -- I booted to a boot menu and selected the SSD to boot
from (just to see what would happen). It seemed to have been successful
although it wasn't nearly as fast as what I had expected.
So did it really boot from the SSD, or from some combination of what was
on the SSD (dosk 2) and the internal one (disk 0)?
P
Paul
And from the FAQ page:Paul said:
http://www.runtime.org/driveimage_faq.htm
"Vista Boot Problem:
If your _cloned_ Vista drive refuses to boot with a
"winload.exe is missing or corrupt" message, you
might need to change the BCD store.
"
It's simply not a "full service" utility. It requires manual
fiddling as described in the FAQ. Still, in a pinch, you
can use that to get the job done. But you can't "clone n' shrink".
That capability is not there. No amount of fiddling will make
it do that on its own.
Paul
B
BobbyM
So you really do believe that copy and clone are synonymous. I give up.
J
Juan Wei
When I restart my computer and hit F12 before Windows starts, I get a
menu of devices from which to boot.
After cloning the C: partition to the SSD and restarting and getting
that menu, I selected the SSD.
Did I actually boot from the SSD or did the system, not finding an MBR
on the SSD, go on and seek out adrive with an MBR?
Thanks.
menu of devices from which to boot.
After cloning the C: partition to the SSD and restarting and getting
that menu, I selected the SSD.
Did I actually boot from the SSD or did the system, not finding an MBR
on the SSD, go on and seek out adrive with an MBR?
Thanks.
M
meerkat
http://www.dpreview.com/forums/post/41750743BobbyM said:
B
BobbyM
Juan, we've been through this several times.
1. Disconnect your original drive. Assuming your old drive is a SATA
just disconnect both plugs & plug them into your SSD. You can
physically install it later & pull out the old drive if everything works.
3. Boot up & see what happens.
FYI - you should change BIOS settings from IDE to ACHI when using an SSD.
T
Timothy Daniels
"Juan Wei" catches on well:
tell US! I suspect that you have the correct idea - the BIOS found
2 drives enabled, it responded to your F12 input and presented the
choice of which to try to boot from, but not finding an MBR on the
drive of your choice, it moved to the top of the boot priority list
and found an MBR on the HDD and subsequently booted the
original OS that still resides there. In short, you still haven't booted
the clone. And don't forget, when you do that for the FIRST time,
have the "parent" OS hidden from it, most easily done by disabling
the HDD. And as I suggested elsewhere in this thread, put a folder
on the desktop (or at the root of the file system) of each OS that has
a name that tells you whether it's in the "parent" or the clone OS.
*TimDaniels*
My advice is to find out through experimentation, and then YOU
tell US! I suspect that you have the correct idea - the BIOS found
2 drives enabled, it responded to your F12 input and presented the
choice of which to try to boot from, but not finding an MBR on the
drive of your choice, it moved to the top of the boot priority list
and found an MBR on the HDD and subsequently booted the
original OS that still resides there. In short, you still haven't booted
the clone. And don't forget, when you do that for the FIRST time,
have the "parent" OS hidden from it, most easily done by disabling
the HDD. And as I suggested elsewhere in this thread, put a folder
on the desktop (or at the root of the file system) of each OS that has
a name that tells you whether it's in the "parent" or the clone OS.
*TimDaniels*
P
Paul
You will know, when the computer has only one diskJuan said:
connected to it
That's how I figure out what the dependencies are.
I've cloned a few older OSes, and run into the
problem with the "first boot" and had to re-clone
to fix it up. It's not a big deal, but it is
annoying. As a consequence of wasting time on that,
I don't take chances.
I don't know if every Windows OS has this problem,
but it's just easier to boot the clone by itself,
just to be safe. After one boot, it should know
where the pagefile is, know it is "C:", and
there should be no further reasons for an
identity crisis. It should settle down after
being booted once.
Paul
P
Paul
No, I do not.BobbyM said:
I do believe the terms lack accurate definitions.
What Macrium Reflect does, is not a clone either. Because it
chooses to ignore any sectors not noted in the $MFT. But
we don't know if some piece of software, stored something
where it wasn't supposed to (like a license key, an expiry
date, trial software information), and the Macrium
operation didn't get it.
For example, there is a difference between the physical and logical
dimensions of a file system, like fractions of a cluster up near the
end of the file system, where a clever application could write stuff,
knowing that the file system cannot access those bytes. And Macrium
would not attempt to copy anything from there, because it is not
noted in the $MFT.
If you're looking for a forensically good duplicate of a partition,
"dd" is the way to do that. (I use it here, and have the port
for Windows, as well as the Linux one.) What Macrium is doing,
is merely "a fairly good copy", certainly a better copy than the
files-only copy DriveImage is making.
It's all a matter of degree. Should we only award the term
"clone" to what "dd" does, or should we also use it for
all those utilities out there doing less than "dd" does ?
To me, "exact duplicate" would describe a thing I might like
to make. Whereas "clone" leaves me wondering exactly what
I'm getting. Is it a duplicate, or just a file-level copy ?
Who controls the definition of the word "clone" ?
Is it what two guys decided over their coffee break ?
Each kind of copy, copies features to a certain level. For
a user and their "data only disk", just getting their files
and folders right, they'd call that a clone. Because they're
not aware of things in the file header or whatever, things
they don't care about (like say a volume serial number). For
someone in the IT department, maybe they'd call what Macrium
was doing "cloning". But if you have to be absolutely certain
you lose nothing in the process, copying all the sectors gets
everything.
To me, it's either an "exact duplicate", or it is "some
poorly defined thing we could argue about".
When Macrium does a "clone n' shrink", that by definition
isn't a clone either. Because now the $MFT is entirely
different. That makes no difference to the user, except
that the storage device won't have the same dynamics
(since the partition is now defragmented, the user
will notice the improved performance). It's not
an exact duplicate.
Paul