PXE Problems w/Ghostcast
I need to run an imaging server in my office for field computers. I had Ghostcast working great, but now it seems to have a problem. I use TFPTd32 as a DHCP server along with GhostCast. The remote computer connects and opens Ghost. However, when I click "MultiCast" or "Directed Broadcast" the local computer defaults to an address of 127.0.1.1 (or something close) The GhostCast server is operating on 10.1.10.250 so despite connecting to the actual server, the local computer can't find the Ghost session.
Does anyone have any clues or can I provide more information?
If the client computer shows an address of 127.0.0.1, that's a special case. That IP address is called the "loopback address", which means it's hardwired to send the traffic nowhere except back to the machine.
The reason that address shows up is because *there isn't any other one to use* that Ghost can determine. If you're using DOS-based Ghost, this generally means that the TCP/IP networking stack built into Ghost wasn't given an IP address by any means (such as a DHCP server).
If you're using Windows PE, then it's Windows that supplies all this and if 127.0.0.1 comes up it usually means that Windows could not find a driver for the specific network hardware on your machine. So, in that case you need to find a driver for you machine's network hardware and add it to Windows PE with the Ghost Boot Wizard.
Okay, Nigel. I gotcha. Let me say that I came from a 20 year Apple background so this Windows and Ghost stuff is fairly new to me. I'm using GhostCast 11.5 and TFTPD32 as my DHCP server. The boot file is called PXE.N12 and works perfectly with the Gateway laptops I have to image. However, the Dell laptops consistently come up with the 127.0.0.1 address on the local machine.
I realize that I probably have to add an Intel NIC driver (which is what the Dells use) but, for the freakin life of me, I can't figure out how to do it. I installed the 3Com Boot Services and tried to edit the boot file, but the PXE.N12 file always comes up as an invalid file when I try to edit it.
What am I doing wrong? [probably everything :-)]
Building boot packages in Ghost Solution Suite 2.5 is always done through the Ghost Boot Wizard, as covered in the product documentation and tutorials. Not surprisingly, this applies to the PXE boot packages as well, although the fact that the Boot Wizard hides the PXE options if 3Com boot services are not installed means that people often don't make the connection that it's the Boot Wizard that builds these.
So, you need to build a new boot package with the right driver (or one of the "Universal" drivers, if using DOS, or a multicard template, or one of the other variations) using the Boot Wizard, and then you need to ensure your PXE configuration is set up to deliver that newly-built package to the suitable machines.
A small piece of basic PXE theory of operation: PXE booting is a multistage process, just as disk booting is, with a succession of boot loaders (and menus, and what have you). The .N12 files are, by convention, the actual boot packages as specified in the PXE protocol, which means they are very limited in size and are expected to contain a real-mode 8086 secondary boot program which then uses the basic UDP and TFTP services provided by the Boot ROM to go through a more elaborate boot process of some kind.
So, the .N12 files are not (or at least, not if people follow the naming convention) the real things you ultimately boot, but rather loaders. Each .N12 loader uses a process for the next stage appropriate to the operating system being booted, and thus the layout of the TFTP server's files and directories that it expects to find and use for the next stage.
In the case of 3Com Boot Services and PC-DOS boot packages, the 3Com code contained a package builder and second-stage boot loader which the Ghost Boot Wizard uses; the GBW-built packages are in effect hard disk images with a special header attached, which the 3Com-supplied second-stage loader knows how to install as a RamDISK. The GBW thus builds a sector image of the PCDOS hard disk with the OS and drivers, and attaches the various parts licensed from 3COM to suit 3COM's environment.
In the case of Linux boot packages, a different .N12 boot loader and hard-disk image format are used, while for Windows PE yet another .N12 boot loader and hard-disk image format (in this case, .WIM files) is used. In all these cases, the Ghost Boot Wizard knows the conventions involved in building the packages, but it's up to you to install them and ensure that the correct boot loaders are used.
Just as a general point, almost any VM technology will use an emulated hardware type that's completely supported by WinPE without extra drivers - additional guest drivers in VMWare, Virtualbox, and Virtual PC/Virtual Server are mostly about paravirtualization, escaping out of the VM via a side channel for higher performance rather than being required for correct operation.
More importantly, the VM systems tend to run absolutely stock, completely unmodified PXE boot ROMs such as the Intel boot agent. Which makes them quite handy for testing, because they really are excellent models of real physical hardware (I certainly did a fair bit of PXE booting into VMs when writing a high-performance TFTP and PXE server last year, just before I was laid off).
I wouldn't expect any difference whatsoever between PXE booting in a VM versus a real machine except that whatever the source of the problem in the VM, it won't be a driver issue.
It's hard to know from the description given whether the error is being reported from the PXE ROM or one of the 3COM later-stage load shims, but it may well be from the 3COM final boot loader. Doing the final booting in a 3COM system is usually done by taking a hard disk image and wrapping it in a special container to prepend it with a header which describes it to the boot loader so it can set up the RAMdisk to load the data into (the TFTP protocol doesn't allow seeking to arbitrary file positions, so a header at the front helps things a lot). If the final stage of the 3COM boot is pointed as a disk image that *doesn't* contain the proper wrapper, it won't be happy.