I've been working on this with QA and there are some things to confirm, along with an idea of a possible workaround. Something that may be useful in addition to the GHOSTERR.TXT is some data from
this DOS utility I whipped up to help investigate this.
Here's some sample output from this for a 32Mb VMware VM - it's best to run this from a boot floppy or bootable USB keyring without HIMEM.SYS installed so it can see the raw BIOS numbers.
1588 30656kb = 0x01df0000
15e801 low 15360kb = 0x00f00000
15e801 high 15296kb = 0x00ef0000
E820 memory table:
00000000 0009f800 00000001
0009f800 00000800 00000002
000dc000 00024000 00000002
00100000 01df0000 00000001
01ef0000 0000f000 00000003
01eff000 00001000 00000004
01f00000 00100000 00000001
fec00000 00010000 00000002
fee00000 00001000 00000002
fffe0000 00020000 00000002
15E820 total 31680kb = 0x01ef0000
Now, on to the theory. It turns out that with the 3COM PXE server, our QA folks found that the 3COM boot packages did not work well with Ghost - running it corrupted the in-memory copy of the boot filesystem. The reason for this turns out to be a design error in the 3COM Floppy emulation that doesn't interact with protected-mode DOS programs well, but our QA people found a workaround for this by using HIMEM.SYS (which it does notify of the memory it uses) in the boot packages we build....
...which works, but it turns out that the IBM PC-DOS version of HIMEM.SYS has a design limit of its own, which is that it's unaware of the more recent BIOS APIs for determining all the memory in a system. It uses the first two APIs my tool reports on, so it's effectively limited to 64Mb of memory. This isn't normally a problem, except that...
...a few machines have design flaws in their BIOSes, which means that although they support all the various memory-reporting APIs, their implementation of the oldest one (INT15/AH=88) for some reason reports only 16Mb of extended memory instead of the 64Mb it is capable of reporting. If you look at my sample above, the first line being reported is 32Mb, but some BIOSes never report more than 16Mb even though they could report more.
Because reporting less memory through this API is also a well-established convention for disk emulators (like the IBM RIS system, as well as PXE) to hide their memory from DOS extenders and HIMEM.SYS, the PC-DOS version of HIMEM.SYS on these machines only registers 16Mb of usable extended memory.
The end result of this cascade of small faults can be problems like the one you are observing. I've done some work on how we can resolve this fully in future versions, but for now it would be good to confirm which of the above factors are really at play in your environment.
In the short term, if you are using PC-DOS then using MS-DOS may help; the reason is that the HIMEM.SYS used in MS-DOS V7 (the Windows 9x editions) is aware of the INT15/AX=E820 BIOS API because Windows was itself reliant on that. Indeed using the MS-DOS HIMEM.SYS by itself in the PC-DOS boot packages may well be all you need. Unfortunately we can't supply that for you but it's something to try.