How: dual-boot with exact partition-clone

[michelratipho]

Hi,
I am trying to set up a XP(mce 2005) dual-boot where I could make a
copy of 1 partition to a second one. Just to test some software and
configurations while being able to startup the older XP without the
changes when needed.

After testing over 10 freeware's to clone and multiple-boot, I
finally
am using "SelfImage" with which I can backup or clone a running XP-
partition to a file or other partition.
Using the multi-boot menu "Vamos" to boot from any partition, naming
it C: and have an option to hide the other partition just to be shure
not to harm it.


Now when I start the XP clone on the second partition I get a blue
screen. I already found out by installing a fresh XP that the
BOOT.INI
should be changed to point to the second partition. But there seems
to
be something else to, because I still can't boot the clone partition.
I get a blue screen with lots or errors-numbers.


IN SHORT:
Does anyone know how to start from a second partition having a clone-
copy from the normal intalled XP-mce first partition? Or could it be
that this only works with a FAT32 instead of my NTFS partitions !?


Thanks,
Michel

 

[Guest]

To properly clone a xp OS or a mce OS,from hd to hd,set the 2nd drive as
slave to C: on the same IDE cable,format the 2nd drive,then go to run,type:
XCOPY C:\*.* D:\ /c/h/e/k/r Agree to all in the DOS window,once its thru,
D: is now a bootable hd.Also,D: being the 2nd drive letter,but if asigned
diffrent
then use that letter.For all XCOPY cmds open cmd prompt,type:XCOPY /?

 

[Timothy Daniels]

I am trying to set up a XP(mce 2005) dual-boot where I could
make a copy of 1 partition to a second one. Just to test some
software and configurations while being able to startup the
older XP without the changes when needed.

After testing over 10 freeware's to clone and multiple-boot, I
finally am using "SelfImage" with which I can backup or clone
a running XP- partition to a file or other partition.
Using the multi-boot menu "Vamos" to boot from any partition,
naming it C: and have an option to hide the other partition just
to be shure not to harm it.


Now when I start the XP clone on the second partition I get
a blue screen. I already found out by installing a fresh XP that
the BOOT.INI should be changed to point to the second
partition. But there seems to be something else to, because I
still can't boot the clone partition. I get a blue screen with
lots or errors-numbers.


IN SHORT:
Does anyone know how to start from a second partition having
a clone-copy from the normal intalled XP-mce first partition?
Or could it be that this only works with a FAT32 instead of
my NTFS partitions !?

There is one difficulty in dual-booting a clone which is on the
samd HD as the "parent" OS, and that is during startup of the
clone for the clone's very first run. To prevent the clone from
confusing some of its files and settings with those of its "parent",
the clone must not be able to "see" its parent during this first
startup. If the 2 OSes are on separate HDs, this is easily
accomplished by merely disconnecting the "parent" OS's HD
before the first startup of the clone. But if the 2 OSes are on
the same HD, special software (e.g. Partition Magic or BootItNG,
etc.) must be used to hide the partition of the "parent" OS.
Maybe Vamos can do this, but I don't know.

Otherwise, to dual-boot from another partition on the same HD,
one must:
1) Add another entry to boot.ini (in the partition marked "active")
under the line "[operating systems]" that is identical to the first
line under "[operating systems]" but with the "y" in "partition(y)"
changed to the no. of the partition of the 2nd OS.

2) Change the value of "timeout" to be a reasonable no. of seconds
to allow the user time to select which OS to start up.

If the 2 OSes are on separate HDs, you can dual-boot using either
the BIOS or boot.ini:

BIOS
The HD which is at the top of the Hard Drive Boot Order in the
BIOS selects which HD will control booting. The default order
is what 99% of users use without even knowing it. But it can be
adjusted by entering the BIOS during startup. Since both OS's
boot.ini is composed as if its HD were in control during boot time,
by putting a HD at the head of the Hard Drive Boot Order, one
also causes the OS resident on it to boot.

BOOT.INI
The parameter in boot.ini which designates the physical HD is
"rdisk(x)", where "x" stands for the position of the HD in the BIOS's
Hard Drive Boot Order, starting at position 0 (the head of the list).
The "parent" OS's HD is almost always at the head of the list, so
its "rdisk()" setting is usually "rdisk(0)". The value of "y" in
"partition(y)" is merely the no. of the partition into which the clone
was placed (the numbering of partitions beginning with "1"). So
merely adding another entry under "[operating systems]" in boot.ini
(of the 1st OS's partition) that points to the clone OS on the 2nd HD,
and setting the timeout value, will direct dual-booting.

If you have the time, why not just install a 2nd copy of WinXP
on the 2nd partition of the same HD? If it has been 4 months or
more since you last used the installation CD, activation can be
accomplished on-line. Otherwise, a call to Microsoft to tell them
that the 1st installation had gotten corrupted will do the trick.
When the installer sees the 1st installed OS, it can automatically
set up the boot.ini on the 1st OS's partition to do dual-booting
between the 2 OSes. The new OS and the old OS will call the
partition of the new OS "D:". But if you eventually reformat the
partition that currently holds the 1st OS, the 2nd OS will be left
without boot files (i.e. ntldr, boot.ini, and ntdetect.com). To
avoid this problem, before re-formatting, you could either copy
those files to the partition of the new OS and remove the
"[operating systems]" entry for the 1st OS and set the new OS's
partition "active". Or you could simply install the new OS on the
2nd partition and tell the installer to ignore any other OSes that
it might see. Then you would have to add an entry yourself to the
1st OS's boot.ini file to do dual-booting. The advantage would
be that if you re-formatted the 1st OS's partition, you'd only have
to set the partition of the new OS "active" to make that partition's
boot files take control at boot time.

In short, until you find someone familiar with the workings of
Vamos, your choices begin with deciding on one or two HDs.

*TimDaniels*

 

[Pegasus \(MVP\)]

You cannot copy the system partition while Windows is
up and running. You must do it by booting the machine
with a suitable boot disk or by connecting the disk to
some other machine. Furthermore, it is essential that
the target partition is marked "active".

 

[John John]

Hi,
I am trying to set up a XP(mce 2005) dual-boot where I could make a
copy of 1 partition to a second one. Just to test some software and
configurations while being able to startup the older XP without the
changes when needed.

After testing over 10 freeware's to clone and multiple-boot, I
finally
am using "SelfImage" with which I can backup or clone a running XP-
partition to a file or other partition.
Using the multi-boot menu "Vamos" to boot from any partition, naming
it C: and have an option to hide the other partition just to be shure
not to harm it.


Now when I start the XP clone on the second partition I get a blue
screen. I already found out by installing a fresh XP that the
BOOT.INI
should be changed to point to the second partition. But there seems
to
be something else to, because I still can't boot the clone partition.
I get a blue screen with lots or errors-numbers.


IN SHORT:
Does anyone know how to start from a second partition having a clone-
copy from the normal intalled XP-mce first partition? Or could it be
that this only works with a FAT32 instead of my NTFS partitions !?

Try this:

Lets assume that you have two partitions, C & D, and that the original
Windows installation is on C and that D is the clone.

Boot to the original Windows installation on C and start Regedit. Use
the Load Hive feature to load the System hive of the cloned installation
(on D). The hive will be in D:\WINDOWS\system32\config and it is the
hive named "system", without any extensions.

Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

You will see a \DosDevice\ value for each drive (partition), one being
C: and the other D:

Rename the Value Name: \DosDevices\C: to another unused name, lets say
\DosDevices\X:

Rename the Value Name: \DosDevices\D: to \DosDevices\C:

Now rename the original \DosDevices\C: (now named \DosDevices\X, to
\DosDevices\D:

Unload the hive and exit Regedit. Try to boot the second (cloned)
installation and see what happens.

*DO NOT* change the MountedDevices values of the original Windows
installation! Only change the values in the registry hive of the cloned
installation. Easy instructions on how to load remote registry hives is
shown here: http://www.rwin.ch/xp-live/regedit.htm

John

 

[michelratipho]

First off all thank you all for the responces,

Andrew E.: XCOPY can't copy long file names from plain DOS and from a
XP-DOS-windows it can't copy the running XP, SelfImage can!

Timothy Daniels: I don't have a second HDD and I want a clone because
of all the work that has already been done setting up and finetuning
the first XP. I want an exact copy to test all kinds of software and
other drivers and always be able to quick boot back to the original XP
do some housework. Then later when I have time I can continue to test
and alter the clone. If the clone would become better I want to clone
it back to the original ;-)

Pegasus (MVP): You can copy, clone or backup a running XP with the
freeware "SelfImage" ;-) Though you need the "XP Ultimate Boot CD" to
be able to restore the backup the cloning works fine after altering
BOOT.INI and HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices


John John and all: ...

I did some more testing in the mean time.
It seems I can alter BOOT.INI and the HKEY_LOCAL_MACHINE\SYSTEM
\MountedDevices while running XP, before I use "SelfImage" (http://
selfimage.excelcia.org) to clone C: to D: and restore the original
BOOT.INI and MountedDevices. This way the clone is ready to boot. I
even made a batchfile do to it, see later....
Note that I am using NTFS partitions where I hide the original 1e
partition C: when booting from the second partition (=clone) with the
free bootmanager "Vamos".

The only problem left now, is that for some reason XP still starts up
the BOOT.INI from the first original partition. I can see this because
I altered the menu-text. So I always need to change the default
selection to point BOOT.INI to the second partition. Works fine, but
if one forgets to select the other partition in the BOOT.INI-menu you
get blue-screen-errors.

It's strange why XP still can find the BOOT.INI from the hidden NTFS,
first partition!? Any idea to solve this last thing of a perfect fast,
easy and free XP dual-booting ???? Maybe a programming language in
BOOT.INI to autoselect the default partition, like a batchfile....

------------------------------ copy of my working CLONE.BAT
-----------------------------
@echo off
cls

echo.
echo. *************** SETTING UP A DUAL CLONED XP with NTFS
PARTITIONS*************
echo.
echo. No warrenty is given using this cloning batchfile. Date
19/10/2007 MR
echo.
echo.
echo. FREEWARE
echo "SelfImage" from selfimage.excelcia.org for backup and cloning
your running XP
echo "Cute" and/or "Ranish" partition manager" to make a 2nd partition
echo "VAMOS" boot manager to swap between partitions
echo.
echo.
echo. TO DO
echo Setup a second partition for the clone and format it.
echo Make shure windows has labled the new partition with a letter!
echo Set up a dual-boot where booting the clone, the original
partition is hidden!!!
echo Boot the original XP where the new clone partition is visible.
echo.
pause

attrib -r -h -s c:\boot*.* > nul

:BOOTREG
set OrgP=1
set NewP=2
if exist c:\bootpar1.ini set OrgP=2
if exist c:\bootpar1.ini set NewP=1
if exist c:\bootpar1.reg if exist c:\bootpar2.reg goto:BOOTINI
reg export "HKLM\SYSTEM\MountedDevices" c:\bootreg.tmp >nul
type c:\bootreg.tmp | find /i "Registry Editor" > c:\bootpar%OrgP%.reg
echo. >>c:\bootpar%OrgP%.reg
type c:\bootreg.tmp | find /i "MountedDevices" >>c:\bootpar%OrgP%.reg
type c:\bootreg.tmp | find /i "\DosDevices\" >>c:\bootpar%OrgP%.reg
del c:\bootreg.tmp >nul
copy c:\bootpar%OrgP%.reg c:\bootpar%NewP%.reg >nul
echo.
echo Edit c:\bootpar%NewP%.reg:
echo. - change "C:" to a free and new driveletter
echo. - change the new clone partition to "C:"
echo. - delete all other lines
echo.
pause
goto:BOOTREG

:BOOTINI
if exist c:\bootpar1.ini goto:CLONE
if exist c:\bootpar2.ini goto:CLONE
echo.
echo Edit c:\boot.ini and add a line under the label [operating
systems]
echo which points to the new cloned partition and set TimeOut to 20.
echo.
pause
copy c:\boot.ini c:\bootpar%NewP%.ini >nul
echo.
echo Edit c:\bootpar%NewP%.ini and change under the label [boot
loader]
echo the default partition-number to the new clone-number.
echo.
pause
goto:BOOTINI

:CLONE
reg import c:\bootpar%NewP%.reg >nul
if exist c:\bootpar%OrgP%.ini del c:\bootpar%OrgP%.ini
ren c:\boot.ini bootpar%OrgP%.ini >nul
ren c:\bootpar%NewP%.ini boot.ini >nul
attrib +r +h +s c:\boot.ini > nul
attrib +r c:\bootpar?.ini > nul
attrib +r c:\bootpar?.reg > nul
echo.
echo waiting on SelfImage to complete...
echo.
"C:\Program Files\SelfImage\SelfImage.exe"
attrib -r -h -s c:\boot*.* > nul
ren c:\boot.ini bootpar%NewP%.ini
ren c:\bootpar%OrgP%.ini boot.ini
reg import c:\bootpar%OrgP%.reg >nul
echo.
echo Done

:EXIT
attrib +r +h +s c:\boot.ini > nul
attrib +r c:\bootpar?.ini > nul
attrib +r c:\bootpar?.reg > nul

-----------------------------------------------------------------------------------------------

 

[John John]

First off all thank you all for the responces,

Andrew E.: XCOPY can't copy long file names from plain DOS and from a
XP-DOS-windows it can't copy the running XP, SelfImage can!

Timothy Daniels: I don't have a second HDD and I want a clone because
of all the work that has already been done setting up and finetuning
the first XP. I want an exact copy to test all kinds of software and
other drivers and always be able to quick boot back to the original XP
do some housework. Then later when I have time I can continue to test
and alter the clone. If the clone would become better I want to clone
it back to the original ;-)

Pegasus (MVP): You can copy, clone or backup a running XP with the
freeware "SelfImage" ;-) Though you need the "XP Ultimate Boot CD" to
be able to restore the backup the cloning works fine after altering
BOOT.INI and HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices


John John and all: ...

I did some more testing in the mean time.
It seems I can alter BOOT.INI and the HKEY_LOCAL_MACHINE\SYSTEM
\MountedDevices while running XP, before I use "SelfImage" (http://
selfimage.excelcia.org) to clone C: to D: and restore the original
BOOT.INI and MountedDevices. This way the clone is ready to boot. I
even made a batchfile do to it, see later....
Note that I am using NTFS partitions where I hide the original 1e
partition C: when booting from the second partition (=clone) with the
free bootmanager "Vamos".

The only problem left now, is that for some reason XP still starts up
the BOOT.INI from the first original partition. I can see this because
I altered the menu-text. So I always need to change the default
selection to point BOOT.INI to the second partition. Works fine, but
if one forgets to select the other partition in the BOOT.INI-menu you
get blue-screen-errors.

It's strange why XP still can find the BOOT.INI from the hidden NTFS,
first partition!? Any idea to solve this last thing of a perfect fast,
easy and free XP dual-booting ???? Maybe a programming language in
BOOT.INI to autoselect the default partition, like a batchfile....

Like others have already said, you should be using a boot manager to
accomplish what you want.

The problem you are now experiencing is because of the active partition.
Any primary partition can be marked as active but there can only be
one active partition at a time on a basic disk. You need an active
partition to boot the operating system, when you boot your setup it is
booting from the files on your original partition because it is the
active partition. You cannot change that after the operating system
starts to boot and there is no batch file that will accomplish what you
want.

If you are using installation #1 and decide that you want to use
installation #2 then go in the Disk Management tool and mark the second
partition as active, when the computer is rebooted it will boot on
partition #2 instead of partition #1.

If the computer is turned off and you want to select which partition to
boot to without having to start Windows and use the Disk Management tool
then you need a boot manager, or you can use a Windows 98 startup
diskette and try to toggle the active partitions with fdisk, a rather
clumsy approach to your "problem". As Timothy said earlier, you would
be much better off using two hard disks, it will make things a lot
easier for you, hard disks are not that expensive, if money is an issue
try asking a computer repair shop for a second hand disk, you might be
able to get a 40 or 80 GB hard disk for a very small amount of money.
If you really cannot use a second hard disk then I strongly suggest that
you use one of the freely available boot managers.

John

 

[Pegasus \(MVP\)]

Pegasus (MVP): You can copy, clone or backup a running XP with the
freeware "SelfImage" ;-) Though you need the "XP Ultimate Boot CD" to
be able to restore the backup the cloning works fine after altering
BOOT.INI and HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

I'm always interested in new disk cloning tools. This one looks
interesting but appears to be rather immature. Here a couple of
big issues:
- When SelfImage creates an image file then it attempts to copy
the whole partition. It does not appear to be aware of what's
data and what's empty space. A 30 GByte partition will
therefore result in a 30 GByte image file, even if only 6 GBytes
are used. It is possible to use the compression option but
even then SelfImage wades through all of the disk.
- The program does not appear to be able to restore a partition
unless the target partition is exactly the same size as the source
partitition. This is a serious limitation.

I assume that both of these restrictions will be addressed in
due course. Commercial programs have addressed them a
long time ago.

 

[John John]

I'm always interested in new disk cloning tools. This one looks
interesting but appears to be rather immature. Here a couple of
big issues:
- When SelfImage creates an image file then it attempts to copy
the whole partition. It does not appear to be aware of what's
data and what's empty space. A 30 GByte partition will
therefore result in a 30 GByte image file, even if only 6 GBytes
are used. It is possible to use the compression option but
even then SelfImage wades through all of the disk.
- The program does not appear to be able to restore a partition
unless the target partition is exactly the same size as the source
partitition. This is a serious limitation.

I assume that both of these restrictions will be addressed in
due course. Commercial programs have addressed them a
long time ago.

Yesterday I "played" with this SelfImage tool. I wanted to see if I
could clone from one partition to another on the same disk, Acronis
absolutely will not do this so I was intrigued about the claims that
SelfImage would do it.

I stuck a small 40GB disk in a test machine and divided it into two
partitions, one 10GB and the other 30GB. I installed Windows 2000 on
the 10GB partition and then "tried" to use SelfImage to clone the 10GB
partition to the 30GB one. SelfImage said that it couldn't do that, it
said that it could only copy an image file to the second partition but
it suggested or offered to use the "whole" disk as the destination to
clone the partition. I didn't want an image, I wanted to clone the
partition in one step, so I figured that maybe using the option to use
the whole disk it might put the clone on the second partition, little
did I know what was about to happen...

SelfImage went through the motions and appeared to be copying a 9.X GB
partition (the 10GB one) to somewhere on the hard disk, where was it
copying to? One could only assume to the other 30GB partition. I
thought of this as a bit odd because the whole Windows 2000
installation, including the pagefile is less than 1.5GB, I figured that
it was doing a sector by sector copy, something that I thought of as
being a bit odd for a "modern" cloning tool. It took about 45 minutes
to do its thing, when it was done the only thing left to do was click on
the SelfImage exit button and see what it had done. As soon as I hit
the exit button the computer died as quickly as if I had pulled the plug
from the wall outlet! Then it wouldn't reboot at all, it would display
the post information but after the post nothing at all, not even a
blinking cursor!

I then thought that the active flag had been toggled so I booted with a
Windows 98 floppy and tried to use fdisk to see what was going on.
Fdisk started ok but as soon as I tried to use any of the options to
query the disk or change anything on it the computer hung and only a
hard reset would take me out of the crash. The BIOS correctly
identified the disk's model number and size, so I decided to try to
reinstall Windows 2000. When I got to the disk partitioning/selection
screen the setup program reported the disk as having two unknown
partitions on it and an extra available unpartitioned space of more than
88,000MB, a bit remarkable for a 40GB disk! While the setup program
could delete the two unknown partitions it couldn't make head or tails
of anything else on the disk and it couldn't properly format and return
the correct disk size.

I then figured that the disk might have been toasted by SelfImage, so I
downloaded a diagnostic utility from the disk manufacturers site and it
reported the disk as being in good condition, yet another try at W98
fdisk failed to query the disk. I had to use the disk diagnostic
utility and zero out the first sector (MBR) to get the disk back to a
usable condition. All I can think of, is that when I accepted the
option to copy to the only place that the utility would allow when used
with a single disk, it doubled the size of the disk (2x 40GB) then added
the 9.x GB partition to the total and rewrote the partition table to
show the disk as being some 88,000+ MB in size.

Of course what I did was stupid and I knew better than that when I did
it but hey, it was only a test on a test disk. Nonetheless, the program
should have *never* even tried to do such a cloning job! I was less
than impressed to say the least and I give SelfImage the "half baked"
award of the month!

John

 

[Pegasus \(MVP\)]

Yesterday I "played" with this SelfImage tool. I wanted to see if I could
clone from one partition to another on the same disk, Acronis absolutely
will not do this so I was intrigued about the claims that SelfImage would
do it.

I stuck a small 40GB disk in a test machine and divided it into two
partitions, one 10GB and the other 30GB. I installed Windows 2000 on the
10GB partition and then "tried" to use SelfImage to clone the 10GB
partition to the 30GB one. SelfImage said that it couldn't do that, it
said that it could only copy an image file to the second partition but it
suggested or offered to use the "whole" disk as the destination to clone
the partition. I didn't want an image, I wanted to clone the partition in
one step, so I figured that maybe using the option to use the whole disk
it might put the clone on the second partition, little did I know what was
about to happen...

SelfImage went through the motions and appeared to be copying a 9.X GB
partition (the 10GB one) to somewhere on the hard disk, where was it
copying to? One could only assume to the other 30GB partition. I thought
of this as a bit odd because the whole Windows 2000 installation,
including the pagefile is less than 1.5GB, I figured that it was doing a
sector by sector copy, something that I thought of as being a bit odd for
a "modern" cloning tool. It took about 45 minutes to do its thing, when
it was done the only thing left to do was click on the SelfImage exit
button and see what it had done. As soon as I hit the exit button the
computer died as quickly as if I had pulled the plug from the wall outlet!
Then it wouldn't reboot at all, it would display the post information but
after the post nothing at all, not even a blinking cursor!

I then thought that the active flag had been toggled so I booted with a
Windows 98 floppy and tried to use fdisk to see what was going on. Fdisk
started ok but as soon as I tried to use any of the options to query the
disk or change anything on it the computer hung and only a hard reset
would take me out of the crash. The BIOS correctly identified the disk's
model number and size, so I decided to try to reinstall Windows 2000.
When I got to the disk partitioning/selection screen the setup program
reported the disk as having two unknown partitions on it and an extra
available unpartitioned space of more than 88,000MB, a bit remarkable for
a 40GB disk! While the setup program could delete the two unknown
partitions it couldn't make head or tails of anything else on the disk and
it couldn't properly format and return the correct disk size.

I then figured that the disk might have been toasted by SelfImage, so I
downloaded a diagnostic utility from the disk manufacturers site and it
reported the disk as being in good condition, yet another try at W98 fdisk
failed to query the disk. I had to use the disk diagnostic utility and
zero out the first sector (MBR) to get the disk back to a usable
condition. All I can think of, is that when I accepted the option to copy
to the only place that the utility would allow when used with a single
disk, it doubled the size of the disk (2x 40GB) then added the 9.x GB
partition to the total and rewrote the partition table to show the disk as
being some 88,000+ MB in size.

Of course what I did was stupid and I knew better than that when I did it
but hey, it was only a test on a test disk. Nonetheless, the program
should have *never* even tried to do such a cloning job! I was less than
impressed to say the least and I give SelfImage the "half baked" award of
the month!

John

Your tests confirm my worst fears about SelfImage. The product
is still in its infancy. By the time it is mature it will probably go
commercial. In the meantime the company behind it gets some free
testing done by people who get their fingers burnt.

BTW, you're not quite right when you say that Acronis cannot
clone from one partition to the other on the same disk. Acronis
TrueImage can't - you need to go via the intermediate step of an
image file - but Acronis DiskDirector can, provided that the
receiving partition is of sufficient size.

 

[John John]

BTW, you're not quite right when you say that Acronis cannot
clone from one partition to the other on the same disk. Acronis
TrueImage can't - you need to go via the intermediate step of an
image file - but Acronis DiskDirector can, provided that the
receiving partition is of sufficient size.

Thanks for the heads up on Disk Director. I have a copy of it here and
I thought of installing it for the test but then I didn't think that it
would be able to do the cloning so I installed True Image instead. I
was going to try my test again by mounting the disk to another Windows
installation and using xcopy to copy the dormant installation to the
other partition. I will try my test again with Disk Director instead.
I want to see if I can do what the OP is trying to do by simply deleting
the complete MountedDevices database on the clone partition and then
toggling the active partitions and rebooting on the clone partition.

John

 

[Timothy Daniels]

Thanks for the heads up on Disk Director. .... I will try my test
again with Disk Director instead. I want to see if I can do what
the OP is trying to do by simply deleting the complete
MountedDevices database on the clone partition and then toggling the active
partitions and rebooting on the clone partition.

John

If you intend to boot up the clone while the "parent" OS
still exists on the 1st partition, use something to hide the 1st
partition when the clone is booted for the 1st time. And if
you do that, mark the 2nd partition "active" before you do
that so that the boot files on the 2nd partition will be used.
If the 1st partition is hidden, the cloned boot.ini file on the
2nd partition *should* work without modification because
"rdisk(0)" will refer to the 2nd partition (i.e. the 1st one visible
in the partition table. If it doesn't, please let us know.

*TimDaniels*

 

[michelratipho]

I have set up 3 partitions on one 500GB IDE drive, all NTFS: p1:15gb,
p2:15gb, p3:all the rest. All primary boot-partitions ;-)
I did use Ranish and Cute partition manager to make the second
partition excactly the same size as the first one. So I peeled off
some because the first partition was a bit smaller. I think because of
the MBR.

Then SelfImage can clone the 1e to the 2e and back. I did it 6 times
by now, always starting XP with the other partition as a hidden NTFS.
I use "Vamos" as the bootmanager which enables to hide the other NTFS-
partition.

Also making a backup with SelfImage to a file on the 3th partition and
restoring it back, works like a charm. The 7GB used on the first
partition becomes a 3GB file. It doesn't copy the not used space and
even compress the data ;-) I once needed to restore that file, which
I've places on a DVD with booting the XP "Ultimate boot CD" which has
SelfImage on it.

Like I say...the only problem I need to solve it hiding the 1e
partition BOOT.INI when it is set to a NTFS hidden partition. Some how
that menu keeps on running instead of the BOOT.INI of the second
partition booting with Vamos.

 

[John John]

Then SelfImage can clone the 1e to the 2e and back. I did it 6 times

I don't know how you did that but when I tried it the program said that
it couldn't clone to another partition on the disk. My "other"
partition was already created, maybe if it had been unallocated disk
space it may have been different. Or did you first create an image file
then restore it to the partition?

I told you earlier why the boot.ini file on the first partition is the
one that is being used.

John

 

[John John]

If you intend to boot up the clone while the "parent" OS
still exists on the 1st partition, use something to hide the 1st
partition when the clone is booted for the 1st time. And if
you do that, mark the 2nd partition "active" before you do
that so that the boot files on the 2nd partition will be used.
If the 1st partition is hidden, the cloned boot.ini file on the
2nd partition *should* work without modification because
"rdisk(0)" will refer to the 2nd partition (i.e. the 1st one visible
in the partition table. If it doesn't, please let us know.

*TimDaniels*

Well I did try my little test and things pretty went as I expected them
to, here are the results.

I did my tests by simply mounting the test disk to another Windows
installation and I used xcopy to copy the contents of the dormant
installation to the second partition, then I returned the disk to the
test machine and did some tests. I then deleted the second partition
and used Disk Director to copy the first partition to a new primary
partition that Disk Director created from the unallocated space that the
previous partition had occupied and I repeated the tests.

Keep in mind that the test installation was just a basic Windows 2000
installation with no user software installed. This is what happened,
the results were the same regardless of the copy method used to make the
second partition:

I did not use a boot manager and I did not bother hiding partitions. I
simply added an extra line pointing to the second partition to the
boot.ini files and tried different booting scenarios, I simply booted to
partition 1 or 2 from the Boot.ini file and tried it with either
partition set as active. The first partition was labeled as C:\ and the
second, copied one G:\.

Booting with the first (original) partition as the system partition I
could successfully boot to both installations without any problems, the
installation on the second partition booted to the desktop without any
problems. I then changed the active flag to the second partition and
once again I could successfully boot either partition to the desktop.

However, even if the second installation successfully booted with either
partition marked as active, the process was still deeply flawed. To an
unexperienced user everything would have probably appeared to be fine
but to the trained eye the expected drive letter problem was easy to spot.

When booting to the first (original) Windows installation, regardless of
the system partition used, the installation (boot volume) maintained its
drive letter assignments, it booted to and used the C:\ drive letter,
where it was originally installed. There would be no problem using this
setup.

Booting to the second (cloned) installation, at boot time, as expected,
the I/O Manager respected the drive letter assignments previously made
by the Mount Manager and assigned drive letters based on the Mount
Manager's MountedDevices database. The cloned installation was booting
to and using the G:\ drive for its boot volume. Although the cloned
installation successfully booted the results were fatally flawed and
eventually this scenario would blow up in the user's face. The
installation is a clone of an installation done on drive C:\, everything
in the registry points to C:\, yet the installation was using the WINNT
and System32 folders on G:\. You don't need to be an expert to know
where that would eventually lead! Also, the installation was using the
UserProfile on G:\ yet, once again, everything in the registry points
the UserProfiles as being on C:\. Another ticking time bomb! Clearly,
even if the installation booted successfully, this was not a viable setup.

To rectify the boot volume drive letter problem with the clone I simply
went to the clone's registry and deleted *all* the entries in the
MountedDevices key. At boot time this caused the I/O Manager's
IoAssignDriveLetters function to use a predetermined and established set
of rules to assign drive letters and it assigned the now available drive
letter C:\ to the boot volume, (it assigned drive letter E:\ to the
first partition). Regardless of the active partition used, when the
MountedDevices key contained no entries the I/O Manager assigned C:\ to
the boot volume of the clone and it repopulated the MountedDevices key
with this new information. Upon subsequent reboots, using either active
partitions, the cloned installation used and retained the assigned drive
letter C:\ for its boot volume, this installation would now be viable.
Of course, due to the persistent nature of the Mount Manager's drive
letter assignments, when booting the first installation none of the
drive letters were affected, it continued to use C:\ for its boot
volume and it kept the G:\ letter assignment for the second partition.

Part of the reason why the cloned installation booted without problems
on boot volume letter G:\ is that the Session Manager did not try to
create a pagefile on the second partition, instead, following the
instructions in the registry the Session Manager created the pagefile on
C:\. Had the first partition (C:\) been hidden, or had its drive letter
been changed in the MountedDevices key the cloned installation may not
have successfully booted. I may try this test again and instead of
deleting the MountedDevices key I may use a boot manager to hide
partitions and see how the installations boot and how drive letters are
handed out by the I/O Manager. I think or suspect that because both
partitions are on the same disk and because the disk signature will
still be valid that the ID of the partitions, hidden or not, won't
change and that the drive letters will, or may be handed out according
to the MountedDevices assignments, I will have to test to know for sure.

So, booting with an exact partition clone on the same hard disk is not
all that difficult, it can be done fairly easily without the use of
third party boot managers. I may try this test again later but do it
with 2 different hard disks instead of different partitions on the same
disk. Other than the possible reboot loop on the clone I expect the
results to be much the same but I would still like to see the results
first hand.

John

 

[Timothy Daniels]

"John John" replied:

Well I did try my little test and things pretty went as I expected
them to, here are the results.

I did my tests by simply mounting the test disk to another
Windows installation and I used xcopy to copy the contents
of the dormant installation to the second partition, then I
returned the disk to the test machine and did some tests.
I then deleted the second partition and used Disk Director
to copy the first partition to a new primary partition that
Disk Director created from the unallocated space that the previous partition
had occupied and I repeated the tests.

Keep in mind that the test installation was just a basic
Windows 2000 installation with no user software installed.
This is what happened, the results were the same regardless
of the copy method used to make the second partition:

I did not use a boot manager and I did not bother hiding
partitions.

(I think you mean "3rd party boot manager" as ntldr,
the standard Microsoft booting utility for Windows
NT/2K/XP, is a boot manager.)

I simply added an extra line pointing to the second
partition to the boot.ini files and tried different booting
scenarios, I simply booted to partition 1 or 2 from the
boot.ini file and tried it with either partition set as active.

And so "rdisk(0)" and "rdisk(1)" continued to mean
"original partition 1" and "original partition 2", respectively,
to ntldr, since no partitions were hidden.

The first partition was labeled as C:\ and the second,
copied one G:\.

Booting with the first (original) partition as the system partition
I could successfully boot to both installations without any
problems, the installation on the second partition booted to the
desktop without any problems.

Since partition 1 was still "active", it remained as the
"System Partition", i.e. the one whose boot files were
used. The original OS called its partition "C:", and it
called the clone OS's partition something else. So far,
as expected.

I then changed the active flag to the second partition and once again I could
successfully boot either partition to the
desktop.

However, even if the second installation successfully booted
with either partition marked as active, the process was still
deeply flawed. To an unexperienced user everything would
have probably appeared to be fine but to the trained eye the
expected drive letter problem was easy to spot.

When booting to the first (original) Windows installation,
regardless of the system partition used, the installation
(boot volume) maintained its drive letter assignments, it
booted to and used the C:\ drive letter, where it was
originally installed. There would be no problem using this
setup.

Booting to the second (cloned) installation, at boot time,
as expected, the I/O Manager respected the drive letter
assignments previously made by the Mount Manager and
assigned drive letters based on the Mount Manager's
MountedDevices database. The cloned installation was
booting to and using the G:\ drive for its boot volume.

THIS is UNEXPECTED. Why, if the clone on partition 2
was an exact replica of the original OS on partition 1, would
the clone call its own partition anything but "C:"? In my
experience (which admittedly is almost entirely with cloning
to partitions on another HD), the clone always calls its own
partition by the same letter designation as its "parent" OS
did. This would imply that something in the partition table,
that is, something external to both partitions, keeps track of
which partition contains the "parent" OS. This especially
strange since you imply that the clone OS, when booted with
ntldr on partition 1 continues to call its own partition "C:".

When you say "The cloned installation was booting to and
using the G:\ drive for its boot volume", do you actually
mean "The cloned installation was booting to and using the
2ND PARTITION for its boot volume" - which would be
expected.

Although the cloned installation successfully booted, the results
were fatally flawed and eventually this scenario would blow up
in the user's face. The installation is a clone of an installation
done on drive C:\, everything in the registry points to C:\, yet the
installation was using the WINNT and System32 folders on G:\.

Re-word that to: "The installation is a clone of an installation
done on partition 1, so everything in its registry points to the
partition that contains it - the partition that it calls "C:" - yet the
clone was using the WINNT and System32 folder on its own
partition.... [so far, so good] ....on "G:" [WHOOOPS!]

Did the clone actually call the 2nd partition (its own partition)
"G:"? Please check that with Disk Management. If actually so,
I find it surprising, and could you explain to me how this came
about?

*TimDaniels*

 

[John John]

See in-line (long post):

"John John" replied:




(I think you mean "3rd party boot manager" as ntldr,
the standard Microsoft booting utility for Windows
NT/2K/XP, is a boot manager.)

Yes, that goes without saying ;-) I simply used ntldr, I didn't use a
third party boot manager.

And so "rdisk(0)" and "rdisk(1)" continued to mean
"original partition 1" and "original partition 2", respectively,
to ntldr, since no partitions were hidden.

There was only one disk in the machine so only rdisk(0) applies.
Remember, my test only involved "cloning" a partition to the same disk
and trying to make both partitions bootable and usable. The only
difference in the two ARC paths were the partition fields, partition(1)
or partition(2).

Since partition 1 was still "active", it remained as the
"System Partition", i.e. the one whose boot files were
used. The original OS called its partition "C:", and it
called the clone OS's partition something else. So far,
as expected.

That is not how it works. See below, where you found the results to be
unexpected, I explain it there.

THIS is UNEXPECTED. Why, if the clone on partition 2
was an exact replica of the original OS on partition 1, would
the clone call its own partition anything but "C:"? In my
experience (which admittedly is almost entirely with cloning
to partitions on another HD), the clone always calls its own
partition by the same letter designation as its "parent" OS
did. This would imply that something in the partition table,
that is, something external to both partitions, keeps track of
which partition contains the "parent" OS.

Not at all unexpected, Tim. You have to understand disk signatures and
how drive letters are assigned at boot time. Other than the disk
signature nothing pertaining to drive letters is kept in the partition
table. You must also understand that when the computer (Windows
2000/XP) is booting the I/O Manager's IoAssignDriveLetters function
follows preset rules, one of the first one being that drive letters
previously assigned by the Mount Manager will be respected, the drive
letter assignments stored at HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
will trump other rules, the IoAssignDriveLetters function *will* use
these drive letters if the signatures are valid.

To determine if the drive letters stored at the MountedDevices key are
valid the disk signature(s) will be checked against the volume GUID's
stored in the MountedDevices key and if there is a match the preassigned
drive letters will be reused. So in the case of our cloned partition,
the disk signature did not change and the location or ID of the first
partition did not change so it (the first partition) will keep drive
letter C:, the second partition, if it did not change will reuse its
previously assigned drive letter (in our case G. If the second
partition's ID or location had changed, the IoAssignDriveLetters
function would still not assign drive letter C: to the second partition
because the enumeration rules will reassign valid drive letters to their
original drives, the first partition will keep C: and the other primary
active partition would be assigned the next available drive letter after C:.

Regardless of where the clone is located and regardless of which
partition is made active and used to boot the operating system, the
partition will keep the preassigned drive letter if the signature and
the GUID are still valid, remember it's a clone so the information in
the clone's MountedDevices key is identical to the parent so when the
operating system on the second partition is booted the drives *will*
keep already assigned valid drive letters, the IoAssignDriveLetters
function will not change or break the rules, so the operating system on
the second partition does not have any say in which letter it will end
up on, it will have to live on the drive letter that it was assigned,
unless of course we take appropriate steps to cause drive letters to
become available and to cause previously assigned letters to become
invalid, the I/O Manager will then call on the IoAssignDriveLetters
function to force and reassign drive letters.

If the disk signature and the GUID's do not match (or if the
MountedDevices key is empty) the IoAssignDriveLetters function will then
rely on its set of built-in rules to assign drive letters. Let's say
that there are no entries in the MountedDevices key, using the preset
rules the IoAssignDriveLetters function will first assign drive letters
to the floppy drives, starting with letter A, it will then start
assigning drive letters to hard drives beginning at letter C:.

When you say "The cloned installation was booting to and
using the G:\ drive for its boot volume", do you actually
mean "The cloned installation was booting to and using the
2ND PARTITION for its boot volume" - which would be
expected.

It was booting on the second partition (G:\), which of course is what it
was supposed to do and it was using the letter G: to identify itself, or
more precisely identify the partition (drive) on which it resided,
which, because of the long explanation above was also expected, at least
by me.

Although the cloned installation successfully booted, the results
were fatally flawed and eventually this scenario would blow up
in the user's face. The installation is a clone of an installation
done on drive C:\, everything in the registry points to C:\, yet the
installation was using the WINNT and System32 folders on G:\.

Re-word that to: "The installation is a clone of an installation
done on partition 1, so everything in its registry points to the
partition that contains it - the partition that it calls "C:" - yet the
clone was using the WINNT and System32 folder on its own
partition.... [so far, so good] ....on "G:" [WHOOOPS!]

No, everything in the registry does *not* point to the partition where
the clone is. Everything in the registry points to drive "C:",
regardless of where drive "C:" is (which partition) and regardless of
what "C:" actually contains. Because of the drive letter assignment
rules the second operating system on the second partition had not been
assigned drive letter C: it had kept letter G:, it was a recipe for
disaster trying to run it without forcing a drive letter change.

Did the clone actually call the 2nd partition (its own partition)
"G:"? Please check that with Disk Management. If actually so,
I find it surprising, and could you explain to me how this came
about?

Yes it did and I fully expected that. Remember my earlier post I said
that I wanted to test complete removal of the Mount Manager's database
(the information in the MountedDevices key) to see how the I/O manager
would reassign drive letters.

If you want to see how the the MountedDevices key is used and queried
when Windows is booted just use Regmon to log the registry activity at
boot time and you will see what is going on. The boot log will probably
contain in excess of 100,000 entries, but luckily, for this exercise,
the queries to the MountedDevices key are amongst the first things to
happen, they will be almost at the start of the boot log.
http://www.microsoft.com/technet/sysinternals/information/BootTimeRegistryActivity.mspx

John

 

[michelratipho]

Thank you "John John" and every one else.

If it wasn't for you I wouldn't have tryed to boot the clone from the
original partition using BOOT.INI. I once messed up both partitions
booting the clone while the original was still visible. But that was
before I know that I needed to change the registry.

In short to all "HOW TO CLONE AND DUAL BOOT XP"

1) !!!!! THIS IS STILL A BETA METHOD !!!!! Backup first !!!!!

2) Download a cloning tool. I use "SelfImage v1.2.1" which can clone
and run from the running XP partition, make partition-backups to small
files.
In my case: it made a +/- 3GB file on an other partition from a 7GB XP-
OS on a 15GB partition.

3) Make a backup-file from your original partition with SelfImage and
burn it to a DVD using some burning-software like NERO. If needed you
can use the "ULTIMED BOOT CD" for booting into XP from CD which has a
copy of SelfImage on board to restore the image-file.

4) You still need to find a way to split-up your harddisk in multiple
partitions if you have only 1 partition and don't want to reinstall
XP. I have set up 3 primary NTFS boot-partitions right away before
installing XP.

5) Because SelfImage clames not to be able to restore to a smaller
partition I used the freeware "Ranish Partition Manager v2.44" to trim
the second partition to the exact size as the first one. This way I
can clone C: to D: and D: back to C:. To do this, I set the heads of
the second partition to 1 less. This is because the first one also has
this amount set to be used by the MBR.

6) Put a second line in the BOOT.INI file which is a hidden file
located in the c:\ (root) map, pointing to your clone-partition. Also
set some time in the timeout to allow you to make a choice.
my BOOT.INI:
---------------------
[boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="XP-mce original on
partition 1" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP-mce CLONE on partition
2" /fastdetect
---------------------

7) Make changes to your registry under HKEY_LOCAL_MACHINE\SYSTEM
\MountedDevices. Swap the keynames "\DosDevices\C:" with the clone one
by renaming them. In my case \DosDevices\D:.

8) Clone the first partition to the other one using SelfImage 1.2.1

9) Restore the changes made in the registry HKLM\SYSTEM\MountedDevices
as soon as the image has been completed !!!!!!!

10) Maybe change the clone-volume-name to "CLONE" just to show you
later where you have booted from.


Good luck ! And if you find some problem with it, please share it
here!

software-links found in http://www.thefreecountry.com/utilities/partitioneditors.shtml

 

[michelratipho]

Thank you "John John"

If it wasn"t for you I wouldn't have found the solution. At least so
far it seems to work. A free and simple XP cloning and booting
I did't wanted to try boot the clone from the 1e original partition,
because I once messed up both partitions trying to boot the clone
while the primary partition was still visible. We need to do more
tests, but so far we found the BEST MULTI XP-CLONE BOOTING. I
hope......

So to explain this in short to all looking for a XP cloning - XP dual
booting

1) !!!!! THIS IS STILL A BETA TEST !!!!! Which seems to work for
me ;-)

2) Download and install some cloning tool. I am using the freeware
SelfImage v1.2.1 which can copy your original running XP while even
doing some other tasks or surfing the net.

3) Because this is still a BETA idea, I would advice to backup your
system with SelfImage making a file. In my case the 6GB windows XP on
the 15GB partition gave a file just a bit bigger dan 3GB. Then burn
this on a DVD which could be restored using "THE ULTIMATE BOOT CD"
which boots into XP from the CD and has SelfImage to restore your OS.
You will need 2 DVD-drives to do the restore if needed or have the
backup-image-file on the 3th partition.

4) Divide your harddisk in 2 or more partitions. I used the freeware
Ranish partition manager v2.44 to make 3 NTFS partitions. Because
SelfImage clames not to be able to copy to a smaller partition and I
want to copy partition 1 to 2 and 2 to 1 again, I trimmed the second
partition to the exact size of the first one which is a bit smaller (I
think because of the MBR). So I put the Head-value 1 less than the
maximum.

5) You don't need a boot-manager. We use BOOT.INI where we copy the
last line to add a second selection to the XP-boot-menu and change the
partition to the clone-one. Also set the timeout to 30 seconds.

my BOOT.INI looks like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="XP-mce original on
partition 1" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP-mce CLONE on partition
2" /fastdetect

6) Now BEFORE we use SelfImage to clone the first original and running
partition to the second clone partition, we need to alter some keys in
the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices with REGEDIT.EXE Swap the
driveletters from the original and the clone partition with renaming
the key-names.
In my case it was renaming "\DosDevices\C:" to "\DosDevices\D:" and
"\DosDevices\D:" to "\DosDevices\C:"

7) Clone the partitions with SelfImage

8) Restore the registry changes, so rename (swap) the keynames again
before you shutdown !!!!!!!!!

9) You should be able now to make a choice in the windows XP boot-menu
to boot the original or the clone ;-)

I will alter my batch-file to do this automaticly the try to post it
here later .....

Take care and let me know here if you find any problems with this
methot

 

[Timothy Daniels]

"John John" explained:

See in-line (long post):



Yes, that goes without saying ;-) I simply used ntldr, I didn't use a third
party boot manager.




There was only one disk in the machine so only rdisk(0) applies. Remember, my
test only involved "cloning" a partition to the same disk and trying to make
both partitions bootable and usable. The only difference in the two ARC paths
were the partition fields, partition(1) or partition(2).

Yes. My brain fart. I meant that "partition(1)" and
"partition(2)" continued to have their original meanings.



This is where our experiences diverge, albeit the great bulk
of my experience is with putting the clone on a separate HD.
In such a case, the clone continues to call its own partition
"C:" (if that is what the "parent" OS called its own partition),
and it calls the "parent" OS's partition by some other letter
designation. I typically clone a single partition and put it
among other archival clones on another HD. What I see
when each of the clones is run, is that the clone calls its
partition "C:", and the letter designations of all the other
partitions are given other letter assignments. Perhaps that is
due to the "parent" OS being invsible to the clone by my
disconnecting the "parent" OS's hard drive before the clone's
1st run. It would be interesting to see if that scenario plays
out with a single HD if the "parent" OS's partition is hidden
before the clone is booted. It could be that the simple method
of hiding the "parent" OS's partition would remove the need
for diddling in the registry in the case of a single HD.

*TimDaniels*