@Sebastian-Roth Thank you for all the details on how to make this work. I haven’t been able to work on our FOG server for the last few months so it has taken me a bit to try this out. I was able to get everything working except I get an update error. The error states “The server address is not correct.” This appears to stem from an issue where the live cd doesn’t have an IP address and can not connect to the update server. I’m looking for a solution now.

Attached is the screenshot of what is happening when i try to image using one of my copied images.0_1469042166199_ntfsflag.jpg

For those who may come across this same problem…

I updated my BIOS and it resolved the problem.

@svalding Hey that’s great you have it going now. Don’t forget to disable dnsmasq you started setting up. It will cause you some pain/confusion if its left running and you don’t need it.

https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

Follow the guide for the git method, dev-branch IS currently RC-1 on it.

@Gary-Kulovics @cpattersonit

Sorry for not responding sooner.

Please turn off any firewall you have on the fog server (sudo ufw stop or systemctl stop firewalld) and try again. Clear the multicast tables per the troubleshooting guide and then restart FOGMulticastManager with either service restart FOGMulticastService or systemctl restart FOGMulticastManager and try again.

If you haven’t, please go through the troubleshooting guide posted earlier. If you’re still having problems, I can help around 4:30 PM CST via Team Viewer, please send me a message via the forums here.

@Motech09 write down all of the passwords and IPs you’re using on the new server. drop the new server database (make a backup first). import a backup of the old database on the new server. open the new server’s web gui. it will ask to upgrade the database. update all of the passwords with the ones for the new server, since the new server how has all of the old passwords and IP addresses from the old database.

@Tom-Elliott It starts with this

[Sun Jul 17 07:35:03 2016] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.19 with Suhosin-Patch configured – resuming normal operations
[Tue Jul 19 07:11:36 2016] [error] [client 10.58.120.97] File does not exist: /var/www/favicon.ico, referer: http://10.58.8.20/fog/management/index.php
[Tue Jul 19 07:52:42 2016] [notice] caught SIGTERM, shutting down
[Tue Jul 19 07:53:42 2016] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.19 with Suhosin-Patch configured – resuming normal operations
[Tue Jul 19 09:51:24 2016] [notice] Graceful restart requested, doing restart
apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
[Tue Jul 19 09:51:25 2016] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.19 with Suhosin-Patch configured – resuming normal operations

Then I get this repeating for a bunch of IP addresses

[Tue Jul 19 09:57:46 2016] [error] [client 10.58.12.46] PHP Fatal error: Call to a member function query() on a non-object in /var/www/fog/lib/db/MySQL.class.php on line 89

@Tom-Elliott Ah ha, thank you!!

@Wayne-Workman I just wanted to update you on what I saw as I got it working.

In the multicast log, it was showing 0 tasks to be cleaned, but 3 tasks were found. Always. Every way I’ve seen here on the forums to destroy any udp casting tasks did not change the log continuing to show those 3 tasks. On two of the laptops I just happened to be trying to multicast that day, I took all source of power away and held the power button for 10 seconds. I then started a multicast task for those two, and they worked. Keep in mind that I haven’t been able to multicast for a few weeks now. I find it odd that that’s all I had to do, and on two random laptops at that.

Also with the timezone issue, the services not starting was happening before I even tried to set the timezone prefrences. I tried to set the timezone purely because my multicast log was showing dates four-five hours away. I don’t know the exact time, because the log is now reporting the dates correctly.

@Tom-Elliott

Update again from my current SVN.
Copy!
Will do. Thank you guys!!!

Thanks Fog is up and running again.

and using info from here: https://forums.fogproject.org/topic/7987/will-not-capture-windows-10-image/4 it seems that I have a successful capture happening now!

You guys are awesome. Thanks for all your help.

@Greg-Plamondon
Please see:
https://news.fogproject.org/fog-client-v0-11-4-released/

0.11.4 now downloads from the storage node if locations are setup.

@coco65 There’s been research in the area of FOG’s compression and delivery times.

The conclusion - 5 to 7 is best.

Read here:
https://wiki.fogproject.org/wiki/index.php?title=Image_Compression_Tests

@Tom-Elliott said in Page timeout when creating multicast task:

This, for now, does mean multicast from groups will not generate the requisite snapin taskings, but it’s only because I need to think of the logic to enable it. It should work hopefully soon.

I’ve been learning about triggers in mysql. It’s really super efficient, you could do all the snapin stuff from deployment with triggers.

Sorry it took so long.

I messed with it quite a lot tonight, and am fairly confident all of the issues (yes there were more than just the OSID issue) of Capone have been patched and appear to be working properly now.

Please update and test, and keep us informed. Thank you,

For a scratch installation, there are literally only 2 extra steps.
https://forums.fogproject.org/topic/7131/fog-on-ubuntu-16-04-php7/27

If MySQL users were messed up, your web interface wouldn’t work. FOG doesn’t setup a ‘fog’ user for MySQL. Typically it uses the root user without password to access MySQL if you’ve not manually defined a user/password in MySQL.

I doubt it’s permissions. It could be a corrupted image - but if that’s the case, it’s likely that the server HDD is dying or underwent a sudden power loss.

What’s stopping you from making a new image and trying that?

@Tom-Elliott you genius

Yes, I was copying files which I captured manually. Your three suggestions, to

temporarily disable replication, not create the image definition,
or use the dev folder

all work, and I’m not sure why I didn’t think of that… #facepalm