First, I think app armor was blocking the fog update, so I disabled all of apparmor, but it still didn’t work and I got the same error about apparmor in the logs still. So I dug deeper and disabled it further and/or removed it.

Then, it still didn’t work, so I looked at the logs some more. I made sure apache was working and fixed a few things there. I also made sure mysql was working.

I tried a lot of other things, but I think this mysql upgrade with my root user and root password is what was really needed. I had to do the mysql update manually with my own command instead:

sudo mysql_upgrade -u root -p

Then, I re-ran the fog update and it worked. If that doesn’t work for anyone else, let me know and I can give you more details on other things I did to fix it. It is all working now. Thank you! Fog is awesome!

BOTTOM LINE = Follow the errors in the logs. I did sudo journalctl -xe a lot and also tail -n 20 /var/log/mysql/error.log to see what was going on.

@Joe-Schmitt said in Fog client not renaming computers:

OG Client

Hey Joe just want to give a huge thank you for helping me out. This solved the issue!

For future reference if anyone has the same issue. This is what we were doing on our end. We are running Ubuntu 16.04 server with KVM. We have multiple virtual network devices which created multiple mac addresses. In return trying to deploy the same image from one machine to others caused a conflict with FOG which made the client not work on the machines. Following what Joe quoted tom on fixed our issue. In my instance using the first 3 hex pairs in FOG_QUICKREG_PENDING_MAC_FILTER solved the issue and the client is working as it was intended to 🙂

@Tom-Elliott issue with ftp permissions

ftp password was different so i had keep all password same .
and its get resolved

thanks for providing usefull link .

@Tom-Elliott you can close this issue. test Firefox and Chromium, no issues with web interface. I upgraded via trunk and it still works fine.

If you repull and install the latest version of the working-1.3.4 branch you should have the error thrown corrected for now.

Thanks for reporting.

@Wayne-Workman The info he is showing is from the “readme.md” file.

While we are not in “stable” form yet, the readme’s are updated so when I pull in the working-1.3.4 into the master branch I don’t have to remember to edit these files.

You are trying to boot the I.S.O. over the network.

The way I recommend you do this for pxe access in your company is to extract the content of the iso to a folder of your choosing then give proper access to the folder for the fog server using the exports file.

examples can be provided if im understanding what your trying to do?

@george1421 @Wayne-Workman
Hey everyone, sorry about not getting back till now. been a hectic few days. I will be glad to help test this as I am always glad to help this project. It’s been good to me over the years. Always useful, helpful, and just simply powerful. Will report back my success/failures.

I’m solving this thread as 1.3.2 apparently fixed the issues that was seen for this thread to have been started.

Now I don’t think anything was wrong, but the installation was started with specifying the php version causing the rest of the system to try to use that versioning. This made it try install incompatible packages on 16.04.

@Tom-Elliott
Thank you for details.

Chakri

You have to path to the executable or include PATH in the crontab itself.

so if you ran command -v grsync it would give you the full path, you’d use this full path instead of just grsync. Or you could just stick the path at the top of the crontab file. echo $PATH and then take the output and put it into line 1 of the crontab as a variable like PATH="put the path output here"

Read through this, they may make better sense than me. Plus I’m tired. http://stackoverflow.com/questions/2388087/how-to-get-cron-to-call-in-the-correct-paths

@elembke Then it was bad RAM, or RAM that needed to be reseated. This is not so uncommon in older systems that have seen a lot of use.

@Tom-Elliott Working again as of rc 31. Thank you!!!

George is correct in what he’s said here. If this is a simple isolated network with one switch, two clients, and a fog server - then the FOG server just isn’t running DHCP as it should be. You can check if the service is running or not with service dhcpd status and you can try to start it with service dhcpd start on Ubuntu 14. Your configuration file will be at /etc/dhcpd/dhcpd.conf If you told the FOG installer to do DHCP, the fog installer would have built this file for you and configured DHCP too, and enabled it and started it as well. I can test that this is working properly on Ubuntu when I have some time. I can say that it works just fine with CentOS 7, I’ve not tried DHCP via FOG on the other major distributions in a few months but I don’t think any of that code has changed much.

@pavon87 said in Database migration and database in external host:

I have less tan 15 clients, I can do it manually

My comments would be the same with only 15 hosts even if you are staying on 1.2.0. You can do a manual copy and paste much faster than messing with database exports and imports. If you had a 100 hosts then I “might” explore the database route first.

@mageta52 But you can. This is Linux, after all, and they do not own CentOS 6. They merely own their product. What is the product?

@linux_4_life Sure this probably doesn’t matter to you at this point, but I managed to fix this one today.

Turns out what I created my user “fog”, I neglected to make it a home directory. Created home directory, problem solved.

@cpast The developers confirmed and fixed the issue and it was done in time to get into the RC15 release. If you have not done much configuration the easiest way to get this fog server back on track is to:

If you have any configurations you want to save make sure you export the settings. Refresh the installer to RC15 (git pull or svn up ) Login to mysql using mysql -u root (provide a password if you gave root a password for mysql) key in drop database fog; (understand when you do this your entire fog configuration will be gone, and then reset to default in step 6. Save what you need saved before you execute this command). Key in exit Run the installer again in the …/bin folder (this will install RC15 and rebuild the fog database)

@dholtz-docbox On Dells, they can be in UEFI mode, but if legacy option ROMs is enabled, that UEFI system will boot from something like undionly.kpxe. But when this happens, it will never properly exit to a GPT disk. I’ve seen this before at work.

Most likely, the answer here is to configure DHCP to hand out only ipxe.efi.

@Wayne-Workman I shall do so

@Sebastian-Roth I will try this in about ten days when we are back in session. Thanks!!