@Quazz said:

I reentered the password for the fog storage node and now the error log viewer is back, good call Tom!

@Tom-Elliott can we get some checks for that, so this doesn’t break the log viewer?

@middendorf bad patch cable… loose connection… or something like that I’m guessing.

@bakgat First look inside of /var/log You should see some files in there with the name fog_error_[version].log Errors from the installer are redirected to these files. Post the last few lines of those files (or the whole log). It’ll help with figuring out what’s going on.

The dhcp configuration file on CentOS 7 / Fedora it’s located at /etc/dhcp/dhcpd.conf
You might also try to install dhcp manually. on CentOS 7 and Fedora 19-21 you’d use yum install dhcp, on Fedora 22 and up it’s dnf install dhcp

You might also see what is written for start and end ranges inside of /opt/fog/.fogsettings if that file exists.

Confirmed Windows XP.

Image was created with Fog 1.2.0 from a reference machine. I know there’s been talk about a fix, but I posted here for the benefit of folks who use the released 1.2.0 and are trying to image older computers with smaller HDDs.

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