Can't you simply mount the .vmdk in VDK and clone the PhysicalDrive?
![:idea:](http://reboot.pro/public/style_emoticons/default/idea.gif)
And BTW qemu-img.exe already can do that:
http://forum.winimag...opic.php?t=3266
![:P](http://reboot.pro/public/style_emoticons/default/tongue.png)
jaclaz
Posted 09 August 2009 - 12:38 PM
Posted 09 August 2009 - 01:55 PM
Posted 09 August 2009 - 05:57 PM
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?
Posted 09 August 2009 - 06:31 PM
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
Posted 09 August 2009 - 06:45 PM
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
Posted 09 August 2009 - 07:20 PM
Posted 09 August 2009 - 07:28 PM
# 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"
Posted 09 August 2009 - 07:37 PM
what you say is that sectors should always be 63 or 32?
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
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.
Posted 12 August 2009 - 01:42 PM
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!
Posted 12 August 2009 - 02:49 PM
Posted 12 August 2009 - 02:56 PM
Posted 12 August 2009 - 03:54 PM
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
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
Posted 13 August 2009 - 08:56 AM
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
Posted 13 August 2009 - 04:04 PM
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?
Posted 13 August 2009 - 07:02 PM
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)
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
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.
0 members, 3 guests, 0 anonymous users