NightOwl

NightOwl wrote on Jul 17^th, 2013 at 2:23am:


Maybe. I ran Ghost 2003 from WinXP with a Standard MBR and then aborted out of Ghost. The MBR did resemble Standard boot code I saw before running Ghost. At least the first two lines were as that's all I recorded. It certainly wasn't the strange code I posted above.

BUT, I still had to write a Standard MBR before WinXP would boot.

I'm leaving further testing to you. I'm interested to hear what you find.

After aborting Ghost...

Brian

Brian wrote on Jul 17^th, 2013 at 4:51pm:

  How well I know that symptom......

So, I fired up my old system to begin doing some testing--this is my old 2002 system that melted down with bad capacitors several years ago--I had the capacitors replaced--and recovered the system from Ghost 2003 backup files--had to go back multiple months prior to the melt down to find a functional image that did not have backed up errors from several months of gradually deteriorating BSOD, random errors, etc.--but I'm still looking over my shoulder that I may still have undetected errors lingering--this is all a background to the problem I discovered this morning:

I had lost the ability to use PartitionMagic's (v8.x) Windows interface when I was trying to recover this system.  Discovered that by deleting a test partition that I had created, the errors disappeared and all seemed to run fine.  But, this morning I attempted to run PartitionMagic and got the error:

Quote:

So, tried to run the Ghost 2003 gdisk program--the Windows based version *gdisk32* and got a whole series of errors, but the two main ones were:

Quote:


So, tried to run the PartInfo program from PartitionMagic--the 32 bit version in Windows--the main screen comes up--but, all entries were blank and could not select either disk 1, 2, or 3--because that menu box was empty also.  But the *Preview* button worked--sort of--my disks were enumerated and the various data was present for my three disk drives, but I saw one anomaly that was out of place--all the partitions showed their respect *labels*, except my main OS partition's label was missing--the label does show up in my file management programs, and in disk management--so I don't know for sure what that means.

I have not done a lot of partition testing and changes in a long time, and as I mentioned above PartitionMagic was working fine the last time I played around with it.  I should also mention that DOS PartitionMagic would not work when that test partition was present, but worked fine again after I deleted it.

So, Brian, I did a little searching to see if BIBM can be used to *fix* an invalid partition table--but so far can not find a good answer--do you know if BIBM can examine the partition table and fix problems?

I searched for how to *fix partition table* errors, and there are some free and paid programs out there--but, so far I'm not ready to try those.

I will be firing up the system to DOS to see if any programs I have will work or what errors I get there--probably will boot BIBM as well--but, I have to delay testing the Ghost virtual partition errors until I get a handle on the current errors.

NightOwl

NightOwl wrote on Jul 18^th, 2013 at 12:12pm:


Boot from your BIBM CD and open Partition Work. Do you see *Errors Exist* or an E next to any partition?

Right click a partition and click Properties? Any mention of errors? Check each partition.

Click View MBR. Any errors?

Brian

Quote:

Nope--no errors.  The only thing I saw was:

Quote:

This warning was present for all my FAT and FAT32 partitions.  But, I don't know what this warning means.  I have always been able to boot to DOS, and access all of these partitions.  DOS recognizes them all, and assigns an appropriate DOS drive letter to each!  It's only the NTFS that does not get a DOS drive letter--and that partition had *NO WARNING* about not being able to access it--go figure!

So, I did a test of the Windows Ghost 2003 interface to set up a Ghost procedure.  I first *customized* my MBR so I could follow any changes--see the attached image at the end.  I used the RoadKil sector editor to replace some of the existing text in the MBR with my customization--I made the assumption that replacing text should not have any effect on the functional code in the MBR as long as I did not change the length of the text string.

I used the *Advanced* Ghost procedure where I chose to run Ghost *Interactively*--this was so I could boot to Ghost's virtual partition into DOS and have the Ghost program loaded, but it stops there waiting for manual input at that point.  And, this allows you to exit Ghost and you are returned to a DOS prompt--but, you are not taken back to the Windows OS automatically.  You have to type *ghreboot* and enter at the DOS prompt to return to Windows.  This allowed me to play around in DOS looking at the MBR with various DOS tools.

Using Dan's above *cheat sheet*, my beginning MBR was a WinXP MBR, and once booted to the Ghost virtual partition it changed to the Win98 MBR--just as you have reported!  A DOS screenshot using Norton Utilities Disk Edit program shows the later half of the MBR where my customization was now gone--see second attachment below.

This is all *new knowledge* for me!  Now I don't know how exactly I recovered from being trapped in the Ghost virtual partition in the past--and how I help others recover as well!  I intend on doing a couple new test runs to see what happens. 

I'm still curious as to why you were prevented from booting back to WinXP without first writing a new MBR.

NightOwl

NightOwl wrote on Jul 21^st, 2013 at 11:46am:


Quote:


We see this situation quite frequently in the Norton Forum as Ghost 15 and earlier won't see a partition that has a File System/End partition mismatch. The partition can't be imaged or restored. We assume it's due to the partition having been created badly. There is a fix.

Quote:


Does this fix the Partition Magic etc issues?

NightOwl wrote on Jul 21^st, 2013 at 11:19am:

Gee, I might have known that 10 years ago, NightOwl, but that's a long time ago!  I no longer remember exactly which MBRs did what (and never used Win95 fdisk anyway), but your hypothesis is plausible.  Somewhere along the way the MBRs evolved from reading CHS only (e.g., the 8GB limit), to presuming CHS and switching to LBA if supported, to presuming LBA and switching to CHS if LBA *not* supported.  ISTR the 98 and 98se MBRs were identical, but no longer remember for sure.


Quote:

Hmm... I've never seen that happen IME.


Quote:

Well, that's a bit out of context.  What I really meant was the MBRs are not specifically tied to the OS.  E.g., you don't need a XP MBR just because you're running XP.  Any MBR that can reach the partition will suffice, but your partition layout may impose limitations on which MBRs those can be.  It's the partition layout that dictates which MBRs can be used, not the OS on those partitions.


Quote:

ISTR it involved running ghreboot first or something like that, didn't it?  IOW, it's not enough just to change the active partition, you also have to get rid of the ghost virtual partition.


Your partition table looks okay--it's got a 23GB gap in the middle but I assume that's intentional and reserved for a future partition.  Here's your post-Ghost partition table with the Ghost virtual partition in the second slot:

.partition table:
 ID  B   BEGIN CHS     END CHS  REL SECS   SECTORS
 -- -- ----------- ----------- --------- ---------
 07 00    0-001-01 1023-254-63        63  48130677 ( 23501 MB)
 0E 80 1023-000-01 1023-254-63  36596070     16065 (     7 MB)
 1C 00 1023-000-01 1023-254-63  95249385  20482875 ( 10001 MB)
 0F 00 1023-000-01 1023-254-63 115732260 196844445 ( 96115 MB)


        63 +  48130677 =  48130740 => CHS  2996/0/1
              47118645 gap                         ( 23007 MB)
                          95249385 => CHS  5929/0/1
  95249385 +  20482875 = 115732260 => CHS  7204/0/1
 115732260 + 196844445 = 312576705 => CHS 19457/0/1

The three real partitions are CHS-aligned and all the numbers are internally consistent.

Remember, though, that the partition table merely outlines the partition boundaries.  Within each partition, the partition boot sector specifies the boundaries of the file system, and I assume what Brian is referring to is a conflict between those boundaries and the partition table's boundaries.