@Junkhacker @Quazz Thank you both ! I did try re-installing FOG on one server and it worked. Then I tried just restarting another server and that worked too. I then restarted ALL the affected servers and they all worked. Don’t know why the problem occurred, never seen that happen in 10 years so I guess I learned something today and I can sleep well tonight 🙂

@Sebastian-Roth Ours was quite a few firmware updates behind and we weren’t able to jump from our current strait to the newest, but stepping up just one version solved it.

@TreyBentley Ultimately, it will break MUCH more than just ldap. It will break pretty much ALL of fog.

Thanks a lot for letting us know! Feel free to post again if you find this is still not properly working somehow.

I had this issue too
I ran ./installfog.sh -K to fix it
I am running CentOS Linux release 7.2.1511

@Wayne-Workman Yes, force people to set a MySQL root password when installing. But it would still fail if people have MySQL server pre-installed (with empty password)… Other than that I don’t think we have any chance to hook into the auth_socket thing. See if you can find anything related to php and auth_socket

@robertkwild As I posted in the other thread,

“I would recommend that you install the FOG trunk version (1.2.0 trunk a.k.a pre1.3.0) and not 1.2.0 stable if you need support for uefi, gpt, and windows 10 support. https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
You can install the trunk version directly and don’t need to install 1.2.0 stable first. Just go directly to the trunk. Use svn or git to get the installer then launch the installer. For Centos FOG installs clean without any problems.”

@Wayne-Workman That did the trick. It said something about “file not found” but I know it got its address. I’ll get all the files worked out later. Thank you for your help!!

@Wayne-Workman Just want to update you that for some reason I kept running into the issue, instead I made MySQL services be the first services to boot and I have not ran into the issue since. (just another work around)

Just got mine working with FOG svn destribution. The problem with FOG 1.2.0 is likely the kernel can’t support the hardware. In my case the network card.

In my opinion, we should only worry about the current version of Raspbian.

@Tom-Elliott @ch3i I changed it to my password. Thanks, I was thinking there was something like that, just didn’t know where.

Thanks!

@scheffman said:

Im more of a FreeBSD person, i would love to see fog working for FreeBSD some day.

While I think that it should be possible to do (requirements: PHP 5/6/7, MySql, Apache, FTP, NFS, (DHCP, TFTP)) it will be a hugh effort to get the installer to fully run on a BSD system - package system being very different!

I’d still love to see if it’d work. Are you happy to give it a try? Start by installing the mentioned packages/services on FreeBSD, then checkout fogproject via GIT and copy fogproject/packages/web folder to apache web root. See what you get. Looking forward to hear from you!

@Sebastian-Roth
have not installed fog on 16.04… yet. I will lol.

@MaMu Again, apache error log??

@andy.king While the rules I’ve already stated are absolutely true - FOG maintains a great deal of flexibility.

Have a storage group per location, and put one storage node in each group, and make it the master node.

this way, each site can upload to their local master node - as long as the image they are uploading to is assigned to the storage group for that location.

images can also be shared across groups, from master to master - however - this replication is a one-way highway. For example, say we have group A and group B. Each group has one node and it’s the master of it’s respective group. Say you make an image on B and upload. Then say you share that image with group A. The image will replicate to the A group’s master (and then from that master to any other nodes in group A).

But - if you update that image and it uploads to group A, replication will just delete that image and then re-replicate from group B because group B was the original.

These complications and features would only be of use to you if you even wanted to replicate images. If you don’t care about replication, don’t even worry about it. Also - if your WAN link is that slow, maybe you shouldn’t even use replication with fog, maybe you should just sneaker-net the images, or mail them.

While it took longer than I would have liked, OSX auto updating is now finished (you can blame Yosemite for the delay).

So yer right.

Mounting the shared folder is easy enough, but NFS wants a block device with a file system, which a directory is not.

boo.

Back to an attached .vhd I go.

thank you. this post solved my problem

@alorsung said in TFTP/PXE timeout Linux server to Windows PXE boot:

I just pulled the current version, wanted to see what new features, if any, were added.

well, new features aren’t always the goal. Stability, performance, and bug fixes are the primary goal right now. the developers aren’t really adding any more features to fog trunk. from this point out it’s mostly bug fixes and performance improvements, and making fog handle potential issues and scenarios better.