I'm having a little trouble understanding one item mentioned here:
http://www.symantec.com/connect/sites/default/files/Ghost251_readme.txt

Mainly, it says this version "enables the support for the Windows 7 and Windows Server 2008 R2 operating system. No additional functionality has been added or fixed in this release."

Fair enough.

But then there's this:

===============================================================
3. Known Issues
===============================================================

Windows 7 System Reserved Partition
---------------------------------------
Ghost by default does not save the System Reserved Partition which is created during Windows 7 operating System installation. An image of this partition has to be created separately. During the system restore, the System Reserved Partition has to be restored before restoring the OS partition. BEST PRACTICE: Take a disk image (default create image task settings) of a Windows 7 machine.

That's rather confusing.

Are they saying that a Local > Disk > (target) backup won't include the "System Reserved" partition, and that I'll have to manually do a Local > Partition > (target) backup of it separately after doing a Local > Disk > (target) image?

See, the reason I'm confused is, it's obvious that a Local > Partition > (target) backup of the Windows 7 OS partition wouldn't also simultaneously include the "System Reserved" partition, because with this type of backup operation, you only select one partition for imaging per backup operation in the first place.  (I.e. anyone doing a Local > Partition > (target) backup would realize from looking at the partition list that there were two Windows 7-related partitions on their drive requiring imaging, and that they'd therefore needed to two Local > Partition > (target) backup operations in total.)

So it seems pointless that they're even mentioning this at all.  But the fact that they are mentioning it makes me wonder if what they really mean to say is that Local > Disk > (target) backups will exclude the "System Reserved" partition.

Of course, if that were the case, then their advice about separately backing up the "System Reserved" partition so it can be restored first would make no sense ... if what you'd be restoring afterwards were a Disk image that would overwrite what you restored first.

Could anyone who's already figured this one out for sure for themselves relate what's actually going on here?  :)

@ pishposh

It does say..


Quote:

BEST PRACTICE: Take a disk image (default create image task settings) of a Windows 7 machine.

... so a disk image includes the SRP.

I use Ghost 15 and it doesn't do disk images. We have to do partition images. The SRP is no big deal. I prefer to get rid of it as I don't use Bitlocker and I don't want to backup and restore two partitions.

@ pishposh


Quote:

"enables the support for the Windows 7 and Windows Server 2008 R2 operating system. No additional functionality has been added or fixed in this release."

Interesting--how exactly is Win7 support added if they go on to say: 


Quote:

Ghost by default does not save the System Reserved Partition which is created during Windows 7 operating System installation.

If Ghost supports Win7--how can you then state that the new partitioning scheme of Win7 is not included in how Ghost functions--how is this statement even logical?


Quote:

See, the reason I'm confused is, it's obvious that a Local > Partition > (target) backup of the Windows 7 OS partition wouldn't also simultaneously include the "System Reserved" partition, because with this type of backup operation, you only select one partition for imaging per backup operation in the first place.  (I.e. anyone doing a Local > Partition > (target) backup would realize from looking at the partition list that there were two Windows 7-related partitions on their drive requiring imaging, and that they'd therefore needed to two Local > Partition > (target) backup operations in total.)

Unless Ghost 11.xxx functions differently than Ghost 2003 (not an unlikely scenario!), you can actually select more than one partition to include in a single image file when using *Local > Partition > To Image*.  After selecting the source drive, you are presented a list of partitions on that drive--you can then select one or more of the partitions to include!


Quote:

So it seems pointless that they're even mentioning this at all.  But the fact that they are mentioning it makes me wonder if what they really mean to say is that Local > Disk > (target) backups will exclude the "System Reserved" partition. Of course, if that were the case, then their advice about separately backing up the "System Reserved" partition so it can be restored first would make no sense ... if what you'd be restoring afterwards were a Disk image that would overwrite what you restored first.

Actually, even if you made a separate SRP partition image, you could never restore it to the HDD unless it already had that partition present--Ghost will not *add* a partition to an existing HDD with other partitions already present!

[edit]By NightOwl, 2/13/2010, @ approx. 3:40 pm:

I need to qualify the above statement slightly--Ghost will *not* add a partition to a HDD if it already partitioned and the whole disk is allocated to those partition(s).  But, if there is *unallocated* space on the HDD, and all the primary partition slots in the partition table are not already used up (or the unallocated space is inside an extended partition where a primary partition slot is not needed), then Ghost will restore a partition from an image file, and *add* it to the HDD with other existing partitions to that unallocated space!

Depending on whether you need to have that *added* partition in a particular physical spot on the HDD--and in the *correct* sequence in the partition table, you might have to control where that unallocated space is located (like using PartitionMagic to move partitions around), and you might have to correct the partition table to match the physical layout of the partitions--that can be done with the MBRWizard program.

This thread and posting talks about being able to restore a image of a partition to a HDD that already has partitions:  Restoring OS only image to new HDD, reply #41.[/edit]

Unfortunately, as the statement stands, it's unclear what Ghost procedure is being referenced when they say *Ghost by default does not save the System Reserved Partition*.  But, given everything else, I think they must be referring to a *Local > Partition > To Image* procedure of just the OS partition--that would then fail to *include* the necessary SRP!

A quick test imaging procedure seems in order!

Do a *Local > Disk > To Image* of the HDD where your OS is installed (has to be an installation where Win7 did the initial partitioning so it has that System Reserved Partition (SRP) on it.  Open that image after it's created using DOS Ghost, or in Ghost Explorer if booted back to Windows, and see if the (SRP) is or is not present!

Unfortunately, Symantec's technical writers tend to leave out the details, and assume the reader *knows* what they are referencing without actually stating the *facts*!

NightOwl wrote on Feb 5^th, 2010 at 10:04am:

@ pishposh Quote: "enables the support for the Windows 7 and Windows Server 2008 R2 operating system. No additional functionality has been added or fixed in this release." Interesting--how exactly is Win7 support added if they go on to say:  [quote]Ghost by default does not save the System Reserved Partition which is created during Windows 7 operating System installation.

If Ghost supports Win7--how can you then state that the new partitioning scheme of Win7 is not included in how Ghost functions--how is this statement even logical?[/quote]

Quite.  I think they should have done this instead.  If ghost.exe/ghost32.exe/ghost64.exe is used to do a Local > Partition > to (target) image of a partition which the software detects is a Win7 OS partition, then IF the software also sees -- but the user hasn't simultaneously selected-for-backup -- a Win7 System Reserved partition on the same physical disk, a warning pop-up should be displayed.  Nothing that forbids the operation, just an advisory saying:

Warning 34567: It appears you're about to image a Windows 7 OS partition. A "System Reserved" partition belonging to the selected Windows 7 OS partition has also been detected on this disk.  Be advised that your Windows 7 OS partition image will not be bootable without also imaging its "System Reserved" partition.  See product manual for details.  [Proceed Anyway]  [Go Back]

If that were done, there'd be no need for a readme.txt entry.  (Heh, do the current developers of classic Ghost read this forum?  I hereby place my example pop-up warning text into the copyright-free public domain, if so!)


Quote:

[quote]See, the reason I'm confused is, it's obvious that a Local > Partition > (target) backup of the Windows 7 OS partition wouldn't also simultaneously include the "System Reserved" partition, because with this type of backup operation, you only select one partition for imaging per backup operation in the first place.  (I.e. anyone doing a Local > Partition > (target) backup would realize from looking at the partition list that there were two Windows 7-related partitions on their drive requiring imaging, and that they'd therefore needed to two Local > Partition > (target) backup operations in total.)

Unless Ghost 11.xxx functions differently than Ghost 2003 (not an unlikely scenario!), you can actually select more than one partition to include in a single image file when using *Local > Partition > To Image*.  After selecting the source drive, you are presented a list of partitions on that drive--you can then select one or more of the partitions to include![/quote]

Mia culpa.  You're absolutely correct.  It's been so long since I've done partition-based imaging that I plain forgot.  :)


Quote:

Actually, even if you made a separate SRP partition image, you could never restore it to the HDD unless it already had that partition present--Ghost will not *add* a partition to an existing HDD with other partitions already present!

That part I understand.  Ghost images partition contents and restores them to existing partitions.  Partition images don't, however, save any data about how a source partition is configured (i.e. if I back up a Win7 "System Reserved" partition, it won't back up its "properties" in its MBR boot track partition table entry which make it a Win7 "System Reserved" partition).

So, AFAIK, if I had an image of a Win7 OS partition, and an accompanying image of its "System Reserved" partition, the only way to operatively restore them to a new (unpartitioned) HDD would be to install Win7 on that HDD, let it create Win7 OS and Win7 "System Reserved" partitions, and then once the installation process finished, go back to Ghost and overwrite those partitions' respective contents with my respective backups.  (That, or use third-party tools like gparted -- if and when support is added to them for creating a partition Win7 would recognize as a "System Reserved" type partition.)


Quote:

Unfortunately, as the statement stands, it's unclear what Ghost procedure is being referenced when they say *Ghost by default does not save the System Reserved Partition*.

Again, same for me.  Seems the readme was very hastily written.


Quote:

But, given everything else, I think they must be referring to a *Local > Partition > To Image* procedure of just the OS partition--that would then fail to *include* the necessary SRP! A quick test imaging procedure seems in order!

And that's just what I'd do if I had Windows 7 to test with.  Unfortunately, as things stand, I probably won't have it for months.  But I do have Ghost 11.5.1 already, and figured it'd be good to familiarize myself with its stated Win7 compatibility.

But that's when I ran into its cryptic readme.txt, and wound up on Radified hoping someone else with Win7 had already encountered and solved this puzzle.


Quote:

Do a *Local > Disk > To Image* of the HDD where your OS is installed (has to be an installation where Win7 did the initial partitioning so it has that System Reserved Partition (SRP) on it.  Open that image after it's created using DOS Ghost, or in Ghost Explorer if booted back to Windows, and see if the (SRP) is or is not present!

See above.

Anyway with your and Brian's comments I feel more confident on how this really works.  Only mystery left: why they say "System Reserved" partition must be restored "before" OS volume.  That shouldn't be necessary as long as both are restored before trying to boot the drive.  Yet they say it, making me wonder if Ghost silently modifies a "System Reserved" partition upon restoring an OS partition, necessitating that restore order.

@ pishposh


pishposh wrote on Feb 6^th, 2010 at 12:22pm:

So, AFAIK, if I had an image of a Win7 OS partition, and an accompanying image of its "System Reserved" partition, the only way to operatively restore them to a new (unpartitioned) HDD would be to install Win7 on that HDD, let it create Win7 OS and Win7 "System Reserved" partitions, and then once the installation process finished, go back to Ghost and overwrite those partitions' respective contents with my respective backups.

You are making restoring sound difficult when it is not. Just regard the SRP and Win7 as two partitions to be restored. The SRP is at the start of the HD so it should be restored first so it can be at the start of the new HD. Partition order does matter. You don't need to partition the new HD, (I'm not sure if Ghost 11.5 requires partitions but I'd be surprised if it does) just restore the drive or the partition images.

Even if you forget to restore the SRP to the new HD you can still get Win7 to boot by doing two repairs from the Win7 DVD.

Brian wrote on Feb 6^th, 2010 at 5:16pm:

(I'm not sure if Ghost 11.5 requires partitions but I'd be surprised if it does)

I rang a mate who uses Ghost 11.5. He assured me there is no problem restoring multiple Ghost images to unallocated space.

I tried it with Ghost 2003. Two partitions were created on HD0 and imaged to a third partition on HD0. All partitions on HD1 were deleted. The two images were restored (correct size) to the unallocated space on HD1. Easy.

I've restored Ghost 2003 images of Win7 in the past. It works.

Brian wrote on Feb 6^th, 2010 at 5:16pm:

@ pishposh pishposh wrote on Feb 6th, 2010 at 12:22pm: So, AFAIK, if I had an image of a Win7 OS partition, and an accompanying image of its "System Reserved" partition, the only way to operatively restore them to a new (unpartitioned) HDD would be to install Win7 on that HDD, let it create Win7 OS and Win7 "System Reserved" partitions, and then once the installation process finished, go back to Ghost and overwrite those partitions' respective contents with my respective backups. You are making restoring sound difficult when it is not. Just regard the SRP and Win7 as two partitions to be restored. The SRP is at the start of the HD so it should be restored first so it can be at the start of the new HD. Partition order does matter. You don't need to partition the new HD, (I'm not sure if Ghost 11.5 requires partitions but I'd be surprised if it does) just restore the drive or the partition images.

This is clearly where our understanding of Ghost differs.  I was under the impression that a .gho image containing only partitions (i.e not made with a full-disk imaging operation) can not be restored to an unpartitioned drive.  I.e., that you need existing partition(s) on the target drive, so you can tell Ghost which to use as target(s) for the partition(s) in your .gho image.

(This understanding is perhaps why I was "making restoring sound difficult when it's not," I assume.  ;))

Actually, this brings up a whole different can of worms for me.  If you have time, hop on over to this thread.

In any case, I thank you and NightOwl for your help on the windows 7 stuff.

pishposh wrote on Feb 9^th, 2010 at 7:58pm:

I was under the impression that a .gho image containing only partitions (i.e not made with a full-disk imaging operation) can not be restored to an unpartitioned drive.

I thought that too and that's why I did the test. But I'm delighted that it can be done.

Nice guides, but it's out of my league. I only dabble in DOS Ghost occasionally.

@ pishposh

I remembered we discussed this a few years ago but I'd forgotten the conclusions.

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1155827177/0

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1155827177/60#66

You can restore a Ghost 2003 image to unallocated space if a MBR is present. If there is no MBR the option to restore is greyed out.

So if one has a brand new HD and Ghost 2003 won't restore an image, create a Standard MBR.

@ Brian and @ pishposh


Quote:

This is clearly where our understanding of Ghost differs.

I can't remember the details--it's been awhile--but, my recollection was that restoring a partition from an image required that a destination partition existed already.

I think I could do a *Local > Disk > From Image* and then choose a partition to restore to a whole disk.  But *Local > Partition > From Image* to the best of my memory required an existing partition to restore to.

Brian--you said you used Ghost 2003, so you must be booted to DOS--what procedure did you select?  Was the image file a single *Local > Partition > To Image*--or was it multiple partitions saved to the image file and selecting only one partition to restore--or multiple partitions?

It will take me a day or two to find the time to set it up, but I will try restoring a partition image to unallocated space to see what happens.

@ NightOwl

You probably didn't see my reply above before you posted as the times are close. We did some interesting tests in that thread.

I was using Ghost from a DOS CD. I deleted all partitions on the target HD before attempting the restore. I used Partition to Image (single partition only). Obviously my target HD had a MBR without a partition table.

Brian wrote on Feb 10^th, 2010 at 12:06am:

@ pishposh I remembered we discussed this a few years ago but I'd forgotten the conclusions. http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1155827177/0 http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1155827177/60#66 You can restore a Ghost 2003 image to unallocated space if a MBR is present. If there is no MBR the option to restore is greyed out. So if one has a brand new HD and Ghost 2003 won't restore an image, create a Standard MBR.

A-ha!

The MBR (absolute/physical sector 0) contains executable code and the NT/Linux disk signature, but also holds the partition table (bytes 447-510).  So if absolute sector 0 is nulled, then there's no partition table either.  I.e., there's a differerence between "a partition table with all 4 entries set blank, indicating an unpartitioned disk" and "no partition table at all".  According to Dan Goodell, it appears the latter is specifically what causes Ghost to refuse to let you restore a partition-type image.

In that case I'll have to revise my draft to say something like "partition images can be restored to an MBR drive as long as sector 0 of the MBR boot track holds a valid partition table.  This is true even if that partition table indicates that the drive is unpartitioned, and even if sector 0 of the MBR boot track is itself otherwise nulled (e.g. contains no executable loader code)."

Got it.  Thanks!

@ pishposh


pishposh wrote on Feb 11^th, 2010 at 5:23pm:

"partition images can be restored to an MBR drive as long as sector 0 of the MBR boot track holds a valid partition table.This is true even if that partition table indicates that the drive is unpartitioned,

That is better worded than my post. The MBR does however contain boot code.

But another complication. I just tried to restore a Win7 image (Ghost 2003) to a HD that already contained a partition. A data partition. There was no option to restore to unallocated space. I had to create a partition to proceed with the restore.

So it looks like you can only restore to unallocated space if there are no partitions on the HD.

*scribbles notes*

Gotcha.  So, I'll have to make my revision something like this: (edit: see next post in this thread) "a partition image can be restored to an existing partition on an MBR drive, or to an unpartitioned MBR drive as long as sector 0 has a valid partition table structure (a partition table whose entries are all unpopulated).  A partition image cannot, however, be restored to unpartitioned space on an MBR drive that already has one or more existing partitions; for that, a new partition utilizing that unpartitioned space must first be created manually."

etc.

Thanks again.  :)

You know what?

I take that all back.  I'm wrong.

Right after posting the above message above, I realized what I said couldn't be true.  Checking http://en.wikipedia.org/wiki/Master_Boot_Record confirmed my suspicions.

If a partition table entry is entirely empty, every byte within will be null.  There will be nothing left to even indicate that a partition table exists.  I.e., there's no partition table "structure"; just the partition table data itself, and if each partition table entry is empty, no partition table appears to exist at all because its entire region within sector 0 then contains nothing but 00h bytes.

When I realized I was forgetting this vital fact, I figured something else had to be responsible for telling Ghost whether or not to let a user restore a partition image to an unpartitioned drive.

So I did this test.

First, I did a Local > Partition > To Image backup of an empty MBR-formatted flash drive I had on hand.

Then, using a disk editor (HxD), I bumped that drive's MBR sector out of place one notch, like so:

http://img62.imageshack.us/img62/331/1hex.png

As you can see, this left sector 0 entirely nulled, effectively rendering the drive "virgin", as far as logic-level recognition routines would be concerned.

After doing that, I started Ghost and attempted a Local > Partition > From Image restoration.  Here was the result:

http://img130.imageshack.us/img130/3975/68702403.png

As this shows, I wasn't allowed.  Drive greyed out.  Which sync'ed with existing findings re: totally-nulled sector 0's.

So, back into HxD I went.  Considering Dan Goodell's findings (that partition images can be restored to a drive whose MBR sector 0 contains no executable bootloader code), I could only think of one possibility.  And did this:

http://img191.imageshack.us/img191/7318/2hex.png

Notice the last two bytes of sector 0.  Leaving the whole sector blank, I simply restored the MBR 55AA signature.

Lo and behold, Ghost's reaction, while again trying to do a Local > Partition > From Image restoration, was this:

http://img513.imageshack.us/img513/7425/14034255.png

And it furthermore went on to present me with this, once I selected the drive itself:

http://img17.imageshack.us/img17/6981/96405320.png

So, in conclusion, it seems my revision needs to go like so:

"a partition image:
  * MAY be restored to any existing partition on an already-partitioned drive;
  * may NOT be restored to any unpartitioned space that may exist on an already-partitioned drive;  (edit: *sigh*, see next post in thread, once again)
  * MAY be restored to an entirely unpartitioned drive, provided the first sector of its MBR boot track contains at least the standard MBR signature bytes 55h AAh at offsets 510-511 (sector bytes #511-#512)."

More testing.

Beginning from this screen - http://img17.imageshack.us/img17/6981/96405320.png - in the test elaborated upon above, I changed the target partition's size to 4000, just to leave extra room on the drive, and proceded with the restore.

Then I tried Local > Partition > From Image again all over again (first using the same image file all over again, then aborting that and trying with a completely different single-partition image file from a different USB stick):

http://img641.imageshack.us/img641/8813/81521487.png
http://img202.imageshack.us/img202/8946/64891459.png

I guess, then, at least for Ghost 11.5.1, I once again need to revise my revision:

"a partition image:
  * MAY be restored to any existing partition on an already-partitioned drive;
  * may NOT be restored to any unpartitioned space that may exist on an already-partitioned drive;
  * MAY be restored to an entirely unpartitioned drive, provided the first sector of its MBR boot track contains at least the standard MBR signature bytes 55h AAh at offsets 510-511 (sector bytes #511-#512)."

Boy, let's hope I'm finally done with this.  ;)

To all

I made an editing change to my previous reply #2
--just to give you a heads up as to that change.

@ Brian


Quote:

You probably didn't see my reply above before you posted as the times are close. We did some interesting tests in that thread.

Yes--I did not see your reply at the time--I was composing my reply and we *crossed posted*--after seeing your reply and the link to that prior thread--I went to that thread and begin reading it--I had forgotten most of that, but as I read it all started *flooding* back--and I see that I have already done this test:


Quote:

It will take me a day or two to find the time to set it up, but I will try restoring a partition image to unallocated space to see what happens.

reply #41

After re-reading that thread, I now realize I/we never actually did the final definitive testing of Ghost 2003 to determine what actually happens when restoring an OS partition only image to a new HDD--i.e. what MBR is actually created or restored!  All the necessary tools and steps are outlined--but the testing and results never occurred!!!

You did the necessary tests for Ghost 10 and reported the results:  reply #59.

I will have to go back and do the similar tests to bring all that to a final conclusion.....

But, pishposh's testing and reported results has brought up some new and interesting issues as well.....

@ pishposh


Quote:

Boy, let's hope I'm finally done with this.

Good luck with that......  ;) !

As Dan Goodell has previously noted--*it's all about controlling the variables*!

And one of the variables is no less than *What version of Ghost are you using?!*  As Ghost has evolved, so too have the included functions...so it's critical to clearly identify each of the variables that may have an influence on the results....

Having said that, it looks like you are using Ghost32 v11.5.1 based on your screen shots.

The details reported in that old thread--Restoring OS only image to new HDD were based on Ghost 2003 and Ghost 10--Ghost 11.5.1 may or may not still respond that same....and DOS Ghost 11.5.1 may or may not respond the same as Ghost32 v11.5.1 that runs under a Windows OS!!!

So, I was *heartened* to see that your result using Ghost32 v11.5.1 when the Absolute Sector 0 of a HDD was *zeroed out*, showed the same response that Ghost 2003 did way back when: 


Quote:

As you can see, this left sector 0 entirely nulled, effectively rendering the drive "virgin", as far as logic-level recognition routines would be concerned. After doing that, I started Ghost and attempted a Local > Partition > From Image restoration.  Here was the result: http://img130.imageshack.us/img130/3975/68702403.png As this shows, I wasn't allowed.  Drive greyed out.  Which sync'ed with existing findings re: totally-nulled sector 0's.

The potential issue of which version of Ghost is being used became apparent when I re-read this posting in that old thread by ckcc:  reply #58:


Quote:

I just realized that even though I had created my image with Ghost 2003 booted from DOS CD... I have been restoring it using Ghost 8 from Bart PE CD from a USB HD. So I repeated my tests restoring from a slave IDE drive and using 2003 from boot CD. Local / Partition / From Image  restoring to unallocated space: Ghost 2003: greyed out, only allows restore to existing partition Ghost 8: will restore, but will not boot Local / Drive / From Image  restoring to unallocated space: Ghost 2003: restores and boots Ghost 8: restores and boots

First off, ckcc had not clearly noted that he was mixing different versions of Ghost until now--reply #58!

And, secondly, based on other results (including yours!), the highlighted result above should not have been possible if the MBR sector 0 was zeroed out!  That result *should* have been that the HDD as a destination should have been *greyed out* too!  I suspect ckcc's posted result may be in error--unless Ghost32 v8.xx functions differently than my Ghost 2003 and your Ghost32 v11.5.1--but, seems unlikely--no?!

Even Dan Goodell's reported results were less than clearly stated in that old thread:

reply #30


Quote:

I just ran a test in which I zeroed out the MBR and then restored a Ghost 2003 partition image.  The partition table (at the bottom of LBA-0) was adjusted, but the boot code portion remained zeroes.

Every other reported result so far indicates that if the LBA-0 (absolute sector 0) is zeroed, then a partition image restore is *greyed out* and not possible!  Dan finally clarifies the setup here:  reply #65


Quote:

For the experiment, I used an existing disk and zeroed out the boot code with de.exe and left the partition table.

So, in fact, the first sector was not *zeroed out*--he had left the partition table there and just removed all the other code in absolute sector 0!

Now, you are reporting a whole new Ghost response to attempting to restore a partition only image:  reply #14 of this thread:


Quote:

Notice the last two bytes of sector 0.  Leaving the whole sector blank, I simply restored the MBR 55AA signature. Lo and behold, Ghost's reaction, while again trying to do a Local > Partition > From Image restoration, was this: http://img513.imageshack.us/img513/7425/14034255.png

So, now, in addition to leaving just the partition table in absolute sector 0, having just the MBR 55AA signature will also allow Ghost to restore a partition only image to a otherwise unpartitioned HDD!

Now, I wonder if you can place any random bit of data in absolute sector 0, and get the same results?????  How about the NT disk ID????

Or, if all the other MBR code is present in absolute sector 0, and if you now substitute *zeroes* for where the partition table data should be--does that cause the HDD to be *greyed out* as a destination--or, is it okay to select for a partition only restore--I have no idea what the limiting factor is for doing a partition only restore to a *new HDD*!!!!

Just for the record--most of the above issues are *esoteric* for the average user who will mostly be restoring his OS image partition to an existing HDD that already has his OS partition on it--and is simply *over-writing* the image back up to that existing partition.  But, it's not completely *esoteric*--if a user makes only OS partition backups, the OS HDD dies and you purchase a new HDD--now some of the issues above can cause a problem in restoring your *OS partition only* backup image to that new HDD.....

Easily resolved if you know what's coming...but, someone who isn't aware of the issues...this becomes a *big* problem.....

Re: ckcc's test (and the result you highlighted in yellow), maybe he didn't truly zero the whole sector (i.e. maybe he left in the MBR signature in its last two bytes, 0x55AA, intact).  If he did zero out even the 0x55AA signature, on the other hand, then maybe Ghost 8 truly was different than Ghost 2003.  (He says he was comparing Ghost 8 and Ghost 2003, and IIRC, Ghost 2003 was effectively Ghost 8.1.)


Quote:

Even Dan Goodell's reported results were less than clearly stated in that old thread: reply #30 [quote]I just ran a test in which I zeroed out the MBR and then restored a Ghost 2003 partition image.  The partition table (at the bottom of LBA-0) was adjusted, but the boot code portion remained zeroes.

Every other reported result so far indicates that if the LBA-0 (absolute sector 0) is zeroed, then a partition image restore is *greyed out* and not possible!  Dan finally clarifies the setup here:  reply #65


Quote:

For the experiment, I used an existing disk and zeroed out the boot code with de.exe and left the partition table.

So, in fact, the first sector was not *zeroed out*--he had left the partition table there and just removed all the other code in absolute sector 0!

Now, you are reporting a whole new Ghost response to attempting to restore a partition only image:  reply #14 of this thread:


Quote:

Notice the last two bytes of sector 0.  Leaving the whole sector blank, I simply restored the MBR 55AA signature. Lo and behold, Ghost's reaction, while again trying to do a Local > Partition > From Image restoration, was this: http://img513.imageshack.us/img513/7425/14034255.png

So, now, in addition to leaving just the partition table in absolute sector 0, having just the MBR 55AA signature will also allow Ghost to restore a partition only image to a otherwise unpartitioned HDD![/quote]

Hmm.  Actually, I think what probably happened is that Dan zeroed out offsets 0-445 (the loader code + NT disk signature area), left offsets 446-509 intact (the partition table), but then forgot to zero offsets 510-511 (the 0x55AA MBR signature).  Which if so technically means it would still have been 0x55AA itself, not the partition table, that made his Ghost allow the restore.  Reason I say this is, it *must* be true.  :)  Without the 55AA signature, Ghost cannot know that ANY data in the partition table's offset range IS a partition table.  I.e., 55AA at that location is what makes a drive an IBM PC MBR drive, and without that signature there, Ghost can't simply assume offsets 446-509 are a partition table.

*moments pass*

Okay, tested: http://img508.imageshack.us/img508/6419/partitiononly.png

With valid partition table data present but nothing else, restoring a partition image is prohibited.  So, again, in all liklihood, Dan just forgot to remove 55AA and concluded the partition table was why it let him restore the partition-based image.


Quote:

Now, I wonder if you can place any random bit of data in absolute sector 0, and get the same results?????  How about the NT disk ID????

http://img402.imageshack.us/img402/8453/badsignature.png
http://img514.imageshack.us/img514/7690/diskidonly.png

So no and no.


Quote:

Or, if all the other MBR code is present in absolute sector 0, and if you now substitute *zeroes* for where the partition table data should be--does that cause the HDD to be *greyed out* as a destination--or, is it okay to select for a partition only restore--I have no idea what the limiting factor is for doing a partition only restore to a *new HDD*!!!!

Offsets 0-445 + 510-511 intact, 446-509 (partition table) nulled:
http://img715.imageshack.us/img715/5817/goodsector0nopartition.png
So THIS does work.  But note: it works because a fully zeroed partition table (like seen here) is exactly what will also exist if you were to go into FDISK and delete all partitions.  Remember (as I remembered myself earlier - heh): MBR partition tables have no "structures", just partition table entry data.  So if you delete all partitions with a tool like FDISK, the partition table bytes in sector 0 will all become zeroed exactly like in the screen capture above.  So .... yeah .... it's 55AA that's the official (and only) "on/off" switch for partition-image restores.


Re: "I have no idea what the limiting factor is for doing a partition only restore to a *new HDD*!!!!" -- a new HDD would be all zeros in every sector of the whole drive, including sector 0.  So no, a partition image could not be restored to a new drive.  However, you *could* make a new drive *able* to accept a partition-only image.  Just put 55AAh in the last two bytes of sector 0.  That makes it an MBR drive.  Of course, you'll also want executable loader code if you plan to boot that drive, as well as a disk signature if you want to use it with NT/Linux.  ;)  So, rather than manually adding 55AA yourself, just FDISK it -- create a primary partition, then delete the primary partition.  That'll have the effect of establishing loader code + MBR signature, and leave you with a zero'ed partition table.  Then you can ghost your partition image to it.

@ pishposh


Quote:

*moments pass* Okay, tested ...

Excellent....nice tests and reporting of the results!  I've learned some new info about the function and structure of the Master Boot Record and boot tract from this discussion.

pishposh wrote on Feb 15^th, 2010 at 1:19am:

I think what probably happened is that Dan zeroed out offsets 0-445 (the loader code + NT disk signature area), left offsets 446-509 intact (the partition table), but then forgot to zero offsets 510-511 (the 0x55AA MBR signature).Which if so technically means it would still have been 0x55AA itself, not the partition table, that made his Ghost allow the restore. Reason I say this is, it *must* be true. Without the 55AA signature, Ghost cannot know that ANY data in the partition table's offset range IS a partition table.I.e., 55AA at that location is what makes a drive an IBM PC MBR drive, and without that signature there, Ghost can't simply assume offsets 446-509 are a partition table.

That's correct--the part about a partition table requiring 55AA, not the part about me "forgetting".  Without the 55AA you don't have a valid partition table, so I deliberately kept that.  What I zeroed out was the *boot code* to see if Ghost would restore it (which would imply Ghost recognized that the disk could not be booted without it).

Dan Goodell wrote on Feb 18^th, 2010 at 7:08pm:

pishposh wrote on Feb 15th, 2010 at 1:19am: I think what probably happened is that Dan zeroed out offsets 0-445 (the loader code + NT disk signature area), left offsets 446-509 intact (the partition table), but then forgot to zero offsets 510-511 (the 0x55AA MBR signature).Which if so technically means it would still have been 0x55AA itself, not the partition table, that made his Ghost allow the restore. Reason I say this is, it *must* be true. Without the 55AA signature, Ghost cannot know that ANY data in the partition table's offset range IS a partition table.I.e., 55AA at that location is what makes a drive an IBM PC MBR drive, and without that signature there, Ghost can't simply assume offsets 446-509 are a partition table. That's correct--the part about a partition table requiring 55AA, not the part about me "forgetting".  Without the 55AA you don't have a valid partition table, so I deliberately kept that.  What I zeroed out was the *boot code* to see if Ghost would restore it (which would imply Ghost recognized that the disk could not be booted without it).

Thanks for the clarification this was in deed what happened.  Guess the mystery is solved officially.

(And sorry for my choice of words - "forgetting;" didn't mean to make you sound absent-minded. ;))