@mitzayapa Great to see that you were able to fix this yourself. Looking at the packet dump helps quite often!

@cschneider-tech said:

When I run command tftp <192.168.13.236> GET undionly.kxpe it returns “The system cannot find the file specified”

After reading the whole lot it all boils down to TFTP not delivering files properly. This can be caused by firewall settings on the FOG server, missconfigured TFTP, permissions on /tftpboot and many more things. Please follow this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP

@atarone where is 1.3.0 and why don’t I know about it? 1.3.0 is what we will label the latest trunk when we release but it has not reached that point yet. I’d have loved to have released by now but seeing as 1.3.0 will be the last of the php series, I’m trying very hard to make this version as stable as I can before it releases. I am not going to say yes it supports this or that thing because it isn’t guaranteed to work the same way for everybody. What I will say is if you need the support the latest development versions will most likely suit you better than anything else.

@j.schumacher99 can you run:

service httpd restart and get output from that?

Update for this topic.

After remounting the SAN to a different folder the image was still getting stuck in the dev directory. With @Tom-Elliott’s help we did an in-place upgrade to the latest Trunk. After doing this the image moved properly and there were no more issues. Thanks @Tom-Elliott! 🙂

Well then, marking this solved.

@Tom-Elliott
Everything appears to be fixed now! Thanks for your help!

FYI, my one image needed to be changed to Single-Disk (resizable) and I was updated to the latest SVN

Thanks for all your help!

@george1421
we have a few images. my script mount directly (i.e. mount /dev/sda2 /windows)
The problem is: now, our server will be used by another department with other config (i only know that they have 4 parts, using mbr) and sometimes the image name can change, disk layout too.
I like your idea and wanna let things more generalized as possible.
in any case, this is temporary until standardize all
Thanks a lot

Hi Wayne,

Thank you that worked perfectly!

@Wayne-Workman @Tom-Elliott

Today I updated to the latest version of fog (6042)… and deploy works well.
I’m very happy. Thanks for all.
Sorry for my english

@TThax use the ? to get the image listing. upgrading fog resets the image numbers. If using one of the listed numbers doesn’t work, it’s a bug. Post the issue in bug reports. (This is a fine example of what a “minor” bug is)

@Hanz What do the logs say for the multicast manager?

@Tom-Elliott Thx, that worked but now it finishes (I guess) and just loops. Ill post a seperate thread on that.

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