Hi @all,

I've tried to clone an ide-hdd to another ide-hdd with an installed ghost2003 (os: XP). After rebooting the system to perfom ghost operations it says: "Missing operating system".
The system contains MS-DOS and XP, so the configuration of the partitions is a little bit strange. However, booting from ghost's virtual partition is failing. I made a clone of the nonbootable disk by starting Ghost2003 from CD (that gave me a platform for some experiments ...  ;) ). Unfortunately everything I tried (ghreboot, 3rd-party bootmanager, etc.) to restore mbr/partition table fails or results in not working XP.

However, I can get back the configuration by restoring the original mbr. I know a copy of the mbr (mbr.bin) exists in the virtual partition (virtpart.dat). My problem: How can I access the virtual partition? I can't "see" it, when booting with pc-dos (ghost-cd) and I didn't find a tool to "open" virtpart.dat. Anyone an idea?

xylo


Quote:

I've tried to clone an ide-hdd to another ide-hdd with an installed ghost2003 (os: XP). After rebooting the system to perfom ghost operations it says: "Missing operating system".

Well, that sounds like your system, for whatever reason, is not compatible with the *virtual partition* that Ghost creates--we would have to explore more to try and understand what's *different* about your system vs systems that work okay with the virtual partition--probably some HDD controller/software incompatibility.

Quote #1:


Quote:

However, I can get back the configuration by restoring the original mbr. I know a copy of the mbr (mbr.bin) exists in the virtual partition (virtpart.dat).

So, I'm not sure if I understand--in the above sentence it sounds like you have accessed the *virtpart.dat* file, and extracted *mbr.bin*, restored it, and now you have your original functioning WinXP OS back on which you have Ghost installed, and used to create the virtual partition and Ghost procedure in the first place.  (If that's true--how exactly did you do that?!)

But, in the next sentence, you state:

Quote #2:


Quote:

My problem: How can I access the virtual partition? I can't "see" it, when booting with pc-dos (ghost-cd) and I didn't find a tool to "open" virtpart.dat. Anyone an idea?

So, in Quote #1 above, are you *speculating* that if you could access the *virtpart.dat*, then you could restore the original *master boot record (mbr)* using the *mbr.bin* file contined within?  (Do you know that *mbr.bin* is contained in the *virtpart.dat* file?)

So, given my confusion above, I'm not sure what problem you are having--but I think you are *trapped* in the *virtual partition* created on your original HDD where Windows Ghost is installed, and *ghreboot* has not worked to adjust the *master boot record* so you can successfully boot back to the original WinXP OS--is that correct?

Below are Symantec's FAQ's regarding recovering *manually* from being trappped in the *virtual partition* if *ghreboot* does not work using *gdisk* (other DOS Master Boot Record tools can also be used to edit the *active* vs *inactive* partition as well such as PartitionMagic or MBRWizard - The MBR utility you've been looking for!):

How to restart the computer into Windows if a problem is encountered after running Ghost 2003

Switches: GDisk

Switches: GDisk and GDisk32 for Norton Ghost 2003

Introduction to GDisk

You do not have to *restore* the Master Boot Record*--it just involves setting the correct partition as active again in order to boot successfully to your previous OS--you do not actually have to *delete* the *virtual partition*--just setting it *inactive* will get it out of the way--but deleting it is usually what you want to do.


Quote:

The system contains MS-DOS and XP, so the configuration of the partitions is a little bit strange.

Probably have to explore that issue to possibly understand why *ghreboot* is failing.

Let us know how the recovery goes--or if you have additional questions!

Recovery successfully done ...  :D

Thanks for your fast response. Sorry, if my description has been confusing. I hope this one is getting better.
After starting the ghost operations in windows, ghost reboots the pc. After postboot and before you get the menu where you can cancel ghost operations the system stopped with the missing os message.  

I booted from the Ghost CD. Using the PC-Dos-Prompt, I was able to access drive D: (primary part., MS-DOS7.1), drive E: (first partition in ext. partition, XP) and drive C: (new one, seemed to be ghosts virtual partition). The 'dir' command showed everything on D: and E:, but for C: it returned only trash. That was the reason why 'ghreboot' (started from cd) failed. It wasn't able to read the virtual partition.
At this point I used the command line to enter the support directory on the ghost cd. I started ghost and cloned the whole disk, to prevent data loss while trying to fix the error.

Like you suggested in earlier threads, I changed the active partition. Result: reboot after postboot ... trapped in a loop.
Then I tried windows recovery console ... fixmbr / fixboot / bootcfg
Result: different error messages and 'the reboot loop'
... I tried some other things, but I belive at this point the partition table has been damaged. That was the moment I thougt: "Best way should be to restore the original MBR/part. table."
I explored the virtual partition on another system. There I found the "mbr.bin" file. Size (512 byte) and date/time indicates, that this one could be a copy of the original mbr (of the second system). Comparing contents of this file with a copy of the MBR before I started ghost (on my test system) verified my guess. I tried to replace 'virtpart.dat' with the version of the failing system. But this didn't work because the sector position of the file is written into the partition table.

So I started this thread ...

... meanwhile I started thinking again about the whole thing. "Wy can't I access the virtual partition?"
A. virtpart.dat has been damaged
B. partition table has been damaged (not indicating the correct position of vitpart.dat)

"What is the same on every MBR on every PC?" ... the last 2 bytes of the 512 bytes, the "MAGIC NUMBER" ... 0x55 0xAA

I opened a copy of virtpart.dat in a hex-editor on the second pc and searched for that number. Several locations contains that number, but only two of them had a mbr strukture. The original MBR was the last location I found ( the last thing, ghosts writes to virtpart.dat before it reboots a computer). I copied the 512 byte to a file and wrote them directly to the first sector on the damaged hdd (using a cd bootable Linux and the dd command).
... reboot ... perfect ... everything is like before starting ghost the first time.

What went wrong?
After restoring the original MBR, I realized the GAG-Bootloader was installed in the MBR. When I started ghost the first time, I didn't know that. I think that was the reason why the partition table got damaged.

Well, this little story worked for me. I hope it helps others.

xylo

Thank you for your report back with your trouble shooting efforts--some interesting insights:


Quote:

"What is the same on every MBR on every PC?" ... the last 2 bytes of the 512 bytes, the "MAGIC NUMBER" ... 0x55 0xAA I opened a copy of virtpart.dat in a hex-editor on the second pc and searched for that number. Several locations contains that number, but only two of them had a mbr strukture. The original MBR was the last location I found ( the last thing, ghosts writes to virtpart.dat before it reboots a computer). I copied the 512 byte to a file and wrote them directly to the first sector on the damaged hdd (using a cd bootable Linux and the dd command).   ... reboot ... perfect ... everything is like before starting ghost the first time.

Does the 512 bytes include the whole absolute sector zero--which also includes the *Master Partition Table--or is that just the *Master Boot Record* without the *Master Partition Table*--I'm curious because you say you are copying that from one system and writing it to another system's HDD?

I'm also wondering why the */fixmbr* command did not re-write the MBR without effecting the Master Partition Table--which is what it is supposed to do--and therefore *fix* the problem as well?!  


Quote:

After restoring the original MBR, I realized the GAG-Bootloader was installed in the MBR.

I thought boot loader code was placed in the *Master Boot Tract* (Sectors 0 thru 62) in other than *Absoute sector zero*--which contains the *Master Boot Record* (MBR) plus the *Master Partition Table*.  Does the boot loader actually alter the MBR itself in absolute sector zero--in addition to placing other code in the boot tract?

If the MBR is non-standard code--that would possibly explain why Ghost got lost trying to find the *virtual partition*  the GAG-Bootloader may be pointing to its own code, and Ghost was looking for standard MBR code.

Booting from a bootable floppy or optical disc with DOS Ghost avoids using the *virtual partition*--so that's a work-around for the problem--best to start Ghost with a switch that forces Ghost to image the entire *boot tract* (sector 0 thru 62) if the system has bootloader code in that *boot tract*:

 ghost.exe -ib

If you don't do that, Ghost's default behavior is to image just absolute sector zero and not the rest of the boot tract.

Quote:

Does the 512 bytes include the whole absolute sector zero--which also includes the *Master Partition Table--or is that just the *Master Boot Record* without the *Master Partition Table*--I'm curious because you say you are copying that from one system and writing it to another system's HDD?

"Master Boot Record" (if you mean the "Boot Loader" programm) and "Master Partition Table" are included in the first 512 bytes of a hard disk. As far as I know, these first 512 bytes of a hdd are called "Master Boot Record". Check out the following table from a specification of the MBR:

adress (hex - dec)	content	size (bytes)
0x0000 - 0	Boot Loader	max. 440
0x01B8 - 440	Disk Signature (since W2K)	4
0x01BC - 444	Null (0x00 0x00)	2
0x01BE - 446	Partition Table	64
0x01FF - 511	MBR Signature or "Magic Number" (0x55AA)	2

Of course you need to be carefully with copying MBR-Data. It doesn't work if you use another hdd that doesn't match size and disk geometry of your source device. My second device is much larger than the original disk, so i wrote the extracted MBR back ...

Quote:

... to the first sector on the damaged hdd.

But the second device contains a backup of the partitions/data of the first, damaged one. A hint for everyone: it's important to do a backup of all accessible data, BEFORE you start experiments.


Quote:

I'm also wondering why the */fixmbr* command did not re-write the MBR without effecting the Master Partition Table--which is what it is supposed to do--and therefore *fix* the problem as well?!

... that's what I thougt, too. It should even work with my backup disk. Well, it didn't do, what it's supposed to do. Perhabs it don't work if MS-Dos is installed in the first primary partition and windows is installed in an extended partition.

Is it likely that if the cloning was done using a bootable cd or floppy with ghost2003, it would have worked without all the problems you encountered?

*  [smiley=thumbup.gif]

xylo,

There is a lot of information about the MBR in this thread.

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1155827177;start=0

Yes, it is like that. After restoring my "initial conditions", I retried cloning by using the bootable cd. Everything worked, like I knew it from ghost2003.
Next time I will try the bootable cd first.  :)