Ghost automatically determines the media type where the image is being saved to.
If it is a network share, it automatically assumes that it cannot handle more than 2 GB and spans it at 2 GB.
So as far as I know the only way to do this would be to save the image to a local drive and then transfer the file after it is created. The problem is that it is unlikely there is an extra local drive or partition to save the image file to.
1 of 1 people found this helpful
You'll find that various other imaging tools do the same (such as our own IMAGE.EXE / IMAGEW.EXE).
The reason for that is not a limitation of the imaging tool itself, but of DOS (yes, I do mean DOS).
Here's the problem - MS-DOS can only cope with a maximum file-size of 2 GB.
So, in order to prevent situations where "an image" is being taken in a non-DOS environment (where we're not limited by 2 GB files) and then to be restored into a DOS environment (where we ARE limited by 2 GB filesize), various manufacturers chose to do this method.
I'm not sure whether PowerQuest/Acronis does the same (I seem to remember that "no"), though they'll likely have command-line options to do this.
In any case, it's not a "bad" thing per se (since the total size is still the same really), just that ONE image you can restore in a DOS environment (the one that's split in 2 GB chunks), the other you cannot.
Operating systems limitations are a "wonderful" thing ;).
Hope this helps.
LANDesk EMEA Technical Lead.
This seems like the sort of thing it would have been insanely easy for them to add a switch for... Like "-RemoteFS:NTFS" or somesuch. So we can tell it that yes, indeed ghost32 is writing to an NTFS share that supports files >2GB and not something like FAT32.
Well, I suppose that this answers my question one way or the other ;). Even if it isn't what I wanted.
Thanks! At least it wasn't me doing something wrong in the LD scripts.
The problem is less the share you're saving the image TO, as it were, but rather the OS that you're restoring the image UNDER more commonly.
I.e. - if you TAKE or RESTORE an image in DOS, you can only cope with 2 GB files, regardless of file-system which holds the files on the network :).
But anyway - glad to have been of help.
LANDesk EMEA Tech Lead
The issue mentioned using Ghost32.exe so that would implies WinPE, not DOS, correct?
Yes, as I said, we're using WinPE for the boot environment that ghost32 runs in. There is no FAT32 or DOS at any point along this process, though I'm assuming that WinPE isn't running on a FAT32 partition....
Actually it is Fat32.
WinPE is built using a parition image. The partition image is created from a Fat32 partition, otherwise, the LDVPE1.IMG file would not be modifyable with WinImage and we wouldn't be able to write to it with our add a drive tool.
The RAM drive X: is created from this image, so I assume it is Fat32 as well.
OK, I stand corrected. But does the file system that the ghost32 executable is running from have any bearing on how ghost treats either the source or destination drives and file systems? Or is the fact that it's a network drive going to mess me up no matter what?
Well, I didn't even think of that as the cause until you asked. My only guess on how to find out would be to test. Find a machine with two drives (where the second drive is not a system drive but has enough data to cause the image to be greater than 2 GB), and while in Windows XP with an NTFS file system, try to save an image of the second drive to the same share.
Hopefully I'll have time to try that soon. Is there any particularly good way to get the WinPE image somewhere on a computer and then convert it to NTFS?
Same format as the other imagew.exe files perhaps?
I wonder if the FS convert utility is included in there...
Not really. You would have to recreate the image. We had instructions
on this that were used for resizing the image before we created the GUI
tool to resize the WinPE image.
I guess you would follow the steps and just use an NTFS partition
instead of a FAT32 partition:
Officially working "How to Resize the WinPE Image using
Warning: Increasing the WinPE image size with increase the time it takes
to install the PXE Representative, as well as the time it takes for a
device to PXE Boot to WinPE. It will also require more memory for a
device to be able to PXE boot. When testing a 180 MB image, a vmware
workstation with 256 MB of RAM allocated did not boot while a
workstation with 384 MB of RAM allocated did successfully boot.
To resize the image follow the steps listed below:
1. On a computer with enough free disk space on any hard drive, make a
new FAT32 partition with the desired size of the new WinPE image.
Note: For this example, a 180 MB partition mounted as drive W: will be
used. Make sure the size is larger than 120MB plus the size of all the
files that must be added into winpe plus 1 MB of extra space. If the
driver files are 15 MB, the minimal size should be 136 MB.
2. Locate LDVPE1.IMG and rename it to LDVPE1.ORIGINAL.IMG. This file is
located on the Core Server under
3. Open the LDVPE1.ORIGINAL.IMG using Winimage.
4. Extract all the files in LDVPE1.IMG to the newly created FAT32
5. Select File > Close to close LDVPE1.ORIGINAL.IMG but leave Winimage
6. In Winimage, go to Options > Settings > Image and uncheck the Use
automatic increment open/save wizard
7. Click OK.
8. Click Disk and select Use Drive W:
9. Click Disk and select Read Disk.
10. Save the image as LDVPE1.IMG. After its saved, copy LDVPE1.IMG to
11. Redeploy the PXE Representatives and once redeployed, verify that
the PEMenu.img and the PEBoot.img files were correctly replaced on the