@Wayne-Workman @Tom-Elliott Solved the problem. Somehow curl had a problem with me being behind a proxy, no idea why though, never had this problem before. As a result, bzimage, bzimage32, init.xz and init_32.xz were not downloaded correctly. I solved this problem by using wget to manually download those files (the download links are in /lib/common/functions.sh).

Also another problem in /lib/common/functions.sh: I was not able to add the repository for php5-5.6, so I had to comment out those lines. In my case this is not a problem, as I’m now using Ubuntu 15.04, which already has php 5.6 preinstalled (at least if you dist-upgrade and update).

Thanks again for the very fast help. 🙂

@Junkhacker Technically yes.

Problem totally solved.

Imaging client work now.

@Jordonlovik With the exception of the /etc/exports file and creating the /dev folder and the .mntcheck files

If the storage that you add is local, You not only add the new directory to the Storage Management area as a new storage node, you also have to add entries to /etc/exports and create the /dev folder and the .mntcheck files

4696 should fix this for you now.

Thanks for reporting.

@sarge_212 What version?

this problem is believed to be resolved now, thank you for the bug report.

@lebrun78 There are no files to change.

The advanced menu is purely a GUI item. From the GUI goto FOG Configuration Page->PXE Settings->Advanced Menu

@Wayne-Workman I have. I can open into ftp on any device to the one node but not the node or server. As far as I can tell all of the config files match.

@Tom-Elliott said:

Can you try reupdating your kernels/ and/or re-running the install if you’re running dev version? I’ve updated the kernels to simply remove the qmi_wwan drivers from the mix. From my reading this should essentially keep the GOBI card from loading with the FOG inits.

Hi
same problem for me
using the kernel 4.2.0 of September 14, 2015 doesnt change
When i’m doing a quick registration and inventory (or quick image) it loops on starting wwan0 interface
Any ideas ?

What has changed in your environment between now and the last time you were able to image? Server change? DHCP change? New firewall? Perhaps it’s an IP Conflict? Did the V-LAN assigned to the fog server change?

Have you tried a different host? Are all hosts doing this?

And the final question is, do you have a reason why you are still using .32 ?

Alright, I got this figured out. Everything was configured correctly on the FOG end, it ended up being a setting on the Synology NAS that I needed to change. I had to enable SFTP. Once that was enabled, everything began working correctly.

@giejo63 In other words, try to reinstall.

I’d really highly recommend using the -y argument so it auto-updates the DB for you. like this:

./installfog.sh -y

@Stefan-400 said:

Oke, how can i do this without damaging the fog server?
Thank you for your help! 👍

Look through this: https://wiki.fogproject.org/wiki/index.php/Modifying_existing_DHCP_server_to_work_with_FOG

Ok bit the bullet and restored a backup of the database seems to have fixed the issue I will keep an eye on how it behaves under load today.

@kman1232 said:

@Tom-Elliott You asked if we would upgrade to Trunk. I haven’t considered it since reading in the wiki https://wiki.fogproject.org/wiki/index.php/FOGUserGuide under the Upgrade to Trunk section states with yellow highlight that “Trunk installs are almost always buggy” If this is no longer the case I would advise making an edit to this section.

I wouldn’t advise it at this particular moment. the latest is in question.

However, an older rev like 4571 seems fine to me. that’s what I’m using. I’d highly recommend virtualizing your FOG server if you’re going to use trunk, and you have to keep up on your DB and image backups and snapshots and server backups.

I was able to get apache to install, now running into issues with mysql failing on the install. Will try installing that manually now. Thank you.

@fabritrento Try apt-get autoremove

@Jamie-Read Some machines Firmware are better than others, some are worse than others.

Some machines will try for 5 or 8 seconds and then give up and boot to the next option in the boot priority.

Others will just sit there and stare at the wall for 15 minutes trying to network boot.

We have no control over how manufacturer firmware acts - but if you’re really skilled and super motivated - you can probably flash the ROMs for the NIC chipset to reduce the wait period.

OR…

You can run dual TFTP servers, or chain one “always on” and simple TFTP server to the primary FOG server. Others here in the forums have accomplished setups like this in the past to reduce their downtime and prevent precisely what you’re describing.

If you’re running dnsmasq ProxyDHCP - it’s possible to ping the FOG sever every minute via a script with Cron-Tab, and if a response isn’t recieved, to simply swap out ProxyDHCP’s configuration file with another one that points to a different FOG server, and then restart the service. This can also be done with Linux DHCP quite easily. However I’m afraid there are no easy ways (or perhaps any way) to manipulate Windows DHCP in such a manner… this is where you will find that Linux excels beyond what Windows is capable of.

Just let us know what you’re interested in and we will try to help - and also feel free to search the forums and other sites to try to figure it out yourself as well, you’ll learn more if you do it on your own.

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.