Ghost Solution Suite

 View Only
  • 1.  GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Jan 15, 2013 04:48 PM
      |   view attached

    Problem Description

    I am a novice user of Ghost.

    I have a ghost image of Win7 x64 size-limited to 4 GB spans that was created
    with ghost32.exe.  It consists of a 100 MB System Reserved partition and
    another partition that contains just a C: drive.

    When executed from a DOS batch file, the DOS version of Ghost v11.5
    (ghost.exe) from Ghost Solution Suite v2.5 executes a two-line ghost script.
    Upon reboot the Windows Boot Manager displays the following:

                                Windows Boot Manager

    Windows failed to start.  A recent hardware or software change might be the
    cause.  To fix the problem:
         1. Insert your Windows installation disc and restart your computer
         2. Choose your language settings, and then click "Next".
         3. Click "Repair your computer."

    If you do not have this disc, contact your system administrator or computer
    manufacturer for assistance.

    Status 0xc000000e
    Info   The boot selection failed because a required device is inaccessible.

    ENTER=CONTINUE                                                 ESC=ABORT


    I think that Ghost is executing the first line of the script and not the
    second.  The two lines of the script "tmp2.rst" are as follows:

    -Clone,Mode=pload,dst=1:1,src=..\base_os\tmp.gho:1 -fx -sure -span -ntic -afile=c:\\Logs\\GhostErr.txt
    -Clone,Mode=pload,dst=1:2,src=..\base_os\tmp.gho:2 -fx -sure -span -ntic -afile=c:\\Logs\\GhostErr.txt

     

    Work-Around

    A coworker of mine (with more ghost experience) was able to run ghost from
    the DOS command-line to restore the ghost image on an Lenovo T61p laptop.
    He is investigating using NTUtils as a short-term alternative to using Ghost.

    Attachment(s)

    zip
    tmp2.zip   227 B 1 version


  • 2.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Jan 16, 2013 06:53 AM

    For modern hardware, you would be much better off using WinPE rather than DOS, as DOS has many limitations when used with modern hardware.

    When using DOS, it is normal to have a 2Gb span size, as this is the file size limit of "regular" FATxx partitions.



  • 3.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 01, 2013 11:23 AM

    My comment regarding the WorkAround of investigating NTUtils was incorrect.  He is investigating NTFS Utils.

    For now, I am stuck supporting a legacy DOS solution.  I tried and failed again with the following differences in the environment:

    1. I took EdT's advice and created a ghost image of Win7 (100 MB System Reserved, the rest C:\) using Ghost v11.5 invoked with command    ghost32.exe -span -size=2048   It created tmp.GHO, tmp001.ghs, tmp002.ghs, and tmp003.ghs size limited to 2GB.  I was able to verify the image by using Ghost v11.5 (ghost32.exe) to restore the image to a Lenovo T61p Laptop.
    2. I un-escaped the file path C:\\Logs\\GhostErr.txt as C:\Logs\GhostErr.txt in the tmp2.rst ghost script file.
    3. I manually renamed tmp.GHO to tmp.gho (all lowercase)
    4. I tried to restore the image using Ghost v11.5.1 (ghost.exe)

    I see Ghost v11.5.1 starting up and then going away quickly (a bad sign), the CMOS gets loaded, and upon reboot, I get the "Windows failed to start" message from the Windows Boot Manager.

    I manually ran ghost and got:

    Internal Error 36000

    An internal inconsistency has been detected

    If the problem persists, contact Symantec Technical Support

    at http://www.symantec.com/techsupp/

     

    Before I pressed the OK button, I copied the Details:

    Connection type Local

    Source Partition Type:7[NTFS], 100 MB, 24 MB used, System Reserved

                               from Local File C:\BASE_OS\TMP.GHO, 152627 MB

    Target Partition Type:7[NTFS], 103 MB

                              from Local drive [1], 152627 MB

    Current file        98 tracking.log

    I manually ran ghost again with manually typing the command-line parameters from the second line of the file.  Ghost v11.5.1 appeared to be acting normally with an advancing progress indicator.  I copied the Details:

    Source Partition Type:7[NTFS], 152525 MB, 18516 MB used, Disk Load

                               from Local file C:\BASE_OS\TMP.GHO, 152627 MB

    Target Partition Type:7[NTFS/HPFS extd] 121794 MB

                              from Local drive[1], 152627 MB



  • 4.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 01, 2013 12:54 PM

    Are you using Lenovo's System Recovery software in your base image, as this creates a non standard boot sector if I recall correctly, and I think you need to use the /IB switch to get around this.

    I note you did not comment on using DOS rather than WinPE. Are you imaging machines with the bios set to compatibility mode as DOS does not have SATA support?

    Do you have any Advanced Format disks in your hardware? If so, you may need to specify cylinder boundaries due to the way these drives work.



  • 5.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 01, 2013 06:40 PM

    Create a disk image with -IB swiitch and restore the same,which should be the straight forward solution.



  • 6.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 06, 2013 12:24 PM
    EdT and Maneesh, The images I created from a WinPE Bootable Ghost v11.5 CD, are restorable to the same T61p laptop. I create the GHO image, wipe the partitions using "gdisk32.exe 1 /y /del /all, and restore the image. If the image is created without the -IB switch, it is restored without the -IB switch. If the image is created with the -IB switch, it is restorable with the -IB switch. The images I had created are not using Lenovo's System Recovery software. I did not see it in the list of installed programs. It is using some kind of Lenovo power management software. I can run "ghost32.exe -script=tmp2.rst". Ghost32.exe fails if I had not already created the partitions. If I create the partitions: "gdisk32.exe 1 /CRE /PRI /SZ:100" and "gdisk32.exe 1 /CRE /PRI /SZ:152521" and then run ghost "ghost32.exe -script=tmp2.rst", it works fine. In my test MS-DOS ramdisk environment, I am telling the legacy "software" to create a 100 MB partition and the rest, a second partition. From my comments above, it appears that the second partition being created is 30 GB smaller Source Partition Type:7[NTFS], 152525 MB, 18516 MB used, Disk Load from Local file C:\BASE_OS\TMP.GHO, 152627 MB Target Partition Type:7[NTFS/HPFS extd] 121794 MB from Local drive[1], 152627 MB EdT, What is the proper way of checking for an Advanced Format disk? I executed the following command: "wmic partition get BlockSize, StartingOffset, Name, Index" which returned "Block Size Index Name Starting Offset 512 0 Disk #0, Partition #0 32256 512 1 Disk #0, Partition #1 108380160 " I don't know whether this is a physical block size or a logical block size. I am using a 160 GB Seagate Momentus 7200.2 hard-drive. It is spec'd to 512 bytes per sector in the product manual. EdT, I still need to get back to you on how the BIOS is set.


  • 7.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 06, 2013 02:02 PM

    OK, it's not an advanced format disk, as a 160Gb drive does not need it.

    When you say that the second partition is being created 30Gb smaller, what exactly do you mean? Are you saying that there is 30Gb capacity left unused on the drive?  If so, the reason for that is the limitation of how MSDOS addresses hard disks using 28 bit LBA, which I believe was the address limit that DOS could handle. (http://en.wikipedia.org/wiki/Logical_block_addressing)

    If you work out the number of sectors represented by 2 to the power 28, and then divide by 2 to get the number of Kilobytes storage this represents, the figure comes to around 132 Gb. 

    Again, there are other variables including the age and design of the bios, but it's one reason I would always recommend using WinPE for any recent hardware.



  • 8.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 19, 2013 04:47 PM

    Edt,

    In the case where I have a 100 MB "System Reserved" primary partition and a 96 GB Win7 primary partition, using a Ghost Bootable CD (WinPE), I can manually use GDISK32.exe to create two primary partitions (100MB and 96 GB) and use the ghost32.exe manually to restore these partitons. I am using Ghost v11.5 here.

    It appears that in the linux PXE (bootable from CD), we are creating a 30 GB primary partition prior to starting the DOS ramdisk.  In the DOS ramdisk, we are passing in parameters to FreeDOS FDISK v1.2.1 to partition the hard disk drive.

    In the simple case where I have a ghost image of Win7 on one primary partition of a particular size, FDISK creates a primary partition and Ghost restores a clone of that image to the newly created partition and eventually upon reboot, It boots and I have a two primary partitions (one of them 30 GB).

    In the case where I have a 100 MB "System Reserved" primary partition and a 96 GB Win7 primary partition, FDISK creates a 100 MB primary partition and an extended partition containing a logical partition of 96 GB.

    When GHOST.exe v11.5.1 executes, it restores the 100 MB partition fine (I think) and now blows up with a

    General Protection Fault in RMCB at eip=196330; flags=3002
          eax=ffff0001 ebx=00001246 ecx=00000000 edx=000015c3 esi=0000142a edi=00002418
          ebp=00acacfc esp=000023fc cs=af ds=3b es=33 gs=bf ss=33 error=0000

    and GHOST.exe returns a non-zero return code.

    Is there anything that I need to do to Win7 before I image it with ghost (besides removing temp files and defragging)?

     



  • 9.  RE: GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

    Posted Feb 20, 2013 09:41 AM

    To be honest, I am confused about when you are using DOS and when you are using WinPE. Mixing the two environments may be the underlying cause of your problems. There should be no preparation required when creating a Win 7 image, but you need to ensure that the source partition numbering will be the same as the target partition numbering. Thus if the source has a boot manager in the first partition, then not imaging this will result in a partition numbering shift on the target which will definitely stop Win 7 booting.

    Can I also check that you are using build 2266 of Ghost 11.5.1, as this has not been mentioned anywhere in this thread.

    As I have no Linux experience, I cannot advise you on any Linux aspects.

    Have you tried creating a disk image as a test?

    Finally, when using WinPE to build systems, I personally prefer to use the DISKPART utility in WinPE to clean and to partition disks - you can get an idea of how to do this in my article:

    https://www-secure.symantec.com/connect/articles/readyadventures-winpe

    where it looks at creating bootable USB devices. The diskpart commands are used in that, but of course you can run DISKPART from the WinPE command prompt and then type ? for help.