No worries, glad it worked!

And I was right there with you when that happened to me, beating my head against a wall, trying to figure out what on earth was going on. I think I’d done so much flailing damage to my Fog installation that I just reinstalled after I figured why the dhcp-server wasn’t working.

[quote=“boon, post: 3157, member: 833”]What is the outcome of a multi-partition image?[/quote]
Mutli-partition seems to have worked. I haven’t tried deploying the image, but it spent a decent amount of time imaging. The files look right on the server, d1.mbr and d1p1.img (11.4 GB). I guess I’ll try a single partition image with a different model laptop/computer when I get the chance, see if it works better or not.

Sounds like the location set for /images is pointing to storage on the network but can’t get there.

This post has some similar sounding things which might help:
[url]http://fogproject.org/forum/threads/fog-server-fatal-error-failed-to-mount-nfs-volume.115/[/url]

Answered this one myself.
Install Ubuntu 10.04 & it installed with no problems.

Your best bet is to read the Fog user guide:
[url]http://www.fogproject.org/wiki/index.php?title=FOGUserGuide[/url]
Have to got the server set up correctly so that you can tftpd boot? Do you get the pxe menu up?

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]

[url=“/_imported_xf_attachments/0/105_Error.jpg?:”]Error.jpg[/url]

I am having the exact same issue, did you ever find a solution?

Thanks for the info, I’ll try and let you know.

Glad you figured it out. 🙂

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).

[url]http://fogproject.org/forum/threads/get-error-when-trying-to-download-image.453/#post-1961[/url]

See here - [url]http://fogproject.org/forum/threads/feedback-snap-in-system.49/page-2#post-3049[/url]

No, it’s not correct…

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

Aha! I figured it out.

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!