Ghost 12 (10561) images will not boot on restore (Grub2/Linux)


Article ID: 170914


Updated On:


Ghost Solution Suite


Imaging a specific volume within a RAID array on a machine.  There are two or more volumes on this RAID array with each being a different size.  One of these volumes is a Linux volume (ext3 filesystem) and utilizes GRUB2.  Only the Linux/GRUB2 volume is being captured.  Ghost is able to capture an image of the Linux volume successfully and is also able to successfully deploy it.  After the image has been deployed, GRUB2 crashes displaying the boot menu and the system restarts.

Ghost 11.51 is able to successfully capture and deploy an image of this Linux volume without this issue.

There are no Symantec errors during the imaging process.  Ghost successfully captures and deploys the image. 


It is believed that this issue is being caused by missing/incorrect information in the boot sector.  Specifically, sector 0:0x5C-0x5D - this is supposedly in the bootstrap area.  A restored (and functional) Ghost 11.51 image has 0x01 0x00. The Ghost 12 counterpart has 0xDC 0x43 in this position.


Ghost Standard Tools 3.2 RU4 (Ghost.exe build 12.10561)

Image created with -ib flag set

Ghost is being executed from a separate bootable drive with a WinPE environment (Not built by Boot Disk Creator)

UEFI support machines that are running in Legacy mode

Open SUSE Leap 42.2 (This may also affect other supported versions of Linux)


Currently there isn’t a solution to this issue.  Development is researching the issue.  Please subscribe to this tech article so that you can receive updates once this tech article has been updated.

Setting the 2 bytes (mentioned above) to 0x01 0x00 allows THIS system to boot normally.  As a possible work-around you can capture the boot sector (or entire “boot area” – sectors 0-63) prior to imaging and then restore it after the image is restored.  This will not work if the partition table is altered on the target system.