UPDATE! It works!
Turns out the issue was all of my ISOs after all. Somewhere along the line of transferring them via ftp from my windows IIS server the data ended up being cut off; which I assume is why the “MEMDISK: Image appears to be truncated” message was there.
This is what happens when I try to cut corners on a terminal-only linux box… 
Thank you for your help, and sorry to be a bother.
So I copied your menu item settings exactly and it’s still happening…
There’s a few new lines this time. The rest appears to be the same as above
[CODE]El Torito boot catalog sanity check failed.
…
MEMDISK: Image appears to be truncated[/CODE]
Maybe the sanity check thing is the key? I’m not sure what it means but I’ll be researching it while this post is up.
Yeah, I ended up following this guide to put it on a USB stick and that worked fine. This is also the same ISO that I have used in the past as an actual bootable DVD. [url]http://www.hiren.info/pages/bootcd-on-usb-disk[/url]
I don’t think I’ve ever encountered a machine that wouldn’t boot this ISO on USB/DVD in a way like was described in the link you posted.
Also after your last reply I thought I should try some other ISOs to rule it out as an issue with the hirens.iso so I grabbed an old copy I had of TinyCore, Slitaz, and DSL Linux; I tried those and they resulted in similar, the only difference being that one more line was added to the output I posted above.
[QUOTE]ISOLINUX X.XX yyyy-mm-dd[/QUOTE]
Where the placeholders are the version, and date of release of ISOLINUX
After doing that the end results are the same, unfortunately.
The client is still able to download the ISO and start memdisk using the ISO as a ramdisk.
I changed the memdisk line to the below as described;
[CODE]:hirens
initrd ${boot-url}/ISO/hirens.iso
chain memdisk ||
echo failed to boot
prompt
goto MENU[/CODE]
And this is the output on the clients screen is;
[CODE]Ramdisk at 0x1abf8000, length 0x252f71ba
command line:
MEMDISK: Image has fractional end sector
MEMDISK: Image seems to have fractional end cylinder
Disk is hd0, 609244 K, C/H/S = 594/64/32 (guess/guess), EDD on, rw
Using safe INT15h access to high memory
Code 1744, meminfo 264, cmdline 1, stack 512
Total size needed = 2521 bytes, allocating 3K
Old dos memory at 0x94c00 (map says 0x94c00), loading at 0x94000
1588: 0xffff 15E801: 0x3c00 0x19bf
INT 13 08: Success, count = 2, BPT= 0000:0000
Drive probing gives drive shift limit: 0x83
old: int13 = 94x0000a int15 = 94c003ba int1e = f00082ad
new: int13 = 9400000a int15 = 940003ba int1e = f00082ad
Loading boot sector… booting…[/CODE]
Looks like there is a section referring to the integrity of the ISO right after the command line. Is that normal when booting ISOs?
Hello all!
I’ve decided to start delving into the advanced menu options of fog and noticed that as of FOG 1.x.x it has changed to use iPXE style commands as opposed to the classic pxelinux.0 style commands. So after a bit of research and coming up with threads/help pages written by the wonderful people here such as -
[URL=‘http://fogproject.org/forum/threads/ipxe-advanced-menu-or-memdisk-problem.10544/’]http://www.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options/[/URL]
[URL=‘http://’]http://fogproject.org/forum/threads/ipxe-advanced-menu-or-memdisk-problem.10544/[/URL]
At this point I had thought that it was just that hirens didn’t work anymore, but then I found this thread -
[url]http://fogproject.org/forum/threads/ipxe-iso-boot-problems.10929/#post-31316[/url]
I am also able to browse to the location on the fog server and get a download of the hirens.iso so I know it’s not a path issue at this point.
Here is my advanced menu config (which matches the one in the last link regarding the ISO/memdisk parts):
[QUOTE]
set boot-url [url]http://${fog-ip}/${fog-webroot}[/url]
:MENU
menu
item hirens Hirens Tools
item hostinfo HOST Information (Your MACHINE Info)
item return return to previous menu
choose target && goto ${target} || goto MENU
:hirens
initrd ${boot-url}/ISO/hirens.iso
chain memdisk iso raw ||
echo failed to boot
prompt
goto MENU
:hostinfo
echo This computer : ||
echo MAC address…${net0/mac} ||
echo IP address…${ip} ||
echo Netmask…${netmask} ||
echo Serial…${serial} ||
echo Asset number…${asset} ||
echo Manufacturer…${manufacturer} ||
echo Product…${product} ||
echo BIOS platform…${platform} ||
echo ||
echo press any key to return to Menu ||
prompt
goto MENU
:return
chain ${boot-url}/service/ipxe/boot.php?mac=${net0/mac} ||
prompt
goto MENU
[/QUOTE]
I suppose that I should mention that my setup is a little non-standard in that I have a secondary drive for all images, and the main one is only big enough for the OS. So I have the hirens.iso on the second drive (which is mounted on /images) in a folder called BOOT, which is then symlinked to the folder /var/www/fog/ISO/. Not sure if symlinks could cause this kind of issue, but I figured mentioning wouldn’t hurt.
Thank you everyone for any help!
Sorry for the misunderstanding on my part! Glad to say it worked like a charm!
Thank you so much for your help guys. 
Just a thought here:
Might I suggest making this a part of the default install for a windows environment install? I say this because my server is available for me to configure (which made me think that the link above didn’t apply since mine wasn’t “unmodifiable”) but when following default install procedure the system didn’t work in the end. With this dnsMASQ setup it works beautifully though!
It just feels to me that this may be a required step for a windows server based DHCP setup.
Thanks again!
Hello again, thank you for your answer! Unfortunately we are mostly a Windows house, and DHCP is one of the systems that is “required” to run on Windows. Are there any options other than switching to dnsMASQ?
Contents of the [/tftpboot/default.ipxe] file:
I also checked my /var/log/foginstall.log for errors and found nothing obvious…
As well I’ve checked the apache2 error.log and it doesn’t show anything after a PXE client’s boot attempt.
I’ll post them once I’ve managed to transfer them off the server.
Hello all! I come grovelling for help from the OpenSource masters in my time of need. haha!
As the title says, I have been having an issue with PXE booting client machines. They will boot, get assigned an IP via DHCP, seems to get grabbed by iPXE (even configures correctly it seems!), then stops at the loading “default.ipxe” part with the error “Connection timed out ([url]http://ipxe.org/4c126035[/url])”
I have been able to get FOG to work before using v0.32 on a LinuxMint desktop in an isolated network [via switch] (maybe 2 years ago). As well as today using some virtual machines with FOG v1.2.0 on an Ubuntu server in an isolated network.
In my lab environment I have:
This is the process by which the above (working) lab environment was setup:
I install Ubuntu server x64 as a terminal only server, assign static IP address as appropriate for the network, connect it to a portgroup that has internet access, install VMware tools, do dist-upgrade, then proceed to install FOG_1.2.0. Going through the install I decide to setup the Ubuntu server as the DHCP server as this will be on an isolated network, all other options are left as default as well.
Once fog is installed I boot my VM client and it immediately jumps from getting an IP to loading /default.ipxe to showing the FOG menu. IT WORKS! 
BUT if I follow the same procedure except I don’t make the Ubuntu server the DHCP server - instead setting options 66 = <serverIP> / 67 = undionly.kpxe on my Windows 2000 DHCP server - then it fails at the line:
" /default.ipxe… Connection timed out ([url]http://ipxe.org/4c126035[/url])"
I have read that my issue is caused by the TFTP service not running/listening, but I don’t understand how my LAN vs an private VM network (essentially a switch) can mean the difference between tftp working properly or not…
Any help would be appreciated in solving this!
Thank you everyone!