@Artur I may be wrong, but I believe these use the rpcbind system. Is this set to enabled?

Typically, on redhat, there are services that are indirectly running. Meaning when a request comes in the service “hears” it and hands out whatever is needed. So a systemctl -l status tftp dnsmasq will likely be a more accurate thing to be displayed here. I’m going to guess that the ‘inderect’ portion is just a means to tell rpcbind to open the ‘listeners’.

Was there a problem doing or anything or just something you noticed?

Fog can’t help you here, you’re going to have to manually do this.

Best way is to boot both systems with live-boot media, mount both local disks to something like /mnt and then scp the contents of each mounted partition over to the new box.

You’ll have to edit the new box’s /etc/fstab file to mount the partitions as ext4 instead of ext3

No guarantees that will work, but it’ll for sure get the files moved.

As long as whatever partition that has /boot on it is marked as bootable with fdisk then it ought to work.

You can find an installation guide for CentOS 7 here: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

The best practices is always to stay patched.

Keep it updated. If your FOG Server is in a VM, snapshot before OS & FOG Updates.

I say set the fix in logrotate configuration. This is the correct answer and should fix the problems.

As I understand realize resizing a few partitions is difficult? I try explain. If I manually partitioning drive and change default filesystem to ext4 for root, installer CentOS7 changes order of partitions. May be this is bug. But in some cases this feature will be strongly useful.

I have one more question. Trouble with wrong UUID deployed swap partition is not solved?

did a clean install of Ubuntu 16.04 with newest latest trunk, installed with

sudo -i git clone https://github.com/FOGProject/fogproject.git /root/fogproject cd /root/fogproject git checkout dev-branch cd bin php_ver='7.0' php_verAdds='-7.0' ./installfog.sh -y

so far it works fine
hopefully I can hosts and images from previous fog server

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.