Unable to span a ghost image to CDs using a MS/PC DOS or WinPE boot partition
I'm working on creating an automated recovery set of cds (some of the machines we have do not have DVD-Rom drives), and am running into problems using either the MS/PC DOS bootable CD or a WinPE bootable CD options in GBW.
If someone could answer a couple questions or point out where answers might be that would be appreciated:
1) Is it possible to use the GBW to automatically span a large image (~4Gb) to a set of CDs while making the first CD bootable with WinPE? I don't want to split the image prior to creating the CD as the first CD would be partially used by WinPE and each subsequent disc would have unused space creating an unnecessarily large set of CDs. Currently I am adding the .GHO file in the add files section and when the process gets to create the CD it get the error message:
"Required files c:\doc...\temp\... not found."
2) Why when I try to use a MS/PC DOS bootable CD and add a split CD sized part of the image in the add files section I receive a message: "An unexpected error has occurred. Please check that the target is not read-only and that there is enough space on disk." The target is not read-only and I have adequate free space for a CD sized image.
I am using the latest available version available through LiveUpdate (shows 11.5.0.2141 in GBW).
Comments
From other threads it seems like the answer to my question 1) is not possible.
I've attempted to split the image into smaller parts (each part is 330mb) so that two parts fit to a CD. I have created a custom WinPE cd that contains Ghost32.exe and the first part of the ghost image. This allows me to use most of the space available on each CD.
However in testing this approach I have run into an issue with the way Ghost32 looks for the next span. The first CD runs the command:
Which works until it asks for the next span. I insert the second CD in the set which contains the files CDR00001.GHS and CDR00002.GHS. When I hit Next to continue Ghost32 throws an error for unable to find the next span. If I hit Browse it looks like Ghost is looking for CDR00002.GHS and if I press Enter gives the error that this file is not the correct next span. If I manually select the proper file CDR00001.GHS the ghost process continues with no issues.
Is there a way that I can get Ghost to correctly find the next span? I've tried both the 8.3 naming convention and the newer naming of CDR00000001.GHS, etc, and both fail with the same behaviour. I've also tried the -AUTO switch but it doesn't resolve the issue.
Below is the top part of my GHOSTERR.TXT:
1. Answer is no as you have already found out. GBW has no intimate knowledge of GHO format.
2. This is limitation of a DOS bootable CD. Unlike Winpe DOS cannot boot directly off the CD. It requires BIOS support for that. BIOS supports two types of emulation mode for CD boot - HD and floppy. What this means that GBW create a HD image on a CD so that BIOS can boot off the CD just like it does from HD. We cannot make HD big enough to fit too many files - certainly not an image. Out HD size is ~25MB. We opted for HD emulation long time ago so that we can fit more files than on a floppy.
Your other question about spanning. Ghost always looks for the next span on the same media. When ghost creates CD itself it has a very special naming convention then when you create a regular image (GHO/GHS). When you put regular image on a CD ghost will restore first span and will then look for 001.GHS. It will not find it and prompt you for next span. There was a bug that we fixed in live update 3 for GSS 2.5 that causes ghost to skip to next span name when it failed to find the one it needed first time. It is only a problem for people like yourself who create images on HD and then wants to copy them to CD. Pleaserun Live update 3 and get ghost build 2165.
Cheers.
Eugene,
Thanks for the quick reply. I believe I am using the build 2165 version of ghost as indicated in my GHOSTERR.TXT in the previous post.
What is the special naming convention that Ghost uses for CDs and would that help if I used it in my case? I think the problem is that ghost is looking at the last available span when I insert the next CD.
So on the CDs I have the following:
CD 1:
- WinPE (~150mb)
- CDR00000.GHO (330mb)
CD 2:
- CDR00001.GHS (330mb)
- CDR00002.GHS (330mb)
When CD 2 is inserted Ghost complains that the span we inserted is not the correct next span. I believe this is due to it looking for the last available span on the CD, which is CDR00002.GHS. Could you explain the logic Ghost uses to find the next span?
Thanks in advance.
Why spanning to cd's??
Can't you create an image to an Local D: drive or make an copy with GCS to an server?
it's much faster when restoring then cd media.
I am having the same problem
I am having the same problem as Nodrog except that I create the image straight to a disc(s) using ghost, which to my understanding that bug was fixed in build 2165.
The images I'm working with will fit onto one DVD. I can create, check integrity and restore an image from a DVD with no issues. But I also needed to test a spanned image so I have the same image spanned onto 4 CDs.
I have verified that I'm on build 2165 and no other updates are available. I'm using the new naming scheme (.gho) and I let ghost name the files.
When I check the integrity or try to restore the first disc runs fine but when it asks for the second disc and I put it in ghost will error that it "cannot open the image file e:\CDR0000#.gho [win32 error: (0x00000002) The system cannot find the file specified] (10010). Putting the next disc in the span just gives me an error that it's the wrong disc from the span.
Disc 1 has CDR00001.GHO, disc 2 has CDR00002.GHO, disc 3 has CDR00003.GHO and disc 4 has CDR00004.GHO
If I click browse and search the correct spanned disc and open the next sequential .gho file everything works fine but Ghost cannot open the correct one on it's own. It is always looking one file ahead.
Since it doesn't find the next span on the current disc it asks for the next disc but also asks for the next file, that should have been fixed in the latest build (When it should be looking for CDR0002.GHO it is actually looking for CDR00003.GHO so I have to browse to the 00002 file manually).
Anybody else running into this, any ideas?
Would you like to reply?
Login or Register to post your comment.