I also had to disable selinux and the firewall in addition to the steps provided in the post from sam-white to get it to install properly. After I did all of those steps, everything worked fine and I have been using that server for about a month now.
Had a similar problem. Option 66 is being passed but the next-server in the bootp wasn’t set. Try using the CLI on the fortigate to go in and edit the DHCP settings.
From the CLI:
FORT-310B # config vdom
FORT-310B (vdom) # edit <vdom name>
FORT-310B (<vdom name>) # config system dhcp server
FORT-310B (server) # edit 1 //Replace 1 with the number of the DHCP server id on the fortigate if more than one configured
FORT-310B (1) # [COLOR=#ff0000][B]set next-server 192.168.X.X[/B][/COLOR]
FORT-310B (1) # end
Ok, after changing the label boot parameters to this:
LABEL fog.GParted
kernel fog/kernel/bzImage
append iso initrd=fog/Gparted/gparted.iso raw
MENU LABEL TEST - GParted 11 Disk Partitioning Utility
TEXT HELP
General Disk Partitioning Utility
ENDTEXT
the image boots partially until I get this error message in the picture attached. I feel that I am getting close, just don’t know enough about Linux to do figure this out on my own yet.[ATTACH=full]105[/ATTACH]
We had that same problem when we upgraded to fog 0.32. The latest bzImage kernels nic drivers don’t work for 1000HA. You will need to install an earlier version of the kernel. Please see the following page that also had the same problems as you (the fix is at the bottom of that page).
Client is booting with PXE:
1.1. bootp
1.2. download kernel + initrd over tftpd
1.3. booting kernel + initrd
kernel does dhcp request (no userspace dhcp!)
kernel starts init
init starts up services
init starts fog-script
fog-script collects some info and contacts server
fog-script run task according to info from server
8a) unicast: image over nfs
8b) multicast: image over udpcast
Client reports result to server and reboots
My FOG server is running on CentOS, so I used the instructions for Fedora to modify php.ini. However, apparently under CentOS, you must also modify the memory_limit setting, similar to Ubuntu, or large snapins will fail. I’m surprised my Intel video snapin worked.
Regardless, once I modified memory_limit to 1900M, the snapin downloaded. Sweet!
Specifically the process it goes through (i.e. when/where it touches the sql DB, when it touches the tftp). All multicasts are reaching the checkin (which goes though fine) and then reportst that it can’t find a job. Unicasts go though fine, so I’m trying to work out the difference.