@Jaymes-Driver

Late response, I know, but you’re right. I think the Ubuntu updated itself and reverted a change I had made with the link below. I had to go back in and blank out the SQL password again:

Is this Ubuntu 16.04? See here: https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04#MySQL_password_behavior

@george1421
thanks for pointing me in the right direction. I reran the installer with wifi internet and static ethernet and dhcp is working now. I think during the initial install i was trying to use two connection profiles on ethernet, rather than utlizing wifi card for internet to complete install and ethernet for fog only.

The following fixed it:

https://forums.fogproject.org/topic/7135/boot-pxe-issue-check-if-mntcheck-exist/2

@Rama This thread is fairly old, and the OP is probably not going to respond. Can you please create a new thread with all the details, fog version, how you are doing it, etc.

@Amerhb Is the fog server doing dhcp or getting dhcp? Did you change the fog server’s IP address? We need a lot more information, what you’ve stated doesn’t have enough information for us to even know what the problem category is.

@grant1842 said in Your database connection appears to be invalid.:

I had to re run the installer as well as remake my dnsmasq 2.76. … but my dnsmasq reverted back to 2.75 which was causing the boot file to not be received correctly.

This is only speculation, but I’m guessing that the linux distro you use updated dnsmasq from (2.72 or 2.73) to 2.75, thus overwriting your compiled 2.76. As wayne said the package manager only knows about what it does. Hopefully the next time it happens is when your distribution updates to 2.76 or newer. Then it won’t matter at all.

On the plus side you were able to discover and fix the problem pretty quickly. So good job there.

@george1421 It’s ubuntu, so ps aux | grep apache2 but yeah he probably got slammed by Canonical’s nasty automatic MySQL update.

@fredlwal that’s basically what a reinstall does.

[Sat Apr 29 00:00:34.054499 2017] [:error] [pid 1136] [client 192.168.67.11:61226] PHP Fatal error: Uncaught exception ‘UnexpectedValueException’ with message ‘RecursiveDirectoryIterator::__construct(/var/www/html/fog/service/ipxe/iso/asus/EFI/Microsoft): failed to open dir: Permission denied’ in /var/www/fog/commons/init.php:125\nStack trace:\n#0 [internal function]: RecursiveDirectoryIterator->__construct(‘/var/www/html/f…’, 4096)\n#1 [internal function]: RecursiveDirectoryIterator->getChildren()\n#2 [internal function]: FilterIterator->next()\n#3 /var/www/fog/commons/init.php(125): iterator_to_array(Object(RegexIterator), true)\n#4 /var/www/fog/commons/init.php(344): Initiator->__construct()\n#5 /var/www/fog/commons/base.inc.php(48): Initiator::startInit()\n#6 /var/www/fog/management/index.php(22): require(‘/var/www/fog/co…’)\n#7 {main}\n thrown in /var/www/fog/commons/init.php on line 125

You were right. They were just permission problems. Sorry for the silly question.

“sudo chmod -R folder/” , for repair.

Thanks for the fast response.

@isaac Thank you for adding clarity to how you fixed it. You have a unique setup and I’m sure someone want to do the same thing in the future. Your guidance in this thread will surely help someone else.

Marking as solved.

@x23piracy said in Issue Capturing HP ELite Desk 800G3 on version 6213:

@george1421 Beer 😉

Too much Beer == very sloppy code. 😉

Make this bad boy solved LOL

Sorry, this took so long to post, but I have found the fix. The issue was that we had storm-control broadcast, storm-control unicast, and storm-control multicast levels set to low on our core switch (layer 3 switch where the routing happens). I removed these and all is well. I appreciate all the help you all supplied.

@Scott-Adams said in Computers not joining domain after password change:

I had thought about that as a work around, didn’t think that would be the actual solution though. Thanks @Wayne-Workman

@Scott-Adams You’d need to post the fog.log from a problematic host.

@greenfog said in New FOG server with different storage size:

Is there any way for me to import the database and maybe manually edit the fog.sql to specify the new hard drive size?

I think you’re off track here - fog doesn’t care what the disk size is that it’s installed on. That value is dynamically calculated, it’s not static. Go ahead and do your DB Import - you will need to change some fields in the web GUI after you do this, all of them are laid out in this article: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG They concern updating passwords and IP addresses from old to new.

A VM or physical server (or AWS instance) is the correct answer.

FOG wraps itself so tightly into the OS, it really should be an appliance. But since we are all volunteers and FOG is totally open source and nobody who works on fog actually has any money or time to do anything else besides what we’ve been doing - we just have a really elaborate installation script that we work hard to support.

@george1421 thanks George, after installing the hot fixes I was able to deploy the image. Thanks for your help everyone!

@pederskz I marked it for you. Glad you have it going now.

Yes hostname is correct 🙂
I just have to test my snapin deployment

Ok so I have the same problem than my old server, some snapins failed to deploy due to “hash does not match”
This is a known issue for me, some snapins, I don’t know why simply doesn’t download correctly (my .exe is 1KB instead of 75203KB in server)

It seems something wrong in the settings, 3 snapins download at 1KB

BTW thanks Joe and Tom for you help, I’ll try to find out why my snapins doesn’t download correctly (all are 1ko in C:\Program Files (x86)\FOG\tmp with hash does not match in fog.log)

@richard.cervelle I would suggest you try it. Here’s an article on it, includes a video explaining how to set it up at a basic level and how it works: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin