Here is an update on this issue for those that may find the same issue.

I added the following lines to the /etc/bashrc profile script at the very bottom.

export http_proxy=http://<proxy_ip>:<proxy_port>
export https_proxy=http://<proxy_ip>:<proxy_port>

saved the file then logged out and back in. After I did that the installer script downloaded the FOGService.msi file without error and the kernel and init.xz files existed when the installer was done.

Just to restate the issue, if you have your FOG server behind a proxy server you must update the bashrc file with your proxy server settings AND wgetrc with the proxy server settings, because both commands are used to download files in FOG.

Ok looking a bit deeper into this, the link you referred to the diff file uses wget to get the kernel images and init.xz from sourceforge. Looking into the actual file commom/functions.sh it uses curl to get the files. In my install my fog server sits behind a proxy server. I’ve got the command in place in /etc/wgetrc to support proxy downloads. I’m going to have to look into what can be done for curl behind a proxy. But as a side note, I’m suspecting that’s also the reason for FOGService.msi failing to download every time during the install process.

Sorry just so I’m clear (my apologies I had several different comments in my post):

When I run the install from the local svn location that will remove the bzImage and init.xz files. But then redownload them during the update process?

If that is true, then something is broken. I can manually install the bzImages from inside the fog management console, but I have to get the init.xz images from sourceforge via wget. If this is SOP then I’m OK with it, but one would think the update/installer would put all of the bits in place for me.

After running the update from 4866 to 4876 both the boot kernels (bzImage) and init.xz have been removed. Is this an expected behavior of the upgrade process?

Running through the built in kernel upgrade process returned these two errors in the apache error log:
[Wed Oct 07 07:40:46 2015] [error] [client 192.168.1.167] PHP Warning: http_build_query(): Parameter 1 expected to be Array or Object. Incorrect value given in /var/www/html/fog/lib/fog/FOGURLRequests.class.php on line 60, referer: http://192.168.1.53/fog/management/index.php?node=about&sub=kernel&install=1&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMi4yLjMy
[Wed Oct 07 07:41:07 2015] [error] [client 192.168.1.167] PHP Warning: http_build_query(): Parameter 1 expected to be Array or Object. Incorrect value given in /var/www/html/fog/lib/fog/FOGURLRequests.class.php on line 60, referer: http://192.168.1.53/fog/management/index.php?node=about&sub=kernel&install=1&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMi4yLjY0

After the kernel upgrade the init.xz file was still missing. Upon the next reboot of the client this error was thrown in the apache error log:

[Wed Oct 07 07:43:07 2015] [error] [client 192.168.1.199] File does not exist: /var/www/html/fog/service/ipxe/init.xz

I can fix the missing bzImage and init.xz but is this expected behavior or should the upgrade . Neither bzImage or init.xz appear in the svn trunk.

I can also confirm that version 4866 resolved the issue.

In reviewing the Apache error logs I did see this error being generated when I try to access host information.

[Tue Oct 06 15:45:37 2015] [error] [client 192.168.1.167] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/pages/HostManagementPage.class.php on line 403, referer: http://192.168.1.53/fog/management/index.php?node=host&sub=list

It only appears to be a problem with the host general pane, the other ones work as intended.

FWIW I’m also seeing the same thing. No host management details. I upgraded this AM from 4388 to 4850 and now 4860 today. I rolled back the VM to repeat the upgrade steps with the same results.

Executing the sql command to disable the location plug has no impact on the host management details. I did confirm that the bit was changed to 0. I did reboot the server just to ensure the value wasn’t cached anywhere. Upon login I did notice the location icon is still visible in the console.

In my install I only have the location and LDAP services installed.

I have the vm restored to the previous state and I’m able to login with version 4388 on the cloud. This vm has the access control, ldap and location plugins installed.

On the vm that was cloned, I renamed the folders for access control and ldap then restarted the httpd service. On this vm I’m now able to reach the schema update page. After the schema update was updated the version number on the cloud is 4652.

After I was able to login I removed the plugins access control and ldap and restarted httpd. I was able to login OK, so I added back in ldap, access control and restarted http. This time on the login page I noticed (as with version 4388) the estimated fog sites and latest version values weren’t displayed only the rotating circles. I was able to login OK. I then removed the ldap plugin again. At the login page the estimated sites just showed the rotating circles. And finally I logged in and removed the access control plugin. Now at the login page I get the values of 4199 and version 1.2.0 (?? since I though this was 1.3.0). I added back in the ldap plugin without issue.

So you guess that it was the access control modules is spot on. I’ll wait a day or two so we can get the images deployed on the production FOG server then attempt to upgrade that one again.

Yes the access control plugin is installed but I haven’t used it/changed from the default settings yet.

Is there a way to externally disable this plugin? I’m unable to get the management interface to display at all. Every time I call up the management interface it tries to access the schema update and I end up with the blank page.

Thank you for responding Tom. I just ran the svn update and attempted to reinstall the update. I got the same blank page for schema update and error message in the apache error log. So no luck here.

Right now we are unable to deploy new client machines. So after cloning this vm, I’m going to roll back the image to before the attempted upgrade. I did find the issue which was the trigger that caused me to attempt the upgrade. After I get the vm restored and fix the other issue, we’re all good.

If you want me to test anything additional I’ll keep the broken vm for a while.

Bump

Any idea on how we can solve this issue? We are unable to login or even interface with the software from the FOG PXE menus since they interact with PHP. We get this error in the apache error log if we try to interact with the web interface or via the PXE menus:

PHP Fatal error: Call to a member function get() on boolean in /var/www/html/fog/lib/plugins/accesscontrol/hooks/RemoveUpload.hook.php on line 28

Sorry I was short on the details.
Centos 6.7
While I don’t have the SVN number I upgraded from, the fog login console graphic had 4388 in the graphic. I can estimate (pretty close) the last svn update was done on 11-Aug-15

I just updated to the latest svn version 3981 too, in an attempt to resolve a fog pxe boot issue. And I’m also getting the same blank screen when attempting to update the schema.

Looking in the http error log I see the following error:
PHP Fatal error: Call to a member function get() on boolean in /var/www/html/fog/lib/plugins/accesscontrol/hooks/RemoveUpload.hook.php on line 28