This Topic covers how to recover a SATA2 drive with a "lost" windows partition when you stupidly try to use any of the GHOST 2003 tools on a live late model PC.

I installed my old Ghost 2003 program so I could verify an old GHO file I needed for an old machine that had got fried.

A local install of Ghost 2003 creates a Ghost virtual disk from inside windows on your local machines hard drive to load the GHO file into.  It does this for most of the advances features.

This component works fine "inside windows" however if your local drive is SATA 2 once the machine reboots you are locked out and cannot get ghreboot to work.  No matter what you do your host machine is "stuffed"  >:( :'(

If you use any of the partition tools available you will see your partition is empty or a Dos partition "sharing" partition space.

The problem is that because you can no longer LiveUpdate Ghost 2003 you cannot get the version with SATA drivers required to correctly access your SATA2 drive.  Also the new versions of Ghost do not read GHO files.

The Solution:
FIRSTLY - DO NOT FIDDLE WITH ANYTHING
I grabbed an empty PATA (IDE) drive of the same size (in my case I was lucky to have an identical sized 160GB IDE drive) and installed it in my SATA machine.

The PATA drive needs to be the same size or bigger.

Now I booted from a Linux based SystemRescueCD
available from http://www.sysresccd.org/

Using the Terminal screen that comes up when the CD boots type
fdisk -l
to find out which drive was which (in my case SDA was the SATA and SDB PATA)

Then type
ddrescue /dev/sda /dev/sdb --force
This forces ddrescue to overwrite the target disk (SDB in my case).
Once completed (I had no errors and it took about 60mins) I removed the SATA cables and rebooted the PC on the PATA (IDE) drive.
The Ghost2003 virtual environment loaded fine so I quickly selected the option "Return to Windows" - you need to be quick.  As expected it worked and on a reboot - BINGO I had my Windows environment back (but now on an IDE not my SATA). Remember the SATA is still unplugged.

At this stage all that is required is copy your IDE drive back to the SATA.
  Plug the SATA drive back in.
  Do NOT allow PC to boot on either hard drive

I used the same procedure as above:
Booted Linux SystemRescueCD
fdisk -l       Just to check the drives are still the same

ddrescue /dev/sdb /dev/sda --force
NOTE the drives are the other way round this time

When complete shutdown and remove CD and PATA (IDE) drive.

Reboot and you have your system back as it was before GHOST 2003 destroyed it.  ;)

The lesson - DO NOT run GHOST 2003 from the application inside windows using a SATA drive.

I hope this helps because I have spent all day researching this solution.

@ andrewdh

Thanks for sharing--a very unique solution!

However, this is probably not unique to our more modern SATA based systems.  Back in the day (2002, 2003) folks with PATA HDDs had this issue happen as well.  Usually the *ghreboot* program would solve most people's problems, but not all!  I have a system with the standard two PATA controllers plus an imbedded PATA RAID controller chip.  I run my OS on the RAID controller (initially Win98se and then WinXP) and have spare HDDs and optical drives on the other standard PATA controllers.  I got trapped in the Ghost 2003 virtual partition and *ghreboot* did not successfully correct my problem.

This is pure speculation, but it fits the problem that occurs:  with my RAID system and your SATA system--both have the *standard* PATA controllers as well.  For older OS systems, it was required that the OS be on the HDD on the Primary channel of the first IDE controller that the system BIOS sees and reports.  When Windows Ghost 2003 sets up the virtual partition--it's done from within Windows--so it sees the SATA or RAID HDDs just fine because there are drivers in Windows for that purpose.  But, when Ghost 2003 reboots the system, the first controller seen is the standard PATA IDE, either on your SATA system or my old RAID system--this is probably to be backward compatible with the former requirement of the OS being found on that first controller on the primary channel.  So when you tell Ghost, from within the virtual partition to re-boot to the OS, or use the  *ghreboot* program, the software is programed to look for the first controller, the PATA IDE controller (and not your SATA or my RAID controller--which are further down the BIOS list of controllers).  Ghost 2003 or *ghreboot* do not find the master boot record that has the Ghost virtual partition entry on it at that PATA IDE controller, and fails to successfully change the master boot record for re-booting to the OS.

The reason I think this may be the cause of the problem is that when I have used my old RAID system with the other extra HDDs on the standard PATA controllers--and in DOS, those HDDs with FAT partitons on them on the standard PATA controllers are assigned drive letters before any FAT partitions that may be on the HDDs attached to the RAID controller--which means the BIOS sees the standard IDE controllers ahead of the RAID controller.


Quote:

If you use any of the partition tools available you will see your partition is empty or a Dos partition "sharing" partition space.

I would be interested in better understanding this statement.  What partition tools did you use?

If you use a DOS based partitioning tool (booted from a floppy disk or a DOS bootable CD), you should be able to access the master boot record to see what the partition status is for each of the listings for the partition table.  In the past, I've used DOS based PartitonMagic, what used to be a free program called MBRWizard (now a paid program--but, possibly worth the cost), old *fdisk* from MS DOS, and the Ghost 2003 command line partitioning program works as well--*gdisk*.

I see that all my old links to Symantec regarding using *ghreboot* and *gdisk* are now dead--Symantec is no longer supporting even the FAQ for Ghost 2003--that's just nasty--they want our dollars to support them, but they are more than willing to abandon their customer base who supported them in the past.  Well, what goes around comes around--see if my dollars will be spent on any of their new products!  There are other competitors with as good, and maybe better options than anything Symantec now produces (did I mention the TeraByte imaging products TeraByte's group of Image for Windows, DOS, and Linux ?).

Here's a link to our forum where I discussed using the *gdisk* program when the *ghreboot* program did not work (you'll see some of the broken links there):  Ghost 2003 -operating system not found

The basic problem is that the Windows Ghost 2003 interface, before shutting down Windows and re-booting to the DOS Ghost virtural partition, creates a new entry in the master boot record (a new primary partition), makes that partition *Active*,  makes your current OS partition *Not Actvie*, and *Hides* your current OS partition.  When it's time to re-boot to your OS, Ghost is supposed to undo those changes--i.e. hide the Ghost virtual partition, and un-hide your OS partition and make it active.

So, to boot back to your original OS, you should be able to boot to DOS, load a master boot record utility that shows the SATA HDD master boot record information, and using that tool, Hide the Ghost partition, make the Ghost partition non-Active if hiding did not already do that, and un-Hide the OS partititon, and make the OS partition Active.  Remove the DOS boot media, and you should be able to re-boot to your OS.


Quote:

I installed my old Ghost 2003 program so I could verify an old GHO file I needed for an old machine that had got fried.

What were you trying to verify?  Maybe there's an alternate method that we could help you with.

@ NightOwl

I just installed Ghost 2003 to "make" an image of WinXP. The computer restarted into Ghost 2003 and I aborted. A BIBM CD was used to examine the partition table of HD0 (a SATA HD).

-VBGHBOOT- was in the fourth partition slot. I deleted the virtual partition, wrote standard boot code and made WinXP Active. WinXP booted normally.

Maybe this is a different situation to what andrewdh experienced.

@ Brian


Quote:

Maybe this is a different situation to what andrewdh experienced.

Actually, I think this is exactly the situation. 

Your aborting just after booting to Ghost leaves the system in the state that the Ghost program has established for its processing of the Ghost procedure set up in the Windows Ghost interface.

I'm glad you joined in and reported how easy the TeraByte partition and imaging program BIBM (Boot-It, Bare Metal) works if it's needed to clear up the mess if the normal Ghost process does not work properly.

I presume when you re-booted the system to the BIBM interface, you saw the *VBGHBOOT* as active, and your WinXP OS partition was *hidden*.  Deleting the virtual partition is the ultimate *hiding* of a partition  8-) , and did BIBM automatically makes the WinXP OS active when you unhide it (?), or did you have to do that as an extra command?

I had not used some of my old links in a long time, and I was appalled when I saw that Symantec has taken down access to their web-based FAQ regarding Ghost 2003 and older programs!  I can understand no longer offering active support for an older program, but not allowing access to the FAQ on their servers--that puts a sword in my heart (two thumbs down as well as two big toes down to Symantec)!

@ andrewdh


andrewdh wrote on Jul 14^th, 2013 at 10:49am:

The problem is that because you can no longer LiveUpdate Ghost 2003 you cannot get the version with SATA drivers required to correctly access your SATA2 drive.

I can probably help you with updating the installed Ghost 2003 program. 

But, based on the above discussion, I have doubts about whether it will actually solve this particular problem.

Send me a PM (Private Message) if you're interested in updating the installed Ghost 2003 program.  You could then test to see if the update solves the problem, or not, and report back here!

And, if it does not help--then you could possibly have on hand the 30 day trial version of BIBM from TeraByte to quickly undo the master partition table changes so you can recover your system back to your OS.  (Or, you could try some of the other partitioning tools to see which one(s) will work on your system, figure out how to use them to modify the master partition table, and be ready to use them if needed after the trial of the updated Ghost 2003.)

@ NightOwl

I repeated the test several times. The -VBGHBOOT- partition was Active and a Type Eh partition (FAT-16). WinXP wasn't Active and was a Type 7h partition (NTFS). On no occasion was WinXP a Type 17h partition (Hidden NTFS).

The virtual partition was 16065 sectors in size. One cylinder. 8 MB. It started inside the WinXP partition, 4125316 sectors after the WinXP Start LBA.

After deleting the virtual partition the boot error was, "No boot device available".
After then setting WinXP Active the boot error was, "Missing operating system".
After then writing boot code, WinXP booted normally.

@ Brian


Brian wrote on Jul 15^th, 2013 at 2:46am:

I deleted the virtual partition, wrote standard boot code and made WinXP Active. WinXP booted normally.

Wow!  I glossed over that statement!

I have no recollection of ever having to rewrite the master boot record when using the Ghost virtual partition.  And, I've helped several folks on the forum here over the years to recover from being trapped in the virtual partition--and I can't recall ever needing to apply a new master boot record.  It has always been the hiding and unhiding of the necessary partition, and making the proper partition active.

The devil is always in the details--what was the original master boot record source--i.e. how did the original master boot code on the HDD get written by what software before you used the Ghost Windows interface to set up the Ghost virtual partition?  Was it the installation CD for WinXP or some other source?


Brian wrote on Jul 15^th, 2013 at 12:33pm:

The virtual partition was 16065 sectors in size. One cylinder. 8 MB. It started inside the WinXP partition, 4125316 sectors after the WinXP Start LBA.

I'm guessing you are using the BIBM program to see that bit of detail.  I don't recall ever seeing that information using the software I have used--or at least not that I was smart enough to use to look for that.  Where do you see that, and how do I bring it up to record the info?

I'm busy for the next couple days and can not play with computers, but I will fire up my old system and see what I find when I use Ghost's virtual partition. (Bet I have to delete one primary partition to make room in the partition table for Ghost's partition!  I've been using the boot directly to DOS method and not the Windows Ghost interface for a long time!)

@ NightOwl

I looked at the MBR with DE (disk editor) and noticed Ghost 2003 had changed the boot code. It was different code to what I saw 5 minutes ago before running the Ghost backup. That's what it has to do to make the computer boot into the Virtual partition. So unless the Ghost code is removed, Windows won't boot.

I guess one of the tools you used removes the Ghost boot code. It will be easy to test using DE.

To see the partition table in BIBM, click View MBR.

Several of the TeraByte tools work in a similar fashion. Change the boot code for the boot and then restore the original boot code.

http://www.terabyteunlimited.com/howto/howto-ifd-bootfile.htm

I used PTS DE. It runs in DOS.

http://thestarman.pcministry.com/tool/de/PTS-DE.htm

@ Brian


Brian wrote on Jul 16^th, 2013 at 1:55am:

I looked at the MBR with DE (disk editor) and noticed Ghost 2003 had changed the boot code. It was different code to what I saw 5 minutes ago before running the Ghost backup. That's what it has to do to make the computer boot into the Virtual partition. So unless the Ghost code is removed, Windows won't boot.

Well, I never knowingly changed the boot code!  For all the MBR tools I used, the only thing I remember ever doing is hiding and unhiding partitions, and changing the active or not active settings of the partition table.  I never had a boot problem after I manipulated those variables, so I never looked at the rest of the boot code.


Brian wrote on Jul 15^th, 2013 at 12:33pm:

WinXP wasn't Active and was a Type 7h partition (NTFS). On no occasion was WinXP a Type 17h partition (Hidden NTFS)

Well, thinking back and looking at the above forum link I gave in reply #1, I only used commands in gdisk to hide the Ghost virtual partition.  I never used a code to unhide the OS partition.  So Ghost probably only switched the Active partition setting.  (The hiding and unhiding of OS partitions was probably me remembering what I was doing to automate Ghost backups from within Windows using MBR tools (not the Ghost virtual partition option), and booting to a DOS primary partition on the same HDD for performing a Ghost procedure.  Looks like hiding the non-active partition may not be necessary--but I think I was doing that because PartitionMagic always gave a warning that you should not have two bootable primary partitions visible--but, maybe only that Active setting is necessary!?)

So, the boot code *I saw 5 minutes ago before running the Ghost backup*--where did that original boot code come from?  What format and partition tool was used to create that code--the WinXP installation CD or .....other.....?

Are you using the BIBM boot code, and/or Multi-boot manager code?  Ghost would not understand TeraByte's proprietary MBR--maybe that could be a source of why your non-boot occurs unless you replace the boot code before you can get the system to boot to WinXP.

Not asking you to rush out and do this *now*, but, if the opportunity arises in the future, can you do a MBR backup to a file of the before and after master boot code.  I think that type of file can be opened in Notepad and read as a text file, which can then be copied and pasted here.  I would like to see where and what code is different.

Right now, when I look at my MBR--I will have no idea where it came from!  It has been whacked so many times by various tools--but, quite some time ago--5-6 years ago (?).  But, I will look at it before I attempt the Ghost virtual partition procedure, and try to make a text capture of the code--and then the after once I have booted to the virtual partition--to look for differences.

I always thought the only change Ghost did was to make an entry in the master partition table for a new primary partition, and making it Active.  That code somehow does  a *redirect* (jump code?) telling the initial boot sequence where to go to continue the bootup process--the startup sequence knows which jump code to use based on which partition was set as *Active*.  Each bootable primary partition has its own jump code to tell the boot sequence where to go to boot that particular OS that has been set for Active

@ NightOwl

The boot code prior to using Ghost was TeraByte code.

---

I'll have to take a photo of the new code generated by Ghost. Later today.

The above MBR doesn't have "Missing operating system" so the Ghost MBR generated that message.

Captured in a WinPE...(the last two lines are the active Virtual partition)

---

After capturing the above MBR I restarted the computer and on the Ghost screen chose Return to Windows and it did. The original TeraByte MBR was present so Ghost must back it up and then restore it.

If I don't abort out of Ghost it creates an image backup and boots back into Windows. So Ghost is happy with the TeraByte boot code.

If I abort out of Ghost and then delete the Virtual partition and make WinXP Active, it doesn't matter whether I write Standard boot code or TeraByte boot code, WinXP boots.

This is a WinXP Standard MBR...

http://i16.photobucket.com/albums/b16/bjkdegree/MBR-Standard.gif

This is a Win7 MBR...

http://i16.photobucket.com/albums/b16/bjkdegree/MBR-Win7.gif

WinXP boots fine with a Win7 MBR. Win7 usually boots fine with a WinXP MBR, but not always.

This is a Dell WinXP MBR...

http://i16.photobucket.com/albums/b16/bjkdegree/dell-mbr.gif

@ Brian


Quote:

If I don't abort out of Ghost it creates an image backup and boots back into Windows. So Ghost is happy with the TeraByte boot code.

Well, only because it apparently replaces the boot code before booting into DOS, does its procedure, and then before booting back to Windows, replaces the boot code that was previously originally there.

This appears to be an unknown (prior to now), undocumented behavior of Ghost 2003, and its use of the virtual partition.

Although I do not know the original source of my current MBR, I sure it's a standard MS MBR.  When I test, I can label my starting MBR and see if it gets replace in any fashion when I boot to the virtual partition.

I'm suspecting that if the MBR code is *std MS MBR* code, it just adjusts the partition table.  If it is something other than *std MS MBR* code, then it probably is copying the non-standard code, replacing it temporarily with the *std MS MBR* code that it needs to successfully boot to DOS (without danger of damaging your non-standard code), and then restoring it after the Ghost procedure is done, and ready to re-boot to Windows.


Quote:

If I abort out of Ghost and then delete the Virtual partition and make WinXP Active, it doesn't matter whether I write Standard boot code or TeraByte boot code, WinXP boots.

I wonder why the temporary MBR will not allow for booting back to the OS, but simply writing new MBR code does--whether it's standard MS MBR code or TeraByte MBR code.  The temporary code must lack some important information that the other MBR code supplies.  The temporary code must supply only the necessary jump code for finding the virtual partition--and nothing more.

@ NightOwl


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

I'm suspecting that if the MBR code is *std MS MBR* code, it just adjusts the partition table.If it is something other than *std MS MBR* code, then it probably is copying the non-standard code, replacing it temporarily with the *std MS MBR* code that it needs to successfully boot to DOS (without danger of damaging your non-standard code), and then restoring it after the Ghost procedure is done, and ready to re-boot to Windows.

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.

I just had to do it. Starting with WinXP having a Standard MBR. Pre and post Ghost MBRs. They are different.

---

After aborting Ghost...

---

Of interest, the post Ghost MBRs are the same. It doesn't matter if you start with TeraByte or Standard boot code, Ghost writes its own boot code.

@ Brian


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

I just had to do it.

;D  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:

Init failed:  Error 100. Partition table is bad

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:

Processor exception Access_Violation

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 wrote on Jul 17^th, 2013 at 2:23am:

Although I do not know the original source of my current MBR, I sure it's a standard MS MBR.

Anytime you install Windows it *always* writes new boot code, whether you need it or not.  That's always been a hoop multibooters have had to jump through when setting up multiboot systems because if you're not careful installing the second OS will overwrite your multiboot manager's MBR--and hence, why my SOP is to install the multiboot manager last, after all the various OS installs have had their way with the MBR.

Also, note there are different versions of a "standard Microsoft MBR".  Attached is a text format "cheat-sheet" to compare and quickly identify which version you have.  Brian's Reply #17 shows the XP MBR, while Reply #18 is a Win98 MBR.

ISTR that Ghost 2003 always used the Win98 MBR as a "standard" MBR, though it's been 10 years since I explored that so memory is fuzzy.  Bear in mind that in v2003's day the Win98 MBR was still a popular, fail-safe choice.

---

@ NightOwl


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

do you know if BIBM can examine the partition table and fix problems?

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?

@ Dan Goodell


Dan Goodell wrote on Jul 18^th, 2013 at 3:01pm:

Also, note there are different versions of a "standard Microsoft MBR".Attached is a text format "cheat-sheet" to compare and quickly identify which version you have.

Thank for the quick reference.  Question--is the Win98  the same for both *Win98* and *Win98se*?


Dan Goodell wrote on Jul 18^th, 2013 at 3:01pm:

Anytime you install Windows it *always* writes new boot code, whether you need it or not.  That's always been a hoop multibooters have had to jump through when setting up multiboot systems because if you're not careful installing the second OS will overwrite your multiboot manager's MBR

I've seen this discussed many times.  If you install an older version of Windows after a newer version of Windows, multi-booting gets messed up.  So, it makes sense that somehow the MBR is being over-written with new code.

But, how is this different?--Long time ago, I used a Win95 fdisk version to partition a new HDD.  (I forget exactly why I used that older version of fdisk--I think I was following some set of instructions that recommended using fdisk--and I didn't know better than to make the assumption that all version of fdisk were the same--bad assumption!)  My intention was to set up multi-booting by using manual switching of which primary partition was active and un-hidden--so I had one active, un-hidden OS partition (empty), two primary partitions that were hidden and not active, and a final primary partition to create an extended partition for additional logical partitions.

I was installing WinXP at the time into that empty active primary partition.  Everything seemed to go well, but when I tested booting to the other OSs in the Hidden Partitions, I could not!  I always got a OS not found or something to that effect.  I fiddled with it for awhile, but never found an answer.

Some time later, I used *Kawecki's Trick* to erase the HDD id--which apparently forced a new WinXP MBR to be written.  Now, I discovered that those hidden parimaries could be unhidden, made active, and they booted fine.  Apparently, those primaries were beyond a 8 GB boundary that the older fdisk MBR could understand (probably did not use LBA locations), and the newer MBR could.

For whatever reason, the installation of WinXP did not over-write my existing older MBR with a new MBR.

You have made the generalization in the past, that any MBR can be used to boot an OS.  I'm guessing that may be true if you only have one primary OS partition and it is located below the 2 and 8 GB boundaries that impose limitations because of older MBRs on older OSs (DOS and Win95 (? not Win98se)).  If you have bootable partitions beyond those old boundaries, then it appears that you need the newer MBRs to function properly.

@ Brian


Quote:

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?

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


Quote:

*Warning* File system ends at LBA xxxxxxxxxx This Partition is not accessible by Win95a, DOS, WinNT, or OS/2.

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.

---

@ Brian

I could not get the forum to allow two attached screenshot in a single post, so here's the second one:

---

@ NightOwl


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

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!

Quote:

*Warning* File system ends at LBA xxxxxxxxxx

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:

Open the Properties window again, this time while holding down the left Shift key.  (Pressing the left Shift key while opening the Properties window allows you to edit the ending LBA.) Change the End LBA to match the number shown in the warning message. Click OK to save the change. Open the Properties window once again (without pressing the Shift key) and verify that the warning message no longer appears.

Does this fix the Partition Magic etc issues?

@ Brian


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.

Is that what that warning is about?!  I thought it had to do with the old 2 and 8 GB size limitation for DOS.  The warning doesn't actually say there's a *File System/End partition mismatch*--I guess I have to be smart enough to look at that *File system ends at LBA xxxxxxxxxx * and compare that to the actual partition end positions   ::) --I'm not good at *seeing* those relationships unless someone points them out to me!


Quote:

The partition can't be imaged or restored.

Well, I've been imaging monthly or so for a long time with Ghost 2003 in DOS--but, Ghost 15 and its cousins are operating from within Windows.  I can not remember trying to restore an image--have not had the need to do so.


Quote:

We assume it's due to the partition having been created badly.

Well, the partitioning was done by Ghost 2003.  I know I restored a good image that was without all the errors that had developed during the system's melt down of its capasitors causing random power fluctuations.  At some point, I had changed from a 120 GB HDD to a 160 GB HDD, and I used Ghost 2003 to resize the partitions as part of the upgrade--but, I can't remember if I did that before the system started having problems--or after I had it repaired--and then had to restore the good image.  I did multiple restores until I found an image that did not have the errors that were saved as part of the image--so there was a lot of messin' around for awhile.


Quote:

There is a fix.

I'll check that out, now that I know its meaning, and let you know if it has any effect on those other errors.

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

But, how is this different?--Long time ago, I used a Win95 fdisk version to partition a new HDD. [...] Apparently, those primaries were beyond a 8 GB boundary that the older fdisk MBR could understand (probably did not use LBA locations), and the newer MBR could.

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:

For whatever reason, the installation of WinXP did not over-write my existing older MBR with a new MBR.

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



Quote:

You have made the generalization in the past, that any MBR can be used to boot an OS.

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:

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!

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.

@ Dan Goodell


Quote:

Gee, I might have known that 10 years ago, NightOwl, but that's a long time ago!

I understand!   :)  I'm having problems remembering a lot of that stuff myself!  It's only certain high points that linger.......



Dan Goodell wrote on Jul 22^nd, 2013 at 4:45am:

Quote: Quote: For whatever reason, the installation of WinXP did not over-write my existing older MBR with a new MBR. Hmm... I've never seen that happen IME.

Just out of curiosity, are you usually setting things up with multibooting vs single OS?


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.

Okay, that clarifies that.


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.

Yes, the first step was to try ghreboot, and if that failed, then using a MBR utility to unhide the OS partition, make it active, and hide the virtual partition.

Knowing now that Ghost was backing up the original MBR, replacing it with its own MBR for the Ghost procedure, and then replacing that Ghost MBR back to the original--I was not smart enough to look at the MBR to see which one was actually present. 

So, I did not know if the ghreboot had been successful in restoring the original MBR, and somehow something else was preventing a successful reboot.  But, that seems unlikely--once the original MBR was in place, it should have acted just as it had before as far as successful booting.

Also, if I recall, one was stuck in an endless loop where the DOS prompt says if you want to return to your OS, press *x*, and the system would reboot to the same DOS prompt, which to me would suggest that the Ghost MBR was still the active MBR because one remained in the Ghost virtual partition.

And, it's that MBR (the Ghost MBR) that I must have changed the active partition from the Ghost virtual partition to the OS partition, hide the Ghost partition, and rebooted--successfully!  I forgot to look with my above experiment to see if the OS partition in the Ghost MBR was hidden or not.  I will take a look at that when I perform a couple more trials that I have in mind, and will report back. 


Quote:

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.

Yes, intentional.  And thank you for that analysis of the partition table.



Here's the first part of the Ghost MBR--the DOS Norton Utilities Disk Editor does not show a full sector at a time (do any of the old DOS disk editors show a full sector at a time--anyone know?--I suspect not--I think DOS has a max number of lines it can display!):

---

There are some known issues with Ghost Solution Suite and SATA drives.  Here are some things to try: http://www.symantec.com/business/support/index?page=content&id=TECH109571

NightOwl wrote on Jul 22^nd, 2013 at 9:27am:

Just out of curiosity, are you usually setting things up with multibooting vs single OS?

Always.  I don't think I've had a single-OS computer since c. 1986, when I started dualbooting two installations of DOS 3.3 on a 20MB hard disk.  Ever since then, the advantages of multibooting have been obvious to me and well worth the effort.



Quote:

do any of the old DOS disk editors show a full sector at a time--anyone know?--I suspect not--I think DOS has a max number of lines it can display!

DOS was fixed at 80 chars wide by 25 rows.  To show an entire sector requires a minimum of 16 two-char columns by 32 rows.  There were some video modes on EGA monitors that could do more, but it's probably been at least a couple decades since anyone has had an EGA monitor.


Your screenshot shows a plain-jane Win98se MBR.  I booted up my Win98se virtual machine to compare it, byte-for-byte.  I think a 1st-edition 98 MBR was the same, but I don't have one of those handy to compare.

It's been a while since I posted but I still regularly check and keep up with this forum.

@Dan Goodell:
Is there a particular boot manager(s) that you recommend for multibooting and any specific advice for doing so? Thanks for your excellent technical discussion as always! I always enjoy reading your contributions and usually learn something new.

IMHO, of all the various boot managers around there are only two that ever need consideration: BING/BIBM or XOSL.

BIBM (BootIt-Bare-Metal) and it's predecessor, BING (BootIt-NG), have simply been the most versatile and stable boot manager for more than a decade, bar none.  But it costs money.  Yet, for $40 it's an incredible bargain and includes a partition manager, a partition imaging/cloning utility, and responsive customer support.

Still, some people don't want to spend money, no matter how good the bargain.  For those people, I always recommend XOSL.  My evaluation of XOSL hasn't changed--it's still the best free boot manager.  It was abandoned by its developer a decade ago, yet the function of a boot manager hasn't changed, either, so it still does the job even with modern OS's.  Still, abandoned means no tech support, and no hope of any updates to handle tomorrow's UEFI partitioning standard.

XOSL isn't perfect, though--it's always had a niggling bug: it doesn't like certain laptop keyboards for some reason.  It works on some laptops but not others.  If you have one of those laptops on which it doesn't work . . . well, there's no tech support, remember?

Personally, I use BING/BIBM on my own machines (and have multiple licenses to stay legit).  For multiboot configurations I setup for other people, I use XOSL unless they're willing to spring for a copy of BIBM.

As for how I create a multiboot system, it's all on my webpage.  It's a tried and true method that has worked for two decades, and continues to work even with Windows 8.  The tools have changed over the years, but the basic methodology hasn't.  I still create building blocks out of images of individually installed OS's, then setup my final partition layout, pour the images into whichever partitions I like, and strap on the boot manager as the last step.

@ Prozactive

I made these summary notes years ago after Dan posted instructions about installing XOSL.

Download XOSL 1.1.5 (450k) from...
http://www.ranish.com/part/

In Disk Management or with a partitioning app, create a 32 MB FAT primary partition. Label it XOSL  (in BING use 14/Eh)

Create a folder called TEMP in the partition. Unzip and copy all the files from the xosl folder into TEMP (ignore the manual folder)

Boot from a Win98 boot CD. I suggest "Win98SEnoram_bootdisk.iso" from...
http://www.allbootdisks.com/download/iso.html

At the A: prompt type C: and press Enter

type dir to confirm you are in the correct partition. You should see the TEMP directory listed

type CD TEMP and press Enter

type INSTALL and press Enter

You are now in the XOSL setup

Select Install XOSL and press Enter

Select Install on a DOS drive and press Enter

You should see "Install on drive      : C "   (make sure it is your 32 MB partition if you have other FAT partitions)

Arrow down to Ranish Partition Manager and use Page Down (or Page Up) key to select NO

Arrow down to Smart Boot Manager and use Page Down (or Page Up) key to select NO

Arrow down to Start Installation and press Enter

Press Enter on Reboot System and remove the CD

XOSL boots

Click Setup

Click Add

Select an OS. Give it a Boot item name. Click Apply.

Click Hiding. Select a partition you wish to Hide and put a tick in the Hide box. Do this again if there are more partitions to Hide. Click Apply.

Click Save. OK, Close.

Click Setup and do the same for another OS you would like to add to the Boot Menu.

If the OS is not on HD0, put a tick in Swap drives before clicking Save.

Now you are ready to choose an OS and click Boot.

*****************************

If desired you can later convert this partition to a bootable DOS partition without losing XOSL.

sys C: But that is not enough. You have to add DOS files. Edit autoexec.bat, msdos.sys, config.sys

***************

Can do an install into a 32 MB FAT logical volume just as easily. XOSL works. But can't sys C: and make this boot DOS. XOSL can't boot it. BING can't either.
If you want DOS it has to be a primary partition.

*****************************

For logical volume OS you don't need to allow for hidden sectors. (but get a bsod until you boot a primary partition ) Next time you try logical it is OK.

@ Dan Goodell


Dan Goodell wrote on Jul 22^nd, 2013 at 6:35pm:

Always.I don't think I've had a single-OS computer since c. 1986, when I started dualbooting two installations of DOS 3.3 on a 20MB hard disk.

Well, what I was thinking is that maybe that was a difference in what I do vs what you do as an explanation for why you see a MBR overwrite when you install a new MS OS.  But after thinking more, I doubt you have been setting up the MS way of multi-booting--which is what I was doing also by using a MBR tool to switch active partitions--and avoiding the MS method of multibooting.

It's been so long ago--and there's no way for me to examine what the actual MBR was pre and post the changes that eventually sorted things out and they began to work.

There's also the possibility that what I thought happened was coincidental and something else happened that I didn't even know happened!

Computers--gota love 'em!

@ Brian


Brian wrote on Jul 21^st, 2013 at 4:10pm:

Does this fix the Partition Magic etc issues?

Been busy the last few days and haven't fired up the old system to check the partitions with BIBM. 

And, I'm out of town for the next few days--so, my testing will have to wait until I'm back.

Just letting you know I haven't abandoned the effort....

@Dan Goodell and Brian:

Thank you for the excellent info. Sorry for the slow acknowledgment but I'm having some major hardware problems that make it difficult to compose and do other tasks. Hopefully I'll be able to resolve the problems soon.

@ Brian


Brian wrote on Jul 21^st, 2013 at 4:10pm:

Quote: Open the Properties window again, this time while holding down the left Shift key.(Pressing the left Shift key while opening the Properties window allows you to edit the ending LBA.) Change the End LBA to match the number shown in the warning message. Click OK to save the change. Open the Properties window once again (without pressing the Shift key) and verify that the warning message no longer appears.

So, using Boot It Bare Metal (BIBM), and the above recommendation--it would only allow me to edit the *ending LBA* on the primary partitions.  But, I have 4 FAT32 logical partitions inside an extended partition which show the error that the end of the partition does not match the end of the file system's LBA--and I can not edit those partitions.

But, tried PartitionMagic's Windows interface after editing the one primary partition that had that error message, and still no joy--the error still occurred:  Init failed:  Error 100  Partition Table is Bad.

The logical partitions in the extended partition has the partition information in the chained EMBR (Extended Master Boot Record) if I remember correctly--can BIBM access the EMBR for editing?

As an alternative, I was thinking I might use BIBM to do a minor edit of the partitions of shrinking and sliding the logical partitions, and letting BIBM modify the various EMBRs to see if that corrects those *Warnings*.

@ NightOwl

It looks like BIBM can only edit the end LBA of a primary partition. In the Actions menu on the right side of the Partition Work window, can you access Slide/Resize/Copy ? With primary partitions these buttons are greyed out until the LBA error has been corrected. If the buttons are available, try a small Slide/Resize as you are planning. It should work.