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!!

This makes a lot of sense. I have seen the FOG Client referenced numerous times and thought it to be the web portal this whole time! Thanks for pointing me in this direction though! This is exactly what I wanted, before I went and did a whole bunch of unnecessary work, heh.

-Dustin

I’m confident the installer doesn’t touch iptables or firewalld. The plainrouter and router and other stuff in .fogsettings is only for configuring DHCP. I think that DHCP is messed up.

If you modify /opt/fog/.fogsettings and change these fields:

dodhcp='Y' bldhcp='1'

To:

dodhcp='N' bldhcp='0'

Then the FOG installer will never again touch the DHCP configuration or DHCP service. Then you can configure /etc/dhcp/dhcpd.conf the way it needs to be for your setup. Feel free to post this file to get help with configuring it if you need.

Very cool, thanks! I set the image type back to Single Disk - Resizable and everything is kicking off like I would expect now.

-Dustin

Understood - I felt I should have done that as well; my mistake.

That said, I have resolved the issue. The issue was addressed by updating the swap drive’s UUID. I raised this question before, how the swap drive does not correctly re-assign its UUID upon deploying an existing image. I had to manually re-assign this to get the image capture to work correctly. Moving forward, the swap drive’s UUID needs to be set as a part of the post-imaging process. Otherwise, subsequent image captures will fail, it appears, from my experience so far.

Nonetheless, thank you for being so attentive - all of you. You guys are seriously the most enjoyable group of dev’s I have had the pleasure of asking questions.

-Dustin

@Tom-Elliott
Ok, this thread is solved. After I deleted everything I was able to login. Thanks again guys.

@Quazz thanks

@Wayne-Workman you might want to use systemctl -l status mariadb as it will give more direct errors to what caused it to die to begin with.

Your load average is 126, and all I see are apache2 processes in top. We need to dig in deep and figure out what’s happening, I can help via Join.Me when you have time.

For starters - you can restart apache with service apache2 restart