@Tom-Elliott said in Log Viewer doesn't list all logs due to number of storage nodes:

Logs are only pulled from “master” locations, and only if they’re “enabled” too.

That explains it. Only all the masters are listed. Thanks.

@pcayphas I’ve already answered you here: https://forums.fogproject.org/topic/8790/upgrade-to-1-2-0-failed-php-bcmath-problem Please do not make duplicate posts, it will not help you to get help faster. We are already a very active and fast responding community and duplicate posts just irritate us.

@Wayne-Workman What do you mean intermittent?

Confirmed and fixed. Maintained as RC14.

Found and fixed for RC-14.

I’ve tried the up-comming rc-14 with Fedora and it installs without any issues beyond needing firewall and SELinux configured as you would normally need to do.

I’ve confirmed full registration works with imaging too.

I’m solving for now in that the group bad entries should he corrected for. I won’t know for sure until I get a bit more of a testbed but I still have had 0 luck in replicating since this was brought up and RC 11 was pushed out.

@Tom-Elliott ok service re-enable, I keep fingers crossed 😉

@LibraryMark I’m 90% certain this has since been fixed. Mainly due to the first reporting I did a bunch of tests lol.

Threads with the same original issue:
https://forums.fogproject.org/topic/8711/host-won-t-image-automatically-after-full-host-registration-and-inventory
https://forums.fogproject.org/topic/8721/no-imaging-after-host-registration
https://forums.fogproject.org/topic/8669/host-registration-doesn-t-start-image

@Tom-Elliott
I have done with phpmyadmin and it worked well

@arnaudrigole No, it doesn’t happen any more. It happened in the past yes.

@Tom-Elliott

I update to version RC-12 (42) this morning. Problem solved!
Thanks a lot!

@Wayne-Workman
Not sure how its working for you. I upgrades 5 different imaging servers and they all have the same problem. The only thing that I change is unassigning the image. I remove the default image, it breaks. I reassign it, it works again. I can replicated this several times with several different hosts. I’d be happy to dig if someone has any idea where it could be happening. We are working around it for now, though.

Thanks!! I will try it as soon as possible.

@Wayne-Workman I’ve been kept busy by my studies and patching the auto updating bug that affected many users (more work is still required to prevent it from happening in the future. The hotfix simply bought us 2 years to fix it).

@demontraven Forgive my sounding rude, but this has no impact on actual functionality. (Sorry I know it’s rude, but I’m just being honest).

That said, for now please run this command:
wget -O /var/www/fog/lib/fog/fogcore.class.php https://raw.githubusercontent.com/FOGProject/fogproject/5726017bed15f89e25fc9ad8fc19ec1b523b4f88/packages/web/lib/fog/fogcore.class.php

This should fix the uptime issue for you.

@Wayne-Workman
Had to run the delete commands one more time after moving to RC11. It’s been okay since then other than needing to reset the encryption data.

@Joe-Schmitt
RC11 has started out well. I did need to rerun the install and reboot the system before the client updater started working. The GUI remains responsive even after all the clients start up in the morning. After a few days I may try shortening the client communication period from 900 so the snapins run more timely.