@Tom-Elliott Hi Tom

I meant I manually removed the snapin from /opt/fog/snapins folder on the server, was looking for a way to remove reference to same in the DB/Web GUI.

It doesnt’ matter now though I’ve just rebuilt Fog having backed up image and snapins etc I need.

Mark this one as resolved, thanks for your efforts.

regards Kiweegie.

Confirmed and fixed in v0.9.7 (https://news.fogproject.org/fog-client-v0-9-7/). Upgrade your FOG server to get the patch. Sorry about the oversight.

@Tonyflan https://github.com/fogproject/fogproject/issues/1

@Wayne-Workman said:

I’m pretty sure this is going to be fixed as soon as Tom implements the latest version of the new FOG Client into the trunk (version 0.9.6).

If you look at the announcement about it, it specifically talks about the backslashes and formatting stuff being fixed. https://news.fogproject.org/client-v0-9-6/

Fingers crossed!

Updated to 5313 and all is working.

@Sebastian-Roth I’ve removed the cached checking areas as I believe you are correct. While it maintains the IP of the pxe-received information, it does not know anything about the next-server/filename settings particularly when it’s being re-chained via proxyDHCP.

@danilopinotti If you can get in touch with me via Chat, I’d be happy to explain and even help out if we could schedule it.

Beyond that, follow the instructions below. Just test it for each revision. When you find one that fails, try the one between the failed version and the last working version you tried. Keep doing that until you find which version it is.

@Wayne-Workman That’s what my problem was. I changed my su password. I didn’t realize that affected the FTP credentials. Once I changed the other locations to match, everything worked perfectly. Thank You!

Turns out that my issue was as FTP based. I had mismatched credentials in my Main Server that was also causing my images to get stuck in the /images/dev folder. Once I solved this issue, the nodes worked perfectly.

Thanks so much!

@Tom-Elliott Have re-installed everything from scratch, it is now working, settings saving as expected 🙂
Thankyou all for your help.

Tony

Bumping this thread, today at work I updated to cloud 5293 svn 4323 and UEFI network booting is WORKING for the Optiplex 9020! 🙂

ALSO, Much progress has been made in the way of GPT and Windows 8 imaging using resizable and non-resizable image types. Read more about it here: https://wiki.fogproject.org/wiki/index.php/Windows_8_UEFI_Imaging_Tips

@Sebastian-Roth to be honest, it was an attempt at comminizing the files so they were very similar between efi and non efi. It was not to hurt anything, but a way to make things more similar.

It’s this separation that you see two ipxescript files as well.

@Wayne-Workman won’t matter.

They are both 40GB virtual disks, with 20-25 used. I’m going to let it run overnight and if it hasn’t finished by morning, I’ll look into the defrag. Thanks @Wayne-Workman !!!

EDIT

One just went through, so this should be resolved.

Thanks for the help everyone, it seems up and working now, but I can’t say I know why. I didn’t get to change the MaxRequestWorkers before it came up.

I did notice in /var I have a fog and a wwwfog directory which I never remember seeing.

@Sebastian-Roth said:

Thanks for posting this. Please check your apache DocumentRoot setting: grep DocumentRoot /etc/apache2/*/*

Seams a bit like thinks got mixed up. See the timestamps of /var/www/html/fog… It’s Jul 16. From the error messages we saw in the apache error log this is the one being currently used and probably what you will see when grepping for DocumentRoot. But the newest date (Nov 4) is /var/www/fog. And I guess this directory is from a newer trunk install but is not being used.

If I remember right Ubuntu changed from /var/www to /var/www/html not that long ago. Tom changed the installer to reflect this and maybe it ran into some condition on your system to also change this at some point.

My advice:

Backup all the stuff in /var/www by moving it (mv /var/www /var/www.bak && mkdir /var/www && chown www-data:www-data /var/www) Update FOG to latest trunk (cd path/to/trunk && svn up) Comment the wget command in the installer script as done before Run the installer Check DocumentRoot setting (see above) and compare with what you see in /var/www

I really hope this will get us one step further. I am very sorry that it took us so long to find out about those different fog directories in /var/www…

This worked for me! I had very similar issues!

Thanks!!

@Julianh If you’re running SVN builds, I’d actually recommend starting by deleting the backups.

I generate a backup of your GUI layout, now, for Every version of FOG you’re attempting to install.

This can eat up quite a bit of space as one can imagine.

I’d recommend (before allowing resources to eat up the 5% for system files and such) clean up the backup location.

Most layouts have a separate layout for /, /home, /var, and maybe others, but some installs use the / only setup.

Check in the /home (unless you changed the backup path for the installer) and look at how many folders of .BACKUP you have.

My guess is this is what’s eating up your space.

While, yes the backups do eat space and it is quite intentional, the backups may not be needed, I find it safer to have and not need, than need and not have. I use the backup folder/file now to ensure any “extra” data you store in the gui folder (for say ISO’s or alternative kernel files etc…).

@Sebastian-Roth Sorry I assumed login == working kit.

I decided this AM to break down my POC setup and rebuild it. Yesterday I attempted to learn objected oriented php programming to add a function to FOG and promptly whacked my install. I’m in the process of rebuilding it with a consistent build across all nodes. It appears that Tom was able to fix the LDAP part. I will test that once I get the environment resetup. Thank you for your assistance.

@george1421 said:

ou have done all of that, but are getting an apache error in

i will do so, in just a few

I used this, and it solved my issue…not as many steps nor as dangerous it seemed.

http://linuxmanpages.net/manpages/fedora20/man1/avahi-browse-domains.1.html