Jump to content











Photo
* * * * * 4 votes

CloneDisk


  • Please log in to reply
564 replies to this topic

#26 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 09 August 2009 - 12:38 PM

@ktp
Can't you simply mount the .vmdk in VDK and clone the PhysicalDrive? :idea:

And BTW qemu-img.exe already can do that:
http://forum.winimag...opic.php?t=3266

:P

jaclaz

#27 ktp

ktp

    Silver Member

  • Advanced user
  • 733 posts

Posted 09 August 2009 - 01:55 PM

@erwan.l and @jaclaz
Thank you for your help. Currently I use CloneDisk inside the VMware virtual machine (online method), but qemu-img.exe would be more convenient for automatization/batch file.

Maybe CloneDisk could have Disk Image <-> VMDK for symmetrical reason, as it already has
Disk <-> Disk and Image <-> Disk.

#28 ktp

ktp

    Silver Member

  • Advanced user
  • 733 posts

Posted 09 August 2009 - 05:57 PM

I have a disk image file xpusboot.img 32 210 196 400 bytes.
It is used by Starwind and booting over iSCSI using it is fine.

clonedisk create xpusboot.img.vmdk file with content:

# Disk DescriptorFile
version=1
CID=ded23225
parentCID=ffffffff
createType="monolithicFlat"
# Extent description
RW 4190284 FLAT "xpusboot.img" 0
# The Disk Data Base
#DDB
ddb.adapterType = "buslogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "4158"
ddb.virtualHWVersion = "4"
---

Under VMWare adding this vmdk file, I see that hard disk size is only 2 GB, and the virtual machine
boot failed. Am I missing something?

#29 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 09 August 2009 - 06:08 PM

I have a disk image file xpusboot.img 32 210 196 400 bytes.
It is used by Starwind and booting over iSCSI using it is fine.

clonedisk create xpusboot.img.vmdk file with content:

# Disk DescriptorFile
version=1
CID=ded23225
parentCID=ffffffff
createType="monolithicFlat"
# Extent description
RW 4190284 FLAT "xpusboot.img" 0
# The Disk Data Base
#DDB
ddb.adapterType = "buslogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "4158"
ddb.virtualHWVersion = "4"
---

Under VMWare adding this vmdk file, I see that hard disk size is only 2 GB, and the virtual machine
boot failed. Am I missing something?


it is a bug I just found out today :idea:
will be fixed in a couple of minutes.
i should used 63 as sectors for image below 32gig and 255 for bigger images.
at least i think so : you'll be my beta tester :P

/Erwan

edit : download latest version (just uploaded right now) and copy paste the vmdk content again.

#30 ktp

ktp

    Silver Member

  • Advanced user
  • 733 posts

Posted 09 August 2009 - 06:31 PM

>edit : download latest version (just uploaded right now) and copy paste the vmdk content again.

Nothing is changed in version 1.4.3, same content of vmdk produced as before.

Suggestion: add to the produced vmdk file a signature of the CloneDisk version, e.g.:
# produced by CloneDisk version 1.4.3

#31 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 09 August 2009 - 06:42 PM

>edit : download latest version (just uploaded right now) and copy paste the vmdk content again.

Nothing is changed in version 1.4.3, same content of vmdk produced as before.

Suggestion: add to the produced vmdk file a signature of the CloneDisk version, e.g.:
# produced by CloneDisk version 1.4.3


seems i am messing wiht my numbers when setting the geometry of big files (above 8gig).
will correct it asap.

about the suggestion, very good idea, thanks!

/Erwan

#32 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 09 August 2009 - 06:45 PM

Wait a minute.

WHAT are you talking about? :idea:

Sectors can be ONLY 32 or 63.
Heads can be 16 64 128 255. (with the notable exception of the "stupid" laptops that use 240)

Common geometries are:
16/63
64/32
128/63
255/63

AFAIK normally used one in VMware is 255/63 (maybe 16/63 is used for very small ones).

32 Gb is a "strange" boundary.

The "switch" should be at any of the traditional boundaries:
http://www.pcguide.c...d/bios/size.htm

Or maybe you are referring to the 65,536 cylinders one? :P
http://www.pcguide.c...izeGB315-c.html

In any case, you shouldn't "invent" a geometry, but rather read it from the data in the MBR of the source image, it could be an image with a different geometry, and eventually offer a "conversion service" to 255/63.


jaclaz

#33 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 09 August 2009 - 07:02 PM

Wait a minute.

WHAT are you talking about? :idea:

Sectors can be ONLY 32 or 63.
Heads can be 16 64 128 255. (with the notable exception of the "stupid" laptops that use 240)

Common geometries are:
16/63
64/32
128/63
255/63

AFAIK normally used one in VMware is 255/63 (maybe 16/63 is used for very small ones).

32 Gb is a "strange" boundary.

The "switch" should be at any of the traditional boundaries:
http://www.pcguide.c...d/bios/size.htm

Or maybe you are referring to the 65,536 cylinders one? :P
http://www.pcguide.c...izeGB315-c.html

In any case, you shouldn't "invent" a geometry, but rather read it from the data in the MBR of the source image, it could be an image with a different geometry, and eventually offer a "conversion service" to 255/63.


jaclaz


indeed, i feel lost right now.
i felt i had mastered the topic but i just got confused again :)

and this would explain my struggling with the vhd part...

but default my CHS would always be c*16*63.
then based on the number of sectors, i would calculate the cylinders.
when getting the chs for a raw image file, i would get the total size, divide it by 512 to get the number of sectors and calculate the CHS again.
may be indeed, i should get the chs right from within the image although i am not sure i can find it in the mbr or bs.

what you say is that sectors should always be 63 or 32?
ouch :P

would this be right then?
heads:=16;
sectors:=63;
if (Total_Sectors >= (65535 * 16 * 63)) then
begin
heads:= 64;sectors:=32;
end;
if (Total_Sectors >= (65535 * 64 * 32)) then
begin
heads:= 128;sectors:=63;
end;
if (Total_Sectors >= (65535 * 128 * 63)) then
begin
heads:= 255;sectors:=63;
end;
cylinders:=(total_sectors div heads div sectors)+1;

Regards,
Erwan.

#34 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 09 August 2009 - 07:20 PM

@ktp, in the meantime, I fixed the vmdk geometry issue.
My getfilesize function was stuck on int32 numbers hence messing big files.
Download new 1.4.4 version.

Thanks,
Erwan.

#35 ktp

ktp

    Silver Member

  • Advanced user
  • 733 posts

Posted 09 August 2009 - 07:28 PM

@erwan.l

With version 1.4.4 the vmdk file produced is OK. My virtual machine using it boots OK now.
Thank you.

# produced by CloneDisk

# Disk DescriptorFile

version=1

CID=ded23225

parentCID=ffffffff

createType=&#34;monolithicFlat&#34;

# Extent description

RW 62910540 FLAT &#34;xpusboot.img&#34; 0

# The Disk Data Base

#DDB

ddb.adapterType = &#34;buslogic&#34;

ddb.geometry.sectors = &#34;63&#34;

ddb.geometry.heads = &#34;16&#34;

ddb.geometry.cylinders = &#34;62412&#34;

ddb.virtualHWVersion = &#34;4&#34;


#36 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 09 August 2009 - 07:37 PM

what you say is that sectors should always be 63 or 32?


No.
You seem to be making some confusion between Head and Sectors.
In CHS:
C is Cylinders (variable in function of size)
H is Heads variable, but that can only be 255-128-64-16 (+as said, the stupid 240)
S is Sectors that can only be 32-63

Then there are "commonly used geometries".
Older was nx16x63 as said still used for small images, as an example in Qemu.
Then there was the nx64x32 used in ZIP disks and in early NT 3.51 and 4.0.
Then the nx128x63 rarely used.
Then the "stupid" nx240x63 used by some laptops (LENOVO)
Then the "usual" nx255x63.

The BIOS of a real or Virtual Machine may default to a given geometry, for certain ranges of images.
Qemu for example uses 16/63 for smallish images and 255/63 for bigger ones, but the "switch", if I am not mistaken, is at the "proper" boundary the CHS limit of 1024x16x63 i.e. 528,482,304
http://www.pcguide.c...izeMB504-c.html

2K, XP, 2003 and Vista/7 will always default to nx255x63 (but then everything will be accessed as LBA, so, NO problem, but MBR code and bootsector code is "sensible" to accurate geometry).
If you format/partition a USB stick under any of the above, it will use nx255x63 geometry, even if it is a small 1 or 2 Gb one.

The point I was trying to make is that NO MATTER what you or VMware think, you shouldn't change the geometry of the source .img.

And the only way to do so is to read the actual information inside the image MBR and translate it to the .vmdk descriptor file, WITHOUT assuming that a given geometry is used, or calculating it in a "logical" way, there is absolutely NO logic in the mess they made for years in this rather narrow field:take your time to read the given links to be able to appreciate the incredible amount of flawed designs and shortsightedness used for years in MBR's, bootsectors and filesystems.

:idea:

jaclaz

#37 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 09 August 2009 - 07:59 PM

No.
You seem to be making some confusion between Head and Sectors.
In CHS:
C is Cylinders (variable in function of size)
H is Heads variable, but that can only be 255-128-64-16 (+as said, the stupid 240)
S is Sectors that can only be 32-63

Then there are "commonly used geometries".
Older was nx16x63 as said still used for small images, as an example in Qemu.
Then there was the nx64x32 used in ZIP disks and in early NT 3.51 and 4.0.
Then the nx128x63 rarely used.
Then the "stupid" nx240x63 used by some laptops (LENOVO)
Then the "usual" nx255x63.

The BIOS of a real or Virtual Machine may default to a given geometry, for certain ranges of images.
Qemu for example uses 16/63 for smallish images and 255/63 for bigger ones, but the "switch", if I am not mistaken, is at the "proper" boundary the CHS limit of 1024x16x63 i.e. 528,482,304
http://www.pcguide.c...izeMB504-c.html

2K, XP, 2003 and Vista/7 will always default to nx255x63 (but then everything will be accessed as LBA, so, NO problem, but MBR code and bootsector code is "sensible" to accurate geometry).
If you format/partition a USB stick under any of the above, it will use nx255x63 geometry, even if it is a small 1 or 2 Gb one.

The point I was trying to make is that NO MATTER what you or VMware think, you shouldn't change the geometry of the source .img.

And the only way to do so is to read the actual information inside the image MBR and translate it to the .vmdk descriptor file, WITHOUT assuming that a given geometry is used.

:idea:

jaclaz


oki, got it.
actually when dumping or restoring disk <-> image, geometry is irrelevant as i do byte to byte and i therefore never modify the geometry or any other bit in the source image.
it is only when i create a vmdk or a vhd that i need to get the geometry to add it in the vmdk file or as a footer in the vhd file.

for vmdk, going for standard geometry as listed above worked fine.
for vhd, getting the real geometry from the disk never allowed me to boot it but when going for n*16*63 i did manage to boot fine.

going to review this part...
do you have tools (yours? sanbarrow?) you can point me to have a look?
these tools would then read the geometry from the mbr from within the img file? i thought that that information was actually handled by the bios and therefore only retrievable live.

Regards,
Erwan.

#38 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 10 August 2009 - 08:12 AM

going to review this part...
do you have tools (yours? sanbarrow?) you can point me to have a look?
these tools would then read the geometry from the mbr from within the img file? i thought that that information was actually handled by the bios and therefore only retrievable live.


Well, the idea is that when the source image was originally partitioned/formatted, it was mounted with a given geometry (depending on the BIOS or the OS on which it was originally mounted/partitioned/formatted), and thus this given geometry is reflected in both the MBR and in the bootsector of the various partitions.
(Theoretically it is possible to have a number of partitions with different geometries - different among them and different from that on the MBR - but unless it has been made "on purpose" it will never happen in real life)

To get the geometry from the MBR:
http://www.boot-land...?showtopic=2959
(I just posted there a newish version of a spreadsheet that should illustrate quite clearly the procedure)

To get it from a bootsector:
FAT12/16/32 and NTFS:
Sectors at offset 0x18 (2 bytes)
Heads at offset 0x1A (2 bytes)

:idea:

jaclaz

#39 niteflyer

niteflyer
  • Members
  • 6 posts
  •  
    Germany

Posted 12 August 2009 - 01:42 PM

One question: I haven't yet tested CloneDisk. I am looking for a tool, which will only restore the bootcode of a previously saved MBR, without overwriting the partition table of the target disk. Is/Will this be possible with CloneDisk? I assume, that CloneDisk currently restores the whole MBR, right? In this case, I will get trouble when applying the MBR-Backup of a disk to another one with a different size/geometry!

#40 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 12 August 2009 - 02:46 PM

One question: I haven't yet tested CloneDisk. I am looking for a tool, which will only restore the bootcode of a previously saved MBR, without overwriting the partition table of the target disk. Is/Will this be possible with CloneDisk? I assume, that CloneDisk currently restores the whole MBR, right? In this case, I will get trouble when applying the MBR-Backup of a disk to another one with a different size/geometry!


Hi niteflyer,
With Clonedisk you can either restore the MBR (to a physical drive) or the BS (to a logical drive / partition).
Regarding geometry, when backuping / restoring MBR/BS, clonedisk does not deal with that as it simplt deals with direct copy of sectors (512 bytes).

Regards,
Erwan.

#41 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 12 August 2009 - 02:49 PM

Update: I have added some command lines to clonedisk.
Note : "|" stands for or

-disk \\.\PhysicalDriveX|\\.\X: \\.\PhysicalDriveY|\\.\Y:

-image -backup raw|gzip|vhd \\.\PhysicalDriveX|\\.\X: c:\dest.img

-image -restore raw|gzip c:\src.img \\.\PhysicalDriveX|\\.\X:

-infos \\.\PhysicalDriveX|\\.\X: c:\infos.txt

-wipe \\.\PhysicalDriveX

-sparse c:\dest.img 2147483648

-mbr -backup \\.\PhysicalDriveX c:\dest.mbr

-mbr -restore c:\src.mbr \\.\PhysicalDriveX

-bs -backup \\.\X: c:\dest.mbr

-bs -restore c:\src.bs \\.\X:

Regards,
Erwan.

#42 niteflyer

niteflyer
  • Members
  • 6 posts
  •  
    Germany

Posted 12 August 2009 - 02:56 PM

Thanks Erwan for the quick reply. Up to now I was using HDHacker for restoring the bootcode of an MBR, but I never dared to apply a backup to disk with different size, so I asked the same question to the author of HDHacker. Unfortunately I never got an answer. My idea (for my purpose) was to overlay the backup with the MBR of the current disk so that only the first 440 bytes will get replaced. Maybe it would be possible to optionally enable the overwrite of the disk signature (next for bytes) and the next two reserved byte (see http://en.wikipedia....er_boot_record) to make it perfect. So you could have the choice which part(s) of the MBR will be rewritten with the backup.

#43 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 12 August 2009 - 03:54 PM

@niteflyer
See here:
http://www.boot-land...?...=3191&st=21

To extend the given syntax:
dsfo \\.\PHYSICALDRIVE0 0 512 C&#58;\Fullmbr.mbr

dsfo C&#58;\Fullmbr.mbr 0 446 C&#58;\Bootcode.mbr

dsfo C&#58;\Fullmbr.mbr 446 16 C&#58;\mbrdata1st.mbr

dsfo C&#58;\Fullmbr.mbr 462 16 C&#58;\mbrdata2nd.mbr

dsfo C&#58;\Fullmbr.mbr 478 16 C&#58;\mbrdata3rd.mbr

dsfo C&#58;\Fullmbr.mbr 494 16 C&#58;\mbrdata4th.mbr

dsfo C&#58;\Fullmbr.mbr 510 2 C&#58;\magicbytes.mbr

To reassemble:
fsz C&#58;\blankptentry.mbr 16

fsz C&#58;\newmbr.mbr 512

dsfi C&#58;\newmbr.mbr 0 446 C&#58;\Bootcode.mbr 

dsfi C&#58;\newmbr.mbr 446 16 C&#58;\mbrdata1st.mbr  OR dsfi C&#58;\newmbr.mbr 446 16 C&#58;\blankptentry.mbr

dsfi C&#58;\newmbr.mbr 462 16 C&#58;\mbrdata2nd.mbr  OR dsfi C&#58;\newmbr.mbr 462 16 C&#58;\blankptentry.mbr

dsfi C&#58;\newmbr.mbr 478 16 C&#58;\mbrdata3rd.mbr  OR dsfi C&#58;\newmbr.mbr 478 16 C&#58;\blankptentry.mbr

dsfi C&#58;\newmbr.mbr 494 16 C&#58;\mbrdata4th.mbr  OR dsfi C&#58;\newmbr.mbr 494 16 C&#58;\blankptentry.mbr

dsfi C&#58;\newmbr.mbr 510 2 C&#58;\magicbytes.mbr

dsfi \\.\PHYSICALDRIVE0 0 512 C&#58;\newmbr.mbr

Add your own "sections", like Disk Signature...

:idea:

:P

jaclaz

#44 bilou_gateux

bilou_gateux

    Frequent Member

  • Expert
  • 230 posts
  •  
    France

Posted 13 August 2009 - 08:56 AM

Salut Erwan,

Currently, i use AccessData FTK Imager Lite to backup UFDs to a safe place.

One feature i like is the ability to display description of physical drive: \\.\PHYSICALDRIVEx Swissbit pitchBLACK USB Device
Posted Image
I have 3 UFDs to backup and it help me select the good one!

Could this feature been added to your program.

Other feature is the image summary of backup output in .txt
test.001.txt

#45 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 13 August 2009 - 10:09 AM

Salut Erwan,

Currently, i use AccessData FTK Imager Lite to backup UFDs to a safe place.

One feature i like is the ability to display description of physical drive: \\.\PHYSICALDRIVEx Swissbit pitchBLACK USB Device
Posted Image
I have 3 UFDs to backup and it help me select the good one!

Could this feature been added to your program.

Other feature is the image summary of backup output in .txt
test.001.txt


Hi Bilou_gateux,
Nice suggestion.
I believe I should be able to add that feature quickly.
Will keep you posted.

Regards,
Erwan.

#46 niteflyer

niteflyer
  • Members
  • 6 posts
  •  
    Germany

Posted 13 August 2009 - 04:04 PM

@jaclaz:

Yes, I know one could use several workarounds to assemble/patch a MBR-file, but I am expecting something like this from a GUI-tool (see attachment). The restriction that we may only write in units of 512 bytes does not prevent from changing certain portions within this sector in memory before writing it to disk: read the target-MBR to memory and replace the checked options with the corresponding sections of a saved MBR-file and finally write it back to disk. ceca...

@erwan:
Can you implement this?

Attached Thumbnails

  • Clipboard02.jpg


#47 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 13 August 2009 - 05:06 PM

@jaclaz:

Yes, I know one could use several workarounds to assemble/patch a MBR-file, but I am expecting something like this from a GUI-tool (see attachment). The restriction that we may only write in units of 512 bytes does not prevent from changing certain portions within this sector in memory before writing it to disk: read the target-MBR to memory and replace the checked options with the corresponding sections of a saved MBR-file and finally write it back to disk. ceca...

@erwan:
Can you implement this?


Hi NiteFlyer,
That could easily be added.
By default, all will be checked so the entire mbr would be saved.
Advanced users could save only portions of the mbr.
Then I guess I will add a concat feature in clonedisk as well so one can re assemble 2 files together to reconstruct a mbr (or else).

Regards,
Erwan.

#48 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 13 August 2009 - 07:02 PM

@niteflyer
Well, I only tried to provide what is available. ;)

I don't understand the "Reserved" (2 bytes) :unsure:


@erwan.l
Since you are gonna do it, I would make a slight change to the proposed setup:
MBR____

	|CODE &#40;First 440 Bytes+2 Ending Magic Bytes&#41;

	|SIGNATURE &#40;4 bytes&#41;

	|DATA &#40;Partition Table 64 Bytes&#41;

	_____|1st Partition Entry &#40;16 bytes&#41; 

	_____|2nd Partition Entry &#40;16 bytes&#41; 

	_____|3rd Partition Entry &#40;16 bytes&#41; 

	_____|4th Partition Entry &#40;16 bytes&#41;

:frusty:

jaclaz

#49 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 13 August 2009 - 07:53 PM

@niteflyer
Well, I only tried to provide what is available. ;)

I don't understand the "Reserved" (2 bytes) :unsure:


@erwan.l
Since you are gonna do it, I would make a slight change to the proposed setup:

MBR____

	|CODE &#40;First 440 Bytes+2 Ending Magic Bytes&#41;

	|SIGNATURE &#40;4 bytes&#41;

	|DATA &#40;Partition Table 64 Bytes&#41;

	_____|1st Partition Entry &#40;16 bytes&#41; 

	_____|2nd Partition Entry &#40;16 bytes&#41; 

	_____|3rd Partition Entry &#40;16 bytes&#41; 

	_____|4th Partition Entry &#40;16 bytes&#41;

:frusty:

jaclaz


On my side, thanks for these explanations : it will help me add some features to clonedisk.
Tools like dsfo, dsfi and fsz are great tools especially when it comes to batch.

Thanks,
Erwan.

#50 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1920 posts
  • Location:Nantes - France
  •  
    France

Posted 14 August 2009 - 01:00 AM

Hi Bilou_gateux,
Nice suggestion.
I believe I should be able to add that feature quickly.
Will keep you posted.

Regards,
Erwan.



edit : latest version now display the volumename for logical drives and the productid for physical drives to match your request.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users