Ghost Solution Suite

Hi,

are there some specific options to use when cloning a GPT disk ?

I have a GPT disk with two partitions (C: and E:) and W2K3 installed in the C: drive.
I have captured the disk with no additional option.
I can open the image captured with Explorer and see the two partitions inside and their contents.

I have cloned the image captured on an empty disk but :
- the cloned disk is MBR (instead of GPT)
- the syste mboots but I cannot open a session (I saw drive letters were not assigned to the proper partitions).

I have also tried to "prepare" the target disk by running "gdisk32 1 /gpt /wipe" in WinPE before cloning to force a GPT target disk but, after the image has been cloned, the system cannot boot.

Did I miss something at capture or cloning time ?
(I use the GSS 2.5 release).

Thanks,
Jean-Pierre

Hi Jean-Pierre, What are the hardware details of your machine(s)? If it is a x86 or a x64 machine, perhaps this article on Microsoft TechNet might give you insight on it - http://www.microsoft.com/whdc/device/storage/GPT-on-x64.mspx Regards, Kartik

Hi Kartikeya,

the version of Windows installed  on the server to capture is Windows Server 2003 x86 Standard Edition with SP2.

As the capture/restore did not work "as is", I was wondering if additional options were required for ghost32
to make the capture or the cloning of the image.

Thanks,
Jean-Pierre

Hi Jean-Pierre,

Thanks for the information about the server version.  

Could you please also post the output from running the following gdisk32 commands on the server to capture?

gdisk32 /raw
gdisk32 1
gdisk32 <n> (if there are any additional hard disks installed in the system identified by the gdisk32 /raw output - e.g. 'gdisk32 2')

Are you using disk or partition operations with ghost?

Also - when you capture the image, are you capturing from the OS Volumes disk (drive 80) or drive 1?  I ask because the OS volumes 'disk' represents itself as a GPT disk, even if the physical system drive is an MBR disk.  This is so that it can address all volumes that might be present in the system.  Generally the OS volumes disk is useful for creating and restoring images from/to volumes that ghost would not otherwise recognize.

I'd recommend using ghost to capture disk 1 using a disk operation and then restore disk 1 to the intended target server (again using a disk operation).  Ghost normally is able to update drive letters with any changes in the underlying partitions.  However if the drive letters are not being properly preserved you could try running the ghost restore with the switches "-fdsp -szee".  The first, -fdsp, will cause the disks ID (or signature) to be preserved and the second "-szee" in a disk restore will cause the partitions to be restored to the same size & therefore (typically) start locations as the original disk.  Through not changing the disks signature or partition offsets the drive letters are then also typically correct.

If when using a disk create (from disk 1) and disk restore to the target the operation is still not successful, it would also be useful to see a ghosterr.txt file generated while either creating or restoring the disk image (easiest way to generate this is to hit CTRL-C while the operation is in progress).

Thanks, Robert.

Hi Robert,

thanks for the answer.

I'm sorry that I cannot provide immediatly the results for the gdisk32 commands you suggested :
the server is a production machine that I cannot currently access.

The goal of the capture/cloning operation on this server is to migrate the system disk from a 36 GB device to a 73 GB one.

We have done disk operations :
- capture an image of disk 1  in a "New Image Create" task  (using no additional flag)
- replace the system disk by a new and empty one (a 73 GB disk) then restore the captured image on this new device, once with options to resize partitions on the disk during the cloning and a second time with no additional option.

From a GSS point of view, there is no error reported, neither during the capture nor during the cloning operation.

When the system restarts after cloning, it can boot but we are unable to open a session :
if we try to connect, we can enter user name and password information but after a few seconds the system returns to the connection screen.

After this session opening failure, I restarted the server in WinPE and executed the "gdisk32 1" command and I could see :
- the cloned disk was in MBR format though the original one was a GPT disk
- the partitions were allocated wrong drive letters : the first partition had D: drive letter (instead of C: on the original disk) and the second one had C: (instead of E:). I think this wrong allocation is the reaon of the session opening failure.

That's why I was asking if I missed some needed option either during the GPT disk capture task or in the cloning task.

Thanks,
Jean-Pierre

Hi Jean-Pierre,

Thanks for the additional information.  The capture sounds fine - a disk image create for this situation sound good.

For your restore image task, are you using any other task steps or options other than clone?  (e.g. SID change, DA, configuration?)

I'd suggest adding  the command line option '-fdsp' to your next restore task.  This forces the disk identification to be preserved and therefore will likely help with your drive letter assignments.  Note that this should not typically be required as ghost will correct the drive assignments as part of restore, but it appears that something else might be happening here.

Further than this, I think I'll need the gdisk32 output and ghost32 error file.  Note that the gdisk32 output can be gathered by a terminal services session to the server while 2k3 x86 is running as the operations I mention above are 'read only'.

Cheers, Robert.