@Tom-Elliott Ok so I understand the image replication wierdness…let me ask about the snapin replication. I’m getting

* Found Snapin to transfer to 5 group(s) [11-16-15 3:20:27 pm] | Snapin name: Essentials Install [11-16-15 3:20:27 pm] * Starting Sync Actions mirror: Access failed: 550 Failed to change directory. (/opt/fog/snapins/MSEInstall.exe)

in error log on server, and this one node seems to be copying the actual snapin “MSEInstall.exe” as a directory as shown below.

cd[bcs@ramage ~]$ cd /opt/fog/snapins SVN 5374 [bcs@ramage snapins]$ ls -la total 1324256 drwxrwxrwx 5 root root 4096 Nov 16 15:20 . drwxr-xr-x 5 root root 4096 Nov 6 10:30 .. drwxrwxrwx 2 root root 4096 Nov 6 10:29 CA drwxr-xr-x 2 fog fog 4096 Nov 16 15:22 MSEInstall.exe -rwxr-xr-x 1 fog fog 677099526 Nov 6 13:05 OfficeUninstall.exe -rwxr-xr-x 1 fog fog 6144 Nov 6 13:05 Repin.exe -rwxr-xr-x 1 fog fog 678899577 Nov 6 13:04 setup_silent.exe drwxrwxrwx 2 root root 4096 Nov 6 10:29 ssl

UPDATE: Per SVN 5374 tokens are being created correctly… Thank you @Tom-Elliott !!!

Please update.

I believe this is now resolved.

Sorry it was the way it was trying to store the data.

Ok, I found the reason. My old nodes are all 32-bit (we run fog on recycled hardware basically), my new node is 64-bit. In the freespace.php a recent change (somewhere within the last few months) made calculating $hdtotal and $hdused use intval(). This made them integers which is not a big deal on 64-bit systems in PHP but in 32-bit systems the harddrive space in bits is higher than the maximum size of an integer. If I restore the old freespace.php file it works fine.

I don’t know a lot about coding in PHP but is there a way to cast the result of the calculation to a double or long for 32-bit compatibility?

@george1421 , I already have a firewall configuration that has been tested for awhile now and works (the hardest part was nfs as it was using random ports, but that is easily limited). As for SELinux I already have a policy made, I just need more people to test it and see if I missed anything (after I package it up nicely).

Can you please update and try again?

I found that while I removed the old “cached” code setup stuff, apparently it still likes the nic’s to come down, then up before ipxe dhcp will readily accept data.

yeah, but only with CLI on the server

some roughly written history is in the history table.

mysql
use fog
select * from history;
or
select * from history where longtext like '%some image name here%';

Just simply doing the select * statement, you’ll see the sort of entries being made. You can then format a like search for the field you want and the sort of data you’re looking for.

AND… I can’t be positive on my SQL syntax above… but I think you get the idea…

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