Blinking Cursor when booting restored Ghost image

Question

I create automated deployment scripts for universal workstation images and I've found something I can't work through. I'm hoping someone else has come across this before and I'm just not searching properly, or that i'm missing something blatantly obvious 16 hours in.

Environment:

• Ghost32 11.5
• WinPE 3.0
• Windows XP Sp3 single partition disk image

It appears that any time the target drive is completely blank; after restoration and reboot I am stuck with an endlessly blinking cursor in the top left corner.

I'll detail below the scenarios I've tried so far in hopes someone sees something I've missed.

(In each of these the boot media for WinPE is a Usb drive (which loads WinPE in RAM @ X:) and the target hard drive is a 74Gb internal SATA)

Edit: I thought that Diskpart may be the problem and retried these using Gdisk32 to complete the disk operations with no change to the outcome.

Scenario 1

(Target drive has a working bootable primary ntfs Windows XP partition on it taking up the entire drive.)

I run Diskpart, select the disk (0) and CLEAN it. (Leaving this step out will produce the same results)

I then run ghost32.exe and navigate to local disk from image and select my image, targeting disk 0

Everything works as planned system boots sysprep runs we're good to go.

Scenario 2

(continued from above state)

Boot back into WinPE. Run Diskpart, select disk 0 and CLEAN it. Reboot system back into WinPE.

(I verified that disk 0 is empty)

I run ghost32.exe as above and restore the disk from image.

Blinking cursor without end.

If I reboot into WinPE and restore again at this point it will work, essentially the same as scenario 1 only it was [not] working before hand.

Scenario 3

(thinking that it may have something to do with the drive letter assignment within WinPE and changes that Ghost32 may make to the restored disk)

I boot into WinPE and CLEAN disk 0, then reboot again.

When the target drive is blank the source drive receives the C: drive letter within WinPE. Once restored the newly created partition will receive a later letter (E: in this instance, the Cd-Rom drive receives D: [It is empty]).

Booted back into WinPE; I enter Diskpart and reassign the drive letter of the source drive from C: to W: and exit Diskpart.

I run ghost32.exe as above and restore the disk from image.

Blinking cursor without end.

Scenario 4

(Booted, cleaned, and rebooted again)

I enter Diskpart and create a primary partition on disk 0 (Tried both RAW and formatted as NTFS on two different attempts).

I run ghost32.exe as above and restore the disk from image over the newly created partition.

Blinking cursor without end.

Scenario 5

(Booted, cleaned, and rebooted again)

I enter Diskpart and create a primary partition on disk 0 that is 10MB in size, unformated RAW and not ACTIVE.

I reboot the system back into WinPE (source still receives drive C: as it is the only formatted partition) I run ghost32.exe as above and restore the disk from image. ...

Everything works as intended, sysprep runs and desktop comes up.

Question

Why in the world does there need to be a partition on the target drive at the time that the build OS starts for Ghost32 to produce a workable recovered disk?

What am I doing wrong here, I have got to be missing something. If I'm recovering an entire disk why would it matter what was [or more precisely; wasn't] on the target disk prior to the restore. I should be getting an exact copy of the original which was also disk 0 and the only drive on the system.

Any help here would be greatly appreciated, I'm ready to rip my hair out. I don't really want to have to script in creating a raw partition and forcing a reboot on detection of a blank target (which is the most likely scenario when someone is rebuilding a workstation).

Follow Up

The problem only appears to occur on HP nc6400 Laptops. I've yet to find another model of workstation that will recreate the problem. I've now been able to test on several and they all exhibit the same behavior (lucky for me we just pulled all of these from the field due to age).

The problem does NOT occur using the same image when loaded from a Dvd; So it does appear to be related to the source media. I had thought it might be the way the system was detecting the USB drive (Some treat them as removable media, others as fixed disks), but on another system I had at my disposal that allowed for control over this option failed to exhibit the same problem in either mode.

When restoring the system using ImageX the problem does not occur, so it appears to be an issue with the way this particular system is treating the USB drive and the post restoration operations that Ghost32 performs.

Answer 1

It sounds like a Ghost bug. One thing I don't see, or may be missing: Have you tried scripting diskpart to clean, create, activate, and assign all at once?

Answer 2

Can you hit F8 during the boot and go into command line recovery mode? If you get there try either FIXBOOT or, if that doesn't work, run CHKDSK /r.

Answer 3

Unfortunately this question only just showed up today in my RSS reader, so even though it's a couple years old I thought I'd offer what is probably the right answer for future readers.

I'm not familiar with the particular model you describe as affected, but this does sound rather similar to a problem which occurred in certain models of ThinkPad (my memory says T60) which used a non-standard multisector MBR that occupied several sectors of the boot track rather than the usual one, with the results being identical to what you describe.

Ghost's classic imaging format prior to the introduction of the -IB switch stored only the original single MBR sector; this means that images of systems which actually have nonstandard, multisector boot track content only have half of the necessary boot code in them.

In almost all situations where the source image was not taken with the -IB switch, if Ghost detects boot code in the target disk you are restoring to, it tends to leave the original boot code intact and just manipulates the partition table within the boot sector. This is by design to deal with systems that did use special boot code (such as those with boot-sector hooks to replace the BIOS), and means that in most cases if the target system needed such custom boot code it would be left alone and would continue to boot.

However, if the target disk is completely blank, Ghost will use the boot code from the image for the MBR sector. If, as with the ThinkPad case we found in our QA labs, you have taken the image with no extra switches then the sector it restores tries to load the rest of itself from later sectors in the boot track that by default Ghost leaves alone.

So, you have several options; you can use gdisk /mbr after restoring to force the use of a standard "safe" MBR instead of a manufacturer custom MBR, or you can use the -IB switch with Ghost when capturing the source image to force Ghost to image all the sectors in the boot track rather than just the MBR.

The above is what we discovered in our labs in Auckland where we developed Ghost (until 2009, when Symantec closed the site and cancelled development of the Ghost Solution Suite product); Krish Jayaratne who was our QA manager discovered this and did the main investigation as to the workarounds and it just then took a little inspection to confirm the presence of the extra boot code.

While your situation may not be the same, it certainly sounds exactly like that case and I suspect the resolution should be the same. I did walk customers through this a couple of times on the official Symantec forums and it was documented fairly thoroughly, but since the Ghost Solution Suite product was cancelled Symantec lost most of the institutional knowledge around this stuff.

---

Edit to add: as I noted above, Ghost on restore by default for "normal" images leaves boot code in the MBR totally alone if an existing MBR is present. However, if the -IB switch was used to capture an image that fact is recorded as part of the image file meta-data (in fact, this is true of quite a lot of the switches; part of the obfuscated file header has a big 'ol bit array in it populated from the global variables - yes, really - that the argument parser extracts the command-line switches into). So not only do images taken with -IB have a subtly different structure to accomodate the extra boot sectors, the restore side of the process "knows" that -IB was used to take the image.

My recollection of the process (although I don't have the source code any more to confirm it) is that if -IB was used to capture an image, by default the boot code and extra boot sectors would then always be restored, making the restore process have the opposite default handling of boot code to the regular images. Part of the logic behind that is that the restore UI doesn't have the boot code stored in the image in a selectable container - you don't have a way of expressing the choice of whether to restore it or not easily (adding that would be a bit of a usability complication; UI is never "free" if people don't grasp what it means). The other is that some of the most important users of Ghost were computer manufacturers who licensed it for their OEM restore disks; if a computer manufacturer's factory restore image contained custom boot code for some reason, then normally by default they'd want it put back and having -IB also imply that slight difference in behaviour on restore seemed like the "right" default.

It was always a delicate balancing act with these fancy special cases deciding whether to make the fiendishly complicated command line even more complicated or adding a new piece of UI to make things more explicit, versus trying to do the "Right Thing" by default for most people and not making the default UI complicated. There's no argument that we didn't always choose right, but we did always agonize over that balance, especially since we had millions of customers with scripts that we wanted not to break.