ckcc and Brian

Based on your responses--my Ghost 2003 is not acting like your Ghost 2003--been daydreaming of what could be the difference, and suddenly Dan's comment about not knowing for sure what variables are being controlled popped into my head.

Did either of you start a disk editor in DOS and look at the MBR Sector--i.e. Absolute Sector Zero?  After using GDisk to zero out the whole HDD, I did, and sector 0 was definitely all zero's--if your HDD's had the former copy of the Partition Table--or at least some remnants of it, perhaps that explains it. 

Maybe if Ghost detects any evidence of a previous Partition Table, it will allow for using *Local > Partition > From Image* even if the Table now says all space is *unallocated*. 

Maybe an existing Partition Table that *states* that all space is unallocated is different than an all zeroed out Partition Table in the MBR!

I will have to check that option--may be a few days before I get to it however.

NightOwl,

I think we have a cultural clash. Aussies usually regard “tick off” as “untick”. Not all of us, but I didn’t click with your intention. It reminds me of John Cleese’s, “The three differences between American and British people”

http://en.wikiquote.org/wiki/John_Cleese



Also http://www.weblink.com.au/login/login_problems.asp?GroupID=902 ; for Tick off.

Enough semantics. I’ll try your test.

NightOwl,

I used the same HDs as in Reply #19.

Using Ghost 10, I imaged the OS partition (5005 MB partition) writing the image to the second HD. I removed the HD and replaced it with the 20 GB HD. Using MBRWork I "Reset MBR to zero". I checked with Dan's de.exe and the MBR was all zeros. From the RE the image was restored using the usual settings including Restore MBR. The OS booted normally but there were no other partitions on the first HD.  Using a PM CD, on the first HD there was only a primary partition and the remainder was unallocated space.

I took the opportunity of again zeroing the MBR (and checking for all zeros). I tried to restore the Ghost 2003 image to Unallocated Space and as you found, it was greyed out. Clever.

Couple comments on NightOwl's reply #36:

(BTW, the third link in NightOwl's index erroneously links to a description of an NTFS partition boot record instead of an MBR description.)



I think that's technically misleading.  The MBR boot code was changed to support Int13 Extensions.  Win95b did coincidentally introduce the FAT32 file system, but the thing that makes a Win95b MBR different from earlier MBRs is its Int13 Ext support.

Int13 Extensions is a patch that manufacturers began incorporating into the bios, and which supplemented the standard Int13 functions--the set of bios routines responsible for disk drive operations.  Standard routines only addressed disk sectors in CHS (cylinder-head-sector) terms.  Int13 Ext added LBA, in which sectors are addressed by absolute sector number.  Since cylinder values can only be in the range of 0-1023, CHS terms would not allow a MBR to hand the boot process off to a partition boot record if the partition began beyond the 1024th cylinder.  In contrast, a Win95b MBR could check if the bios supported Int13 Ext, and if so, it could switch from CHS to LBA in order to load the partition boot record.  This enabled the booting of partitions beyond the 8GB barrier (1024 cylinders corresponds to about 8GB).  Note the OS and particular file system on the partition being booted is not the factor here.

Aside: whatever operating system is on the partition being booted could be designed to use LBA if the bios supported Int13 Ext, but you can't even get the OS started if the MBR can't reach it.  Read between the lines here, and you'll notice this means the pre-Win95b MBR did not limit disk sizes to 8GB, it only limited the starting point of the partition being booted to the first 8GB.  IOW, if a pre-95b MBR could use CHS to pass the boot process off to the first sector of the partition, then as the OS loads it could switch to LBA to be able to access disk space beyond 8GB.  (Incidentally, this is the source of the Partition Magic warning that a partition beginning beyond Cyl 1023 might not be bootable.)  Since the Win95b MBR could itself switch to LBA, it eliminated the requirement that a boot partition had to begin below the 8GB boundary.



The NTFS file system was introduced with NT.

Although this statement doesn't assert there's a cause/effect relationship here, as worded I'm afraid readers might infer there is.  The new MBR wasn't due to NTFS.  Microsoft was just streamlining and compacting the code a bit, and introducing the DiskID area.  (I've seen early references to the DiskID as the "NT Serial Number".)  The DiskID is necessitated by the NT/2000/XP operating system, not by the NTFS file system.



None.

NightOwl quoted:

FTR, any partition table can always be recontructed manually, as long as the partitions themselves are still intact.  And if the partitions are not intact, a backup of the partition table won't fix that.

Backing up the partition table is a good idea nonetheless, but it wouldn't be right to think you'd be left dead without it.

Brian, based upon Reply #52, the functional conclusion is that the restoration of the MBR – when recovering the PC with a Ghost 9 or Ghost 10 image/recovery point – is not a concern, with the application handling the required actions.  In other words, in the world of Ghost 9/Ghost 10, it’s all a non-issue.

Nonetheless, I wonder:  With the Restore MBR setting “Ticked or unticked, you still get a MBR” – but, is it the same MBR?  For example, in the unticked case, Ghost 9/Ghost 10 might be installing the ‘generic’ or ‘standard’ MBR; whereas in the ticked case, the application may be designed to restore the original MBR contained in the .V2I file which (depending upon the PC’s unique configuration) might not be the same as the ‘generic’ or ‘standard’ MBR.  Could this be how it works?

One way to test this hypothesis is to repeat your procedure, but first manually add a unique byte sequence ‘signature’ into an unused segment of the MBR before creating the Ghost .V2I image/recovery point.  After setting the MBR to zero, the restore can be performed (A) with the Restore MBR ticked and (B) without that option ticked.  In the former case, your new and unique signature should be present; in the latter case, it should be absent.

Dan, a good recommendation concerning the marking of the MBR for test purposes.

Brian, the world awaits with bated breath the results of your continued investigation . . . .

Brian wrote on Aug 21^st, 2006 at 3:23am:


Dan Goodell wrote on Aug 19^th, 2006 at 3:55pm:


Dan, were you able to restore the image to Unallocated Space with the MBR zeroed?

With the original HD installed I used de.exe to edit the ascii text of the MBR. I edited "Missing" to "Mixxing".

A Ghost 10 image was taken (recovery point)
de.exe was used to confirm that the MBR was still marked
The HD's were swapped
MBRWork was used to zero the MBR and EMBR
de.exe confirmed all zeros
Ghost 10 restore with Restore MBR ticked
The OS booted normally and de.exe confirmed that the marked MBR present
MBRWork was used to zero the MBR and EMBR
de.exe confirmed all zeros
Ghost 10 restore with Restore MBR not ticked
The OS booted normally and de.exe confirmed that the marked MBR was present

So if you don't tick Restore MBR then you get a generic MBR. If I understand Dan correctly, this doesn't matter.