Radified Community Forums - GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266)

pishposh

Dude

Offline

I Love Radified!

Posts: 24
Cambria, California

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #15 - Feb 13^th, 2010 at 3:07am

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. Wink

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

	Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion Reply #16 - Feb 13^th, 2010 at 5:51pm To all I made an editing change to my previous reply #2 --just to give you a heads up as to that change.
	____________________________________________________________________________________________ No question is stupid ... but, possibly the answers are ! IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #17 - Feb 14^th, 2010 at 2:01pm

@

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.....

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #18 - Feb 14^th, 2010 at 3:09pm

@

pishposh

Quote:

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

Good luck with that...... Wink

!

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.....

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

pishposh

Dude

Offline

I Love Radified!

Posts: 24
Cambria, California

Back to top

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #19 - Feb 15^th, 2010 at 1:19am

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!

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. Wink

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.

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

	Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion Reply #20 - Feb 17^th, 2010 at 11:23am @ 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.
	____________________________________________________________________________________________ No question is stupid ... but, possibly the answers are ! IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #21 - Feb 18^th, 2010 at 7:08pm

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).

IP Logged

pishposh

Dude

Offline

I Love Radified!

Posts: 24
Cambria, California

Back to top

Re: GSS 2.5 LiveUpdate 5 (Ghost 11.5.1.2266) - Windows 7 Confusion
Reply #22 - Feb 21^st, 2010 at 8:42pm

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

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).

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. Wink

)

IP Logged

	Welcome, Guest. Please Login