CloneDisk
#26
Posted 09 August 2009 - 12:38 PM
Can't you simply mount the .vmdk in VDK and clone the PhysicalDrive?
And BTW qemu-img.exe already can do that:
http://forum.winimag...opic.php?t=3266
jaclaz
#27
Posted 09 August 2009 - 01:55 PM
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
Posted 09 August 2009 - 05:57 PM
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
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
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
/Erwan
edit : download latest version (just uploaded right now) and copy paste the vmdk content again.
#30
Posted 09 August 2009 - 06:31 PM
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
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
Posted 09 August 2009 - 06:45 PM
WHAT are you talking about?
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?
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
Posted 09 August 2009 - 07:02 PM
Wait a minute.
WHAT are you talking about?
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?
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
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
Posted 09 August 2009 - 07:20 PM
My getfilesize function was stuck on int32 numbers hence messing big files.
Download new 1.4.4 version.
Thanks,
Erwan.
#35
Posted 09 August 2009 - 07:28 PM
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="monolithicFlat" # Extent description RW 62910540 FLAT "xpusboot.img" 0 # The Disk Data Base #DDB ddb.adapterType = "buslogic" ddb.geometry.sectors = "63" ddb.geometry.heads = "16" ddb.geometry.cylinders = "62412" ddb.virtualHWVersion = "4"
#36
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.
jaclaz
#37
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.
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
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)
jaclaz
#39
Posted 12 August 2009 - 01:42 PM
#40
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
Posted 12 August 2009 - 02:49 PM
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
Posted 12 August 2009 - 02:56 PM
#43
Posted 12 August 2009 - 03:54 PM
See here:
http://www.boot-land...?...=3191&st=21
To extend the given syntax:
dsfo \\.\PHYSICALDRIVE0 0 512 C:\Fullmbr.mbr dsfo C:\Fullmbr.mbr 0 446 C:\Bootcode.mbr dsfo C:\Fullmbr.mbr 446 16 C:\mbrdata1st.mbr dsfo C:\Fullmbr.mbr 462 16 C:\mbrdata2nd.mbr dsfo C:\Fullmbr.mbr 478 16 C:\mbrdata3rd.mbr dsfo C:\Fullmbr.mbr 494 16 C:\mbrdata4th.mbr dsfo C:\Fullmbr.mbr 510 2 C:\magicbytes.mbr
To reassemble:
fsz C:\blankptentry.mbr 16 fsz C:\newmbr.mbr 512 dsfi C:\newmbr.mbr 0 446 C:\Bootcode.mbr dsfi C:\newmbr.mbr 446 16 C:\mbrdata1st.mbr OR dsfi C:\newmbr.mbr 446 16 C:\blankptentry.mbr dsfi C:\newmbr.mbr 462 16 C:\mbrdata2nd.mbr OR dsfi C:\newmbr.mbr 462 16 C:\blankptentry.mbr dsfi C:\newmbr.mbr 478 16 C:\mbrdata3rd.mbr OR dsfi C:\newmbr.mbr 478 16 C:\blankptentry.mbr dsfi C:\newmbr.mbr 494 16 C:\mbrdata4th.mbr OR dsfi C:\newmbr.mbr 494 16 C:\blankptentry.mbr dsfi C:\newmbr.mbr 510 2 C:\magicbytes.mbr dsfi \\.\PHYSICALDRIVE0 0 512 C:\newmbr.mbr
Add your own "sections", like Disk Signature...
jaclaz
#44
Posted 13 August 2009 - 08:56 AM
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
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
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
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
Posted 13 August 2009 - 04:04 PM
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?
#47
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
Posted 13 August 2009 - 07:02 PM
Well, I only tried to provide what is available.
I don't understand the "Reserved" (2 bytes)
@erwan.l
Since you are gonna do it, I would make a slight change to the proposed setup:
MBR____ |CODE (First 440 Bytes+2 Ending Magic Bytes) |SIGNATURE (4 bytes) |DATA (Partition Table 64 Bytes) _____|1st Partition Entry (16 bytes) _____|2nd Partition Entry (16 bytes) _____|3rd Partition Entry (16 bytes) _____|4th Partition Entry (16 bytes)
jaclaz
#49
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)
@erwan.l
Since you are gonna do it, I would make a slight change to the proposed setup:MBR____ |CODE (First 440 Bytes+2 Ending Magic Bytes) |SIGNATURE (4 bytes) |DATA (Partition Table 64 Bytes) _____|1st Partition Entry (16 bytes) _____|2nd Partition Entry (16 bytes) _____|3rd Partition Entry (16 bytes) _____|4th Partition Entry (16 bytes)
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
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.
3 user(s) are reading this topic
0 members, 3 guests, 0 anonymous users