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

@Wayne-Workman

Sure,

I follow the steps in the wiki for the most part, except for the ipxescript I use:

#!ipxe ifclose ifopen && goto bootme || goto netstart :netstart dhcp || shell ifopen || reboot :netboot chain tftp://192.168.1.20/default.ipxe || goto shell

Where of course 192.168.1.20 is replaced with your FOG IP.

But, reading back over the wiki the section labeled Custom ipxe script has a way that bypasses default.ipxe entirely.

@Fritch94 I ran into this exact problem after upgrading FOG to the latest svn. It took me a while to track it down, but this solution worked:

https://forums.fogproject.org/topic/3433/unable-to-upload-first-image/5

It was a suggestion Tom made a while ago to another user with similar issues. Replacing pxelinux.0 with a sym-link to ipxe.kpxe did the trick for me. Hopefully it will work in your case.

Fog is a multitude of packages, but those packages have their own controllers. These controllers are designed in such a way that they handle their own startup and shutdown. Of course you can also start or shutdown or restart them as you see fit as well. The simplest way to shutdown is to type the command:
sudo poweroff or sudo shutdown -P now

To restart type:
sudo restart or sudo shutdown -r now

does that computer have 32 gigs of ram, by chance?
by default, i believe windows creates a pagefile equal in size to the amount of ram in the computer.
btw, fog automatically deletes the pagefile and hibernate files before uploading the image to the server, since they will automatically be recreated and they consume a lot of wasted space.

@Kiweegie said:

Thanks Tom,

I did move it myself. Uploading a new image ended with the same result though. I’m happy to continue manually moving from /images/dev/macaddress to /images/imagename if necessary just wondered if this was down to something I’d done wrong…

regards, Kiweegie.

The only reason that FOG wouldn’t move it itself would be due to FTP credentials…

Knowing now what credentials are set on the master storage node, try to connect via CLI using FTP with those credentials you have set. If it doesn’t work, there’s your problem.

i would add a note that it’s only specific versions of Ubuntu

if you’re still having issues with the “vista” setting, your best bet would be to upgrade to a trunk version of fog where it’s already fixed.