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:

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:

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

Brian

Quote:

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  , 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)!

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.

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

Brian

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

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:

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

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.

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.