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

@Wayne-Workman I will give that a shot. Thank you!

OK. Thanks. I guess I will just recreate my original image without LVM. I will probably get rid of the XFS while I am at it since they don’t shrink. BTW, 1.2.0 and 1.3.0 both treat the LVM partition the same.

Again, thanks for the reply.

Upgrading always has the potential to screw some things up, the package handler seems to struggle doing it properly in one go, at least in my experience.

There are some steps to take to get FOG to play nice on Ubuntu 16.04 though, because it removed PHP5 from its repository and made PHP7 the default one.

https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04

I installed FOG again, and same issue happened.

/opt/fog/.fogsettings is nowhere to be found.

Can’t find the proper file to stop apache2.

drwxr-xr-x 8 root root 4096 Aug 21 14:10 …
drwxr-xr-x 2 fog fog 4096 Aug 21 14:10 bin
-rwxr-xr-x 1 fog fog 27695 Jul 20 2014 changelog.txt
drwxr-xr-x 3 fog fog 4096 Aug 21 14:10 FOGCrypt
drwxr-xr-x 4 fog fog 4096 Jul 21 2014 FOG Service
-rwxr-xr-x 1 fog fog 1419 May 28 2014 installation.txt
drwxr-xr-x 2 fog fog 4096 Aug 21 14:10 kernel
drwxr-xr-x 5 fog fog 4096 Jul 21 2014 lib
-rwxr-xr-x 1 fog fog 35147 Feb 12 2008 license.txt
drwxr-xr-x 6 fog fog 4096 Jul 21 2014 packages
drwxr-xr-x 2 fog fog 4096 Aug 21 14:11 rpttmp
drwxr-xr-x 7 fog fog 4096 Jul 21 2014 src
drwxr-xr-x 7 fog fog 4096 Aug 21 14:10 utils ```

This is installation error message: ```

Configuring services.

Setting up and starting MySql…OK

Backing up user reports…OK

Did you leave the mysql password blank during install? (Y/n) n

Please enter your mysql password:

Please re-enter your mysql password:

Setting up and starting Apache Web Server…Failed!
Script done, file is /var/log/foginstall.log ```

Don’t forget that case IS important, /Images2 is not the same as /images

The idea is to mount the /dev/sdb1 partition over a temp directory, move the contents of /images to that temp directory, unmount the temp directory and then mount /dev/sdb1 over /images. That way there is no need to change the FOG settings one bit, its all done in the linux realm.

well,
i tried another way and solved it.
installed grab4dos on the hard drive and set up a menu that will grab and boot thinstation.iso.
captured it as a linux image, and deployed with no problems!

@dwithandelmo Great job, it would be interesting to know why RHEL7 is different then Cento7. But at the end of the day, as long as you have fog up and running with the least amount of extra headache then we’re good.

As for 1.2.0 acting the same way on Centos7 I can kind of expect that too.

@mcgill-eus if you follow the Upgrade to Trunk instructions exactly, you’ll get Release Candidate 6. RC-7 will probably be out sometime today though and I feel it highly important to move to that when it’s out, as it fixes some issues in 6.

@Quazz
OK!!! Houston we have liftoff…

I was able to get this working by completely ignoring mounting the iso at all and instead doing what I had found in another forum with directly using memdisk and the raw iso. My working config for this is as follows

0_1469802843514_upload-365ae328-e013-4ad9-b6cc-2f6183ce8087

So, we found out what it was.

A security camera contractor had damaged the fiber line that the VMWare platform used.

He fixed it Friday morning. I’m guessing he told our network team what happened sometime Friday. After that, everything was fine.