Correct.

Group reset encryption data added.

It is fixed at 4250.

The technician administering this particular FOG server has reported that the latest revision has resolved the issue.

Thank you @Developers !

I was able to fix the issue. It was looking for the file in http://10.105.2.253//service/ipxe/boot.php instead of http://10.105.2.253/fog/service/ipxe.boot.php. Fog was somehow stripped out in default.ipxe.

@Tom-Elliott Testing now.

As I’m setting the password variables in .fogsettings with single quotes as opposed to double quotes, this should be resolved even with $2 or other funny symbols that may have a different meaning in bash/csh/ksh/zsh/tsh/etc… shells. Hopefully this helps. I’m just solving for now. If you see the issue again, please just let us know.

I don’t know what you mean timeout?

Can you provide some screenshots?

My other guess is the webroot issue. Maybe try rerunning the install with, after updating to latest pull please:
./installfog.sh -y -D /var/www/html

The webroot issue should be fixed in SVN/GIT so I’ve solved this thread.

TO ALL: If you’re still having the webroot issue, and you’re on Ubuntu >= 14.??, try running the installer with:

If you access with http://IPADDRESS/fog
./installfog.sh -y -W /var/www/html/ -D fog/

If you intend to access with out the fog trailing:
./installfog.sh -y -W /var/www/html/fog/

I’m solving this. I added the very code to remove duplicates to the schema. So it is still possible, in the future, to have this same issue. However, for the time being this should be fixed.

@Tom-Elliott Ya that did the job. Tx for the info!

@el-psycho the new client can only be used with the development versions of fog. This is because the new client was coded along side the development versions. And believe me there are a lot of changes to make it work. The compatibility of legacy and new clients is still present, but 1.2.0 will NOT work with the new client.

@Wolfbane8653 said:

@Tom Elliott:

[fogproject:dev-branch] 1 new commit by Tom Elliott:
447a131: Update ipxe files to latest. Maybe fix escape sequences particularly frustrating to printers and file names. - Tom Elliott

Tom’s latest update has updated your ipxe files. If you use the kkpxe or any of the other pxe files please try testing around the other pxe files to see if this helps.

If not then we will have to report your Machine hardware (Make/Model) so the ipxe team can look into it.

Fixed.

@Wayne-Workman I actually created a fog database from MySQL Workbench with no problem, however, I didn’t realize my account doesn’t have a MySQL password, but the mysql and root accounts do and fog was using one of those! So, that’s why there was a permissions problem. I installed the trunk and built it and it worked! I did however, have to comment out the configureMySql call because it wasn’t defined in the trunk. I guess someone removed its definition so it failed because the installation.sh script still called it!
"I’m so happy… " I can now go on with my PXE thing and proceed with the software phase of my new server.

I have a working fog in my environment via my mods. The biggest part of the problem is clearly our switched network behaving badly so I don’t think there’s any in fog that should be changed cover that brokenness. I’ll be happier of course if our network folks can figure out why it takes so long.

I do wish udhcpc had an option to “try one more time” if it failed to get a lease but it appears to be that it’s either one pass through or repeated passes until you succeed. I don’t really feel like it’s a good idea to default fog to “keep trying dhcp forever” mode. And even if fog could be set to dhcp for two or three attempted leases it’s still a bad solution - it would make things “work” in my case but at the cost of several extra minutes on the boot time and really the problem is my network is broken. That piece is just a bit out of my ability to fix while hacking fog to workaround the issue is possible - apparently. Learned a bunch figuring it out. 🙂

If the code is useful then by all means use it, that’s why I posted it.

@Lee-Rowlett said:

sourceforge site is down atm (SVN) and is out of our control however rest assured git is the latest version, if unsure just run git pull.

the version detail will be back in the gui if you install SVN Version, when it’s back up.

“SF.net Operations
‏@sfnet_ops
#SourceForge down due to storage platform bug, working 24x7 on recovery and data validation, service restoral. Slashdot restored”

I absolutely love how they keep changing the name of what’s the issue… 😄 Yesterday it was “instability” and now it’s a “bug”. lol. SF people, please fix your issue so I can continue with my FOG Updates, Thank you.

@Tom-Elliott Gotcha. We’re just imaging like crazy and that is creating a lot of these errors which filled about 12GB of logspace up. I’ve adjusted my logrotation (which is probably the better answer anyways).

This ran in mysql will remove the hosts from the group. All you have to do is swap in your host and group names (leave the quotes).

I also advise always backing up before you make any mysql changes.

DELETE FROM groupMembers WHERE gmHostID = (SELECT hostId FROM hosts WHERE hostName="HOSTNAME") AND gmGroupID = (SELECT groupID FROM groups WHERE groupName="GROUPNAME");

This is what I meant.

Since I updated on Jul 14th it only shows the uploaded images, but it showed the downloaded images before (see Jul 13th).

And I can tell you that we have done a a few downloads these days.Captura.PNG

@netrunner You need to change name on your 67 DHCP option.