@FlowLive
It seems since I am using trunk this is not applicable anymore using the newer client version.

Thanks again to Wayne Workman helped me out figuring this and updated the wiki with a note for the ones running version 1.3.0 of the server.

I will leave this post as resolved in case someone else in the future also looks for this info.

Lets try to get a little clarity around your setup here.

You have install fog, is it safe to assume you installed 1.2.0, or did you install the current fog trunk version (i.e. pre 1.3.0)?

Is it safe to assume you are using a Microsoft dhcp server? (your event log might suggest something different). One might think you have two dhcp servers covering the same subnet.

What exactly did you set options 66 and 67 to?

What is the IP address of your fog server?

@Wayne-Workman Sure

The content of /etc/subversion/servers on my servers are like this:

[global] http-proxy-host = 192.168.1.56 http-proxy-port = 3128

for git you can issue the following commands (from stackoverflow.com😞
git config --global http.proxy http://192.168.1.56:3128
git config --global https.proxy https://192.168.1.56:3128

If you really wanted to not use env variables, then wget has proxy settings in /etc/wgetrc just uncomment the proxy lines and add the appropriate values and save.

@sutra added to the wiki here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Uploading

@Gardinero Added to the wiki here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_TFTP

Didn’t know where else to put it… it’s close enough to a tftp issue.

@Tom-Elliott said:

I’m not able to replicate the memory usage, but what I could suggest is to up the memory limit? I don’t know, what, on your system is trying to use it all. You can Up the memory limit from FOG Configuration Page->FOG Settings->General Settings->FOG_MEMORY_LIMIT. It’s done in megs, so 128 = 128M, 256 = 256M etc…

Added here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Web_Interface

@amr said:

I will definitely keep it enabled as it takes one step out of the deployment process for us, nice work!

The client will also auto-name, and auto-join to domain… and a bunch of other things that will take many steps out of your deployment process.

@Wayne-Workman Great, 10x man. I will read and try it as soon as posible!

@Wayne-Workman said:

When I ask about specific settings, did you put anything into the drive field for the tablet? What boot file are you using for it?

Nothing in the drive field was needed (fog recognized the SSD as /dev/sda ) and I used the stock truck ipxe.efi boot file.

Thanks… I’ll check that out… I see that you said you were going to work on something on that post.

@Wayne-Workman

I’m catting the latest log file and that’s all I’m getting. Should I run the upgrade again and see if it generates a new file?

okay, the folder should have the same name…
The folder is named the same, size in Image management is still 0iB

is a reboot or service restart required?

0_1452865486563_fog-.PNG
0_1452865348267_fog-.PNG

edit:
SOLVED!

Notice: FOG create the folder without dashes (-)
renamed the Folder from “Phase1-without-Progs” to “Phase1withoutProgs” and it works

cd /images mv Phase1-without-Progs Phase1withoutProgs

Thanks dude 😃

@BASURILLABAS2 Ok, now you have a trunk version installed with the good settings in Multicast ?

@Andrew-Aitken I’m not saying there isn’t a way, but there is no way that I know of to convert an image other than deploy and recapture. Maybe one of the devs has a better idea. But the quickest route is to deploy and recapture.

@nbuursma said:

Got it, okay first thing that fails is
Attempting to check in… Failed

Then screen is filled with complete GARBAGE

Can you get us a picture?

How is it that it fails on check in, when before it failed at the very end? What changed?

Cool - issue resolved!

This was absolutely an issue on our network, but we’re not sure if it was an old static Rendezvous Point that was configured on our core or if it was our VPC redundancy between our two nexus switches, but we were able to solve it by disabling pim on one of the nexuses and removing that static RP.

Thanks for the help on investigating, everyone. It’s much appreciated.

@Arrowhead-IT

“What version of Ubuntu are you running?”

Ubuntu 14.04 LTS

@Scott-B What I’m saying, somebody edited something in the code.

I’m not enforcing any PHP 7 anywhere.

Edit the /opt/fog/.fogsettings file and remove the packages line. Then try re-installing. Maybe it’ll work better?

@Wayne-Workman said:

If you liked that, FOG Trunk will blow your socks off. 👍

As far as I know, imaging unregistered computers using FOG Trunk only works with Unicast.

You can set (in storage management) how many active tasks are allowed. I keep mine set at 2. Then you network boot all machines. 2 will start. The rest wait in line and automatically start.

Thanks for the suggestion to move to trunk, and thanks Quazz for the clarification on whether or not multicast worked. This is exactly what I wanted/needed! 🙂

For any wayward googlers:
I upgraded my install to trunk using these instructions: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk pretty straight forward.

After the upgrade completed, I went back to image management in the web gui, selected multicast image, started a new session for the amount of clients I wanted, netbooted each client to fog’s boot menu and selected join multicast session. it goes when the specified number of clients connect.

Wonderful. Thanks a lot, guys. 🙂