@vincityhn1 said:

When we try send a image stored in node A, the Fog Server search this image in both nodes A and B.

What exactly do you mean by “try send a image”? Send where? Pushing the image to the client? And what do you mean by “Fog Server search this image…”? Can you be more specific on this. Maybe take a picture of what you see on screen and post here.

@fogofwar said in "Operation not supported" tftpboot failing - please help:

Only one problem now that we got past that I am getting this error about “No configuration method succeeded” but only on a VM. I will have to look at that next.

This is only on reboot I am fairly sure! Shut down the VM completely, bring it up again and PXE boot will work nicely. This is a known bug in virtualbox.

@jherron The information is split in two different tables. Host information and MAC information. So you need to commands to clean that host’s information from the database:

mysql> DELETE FROM hostMAC WHERE hmHostID = 1272; ... mysql> DELETE FROM hosts WHERE hostID = 1272; ...

But I still wonder why we only see one entry while FOG seems to find duplicates. Would you be keen enough to add some more error output to the PHP code so we see which MAC it sees as duplicated? If yes, I should be able to help you with the code. Let me know.

@kwilson7392 said in FOG Capture Task keeps rebooting:

This is my first capture task…

So my guess is you might still be thinking in different concepts. Ghost for example did some modification to the boot loader on disk and joined into the task when rebooted from disk. But FOG is different. It’s based on PXE booting the client. If a job is scheduled then the PXE loader will bring up the FOS system to do that task on your machine and if there is no task it will chainload from disk to boot the OS.

Have you setup your machine to PXE boot?

I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”

I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.

@Jim-Holcomb said in http 500 error:

uncaught error: call to a member function lastInsertID()

This is usually due to a database connection issue. Please read through this: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

problem solved!
In fog settings >> Ad default OR I have filled in the fields in small as an example:
or = xxxx, dc = yyy, dc = zzz
Thank you all

@gabbas said in Snapin not working as a Batch file xcopy:

everyone has read and execute permission to this folder

Is it really everyone as in anonymous without authentication or is it all users/group members of your organization? I ask because the FOG client is running as service and won’t have the same auth tokens as if you run the script as user.

Hi,
I tried the password fix and it didn’t help.
Did you manage to overcome this issue?

The Fog Client and Fog Server are up to date and database is fixed.

Now the Fog Server working properly now.

Thank You for your help.

@Cire3 Hey I’m glad you have it worked out. You found one of the gotchas with naming (No special characters as the first character in the names).

@Wayne-Workman thanks i was able to figure it out, and yes im an old fog user and installer. I had to changed the fogstorage mysqlpassword on my storage node on the .fogsettings (/opt/fog/.fogsettings) Once i changed it to the one provided by the Fog Server everything worked.

@matijn Don’t edit core files for this. (they’ll be overwritten at next update)

Instead update your /opt/fog/.fogsettings file with the credentials and rerun the fog install script.

Ok.
It seems i decided to enter no root password for mysql while running the installation, after I tried to configure a less secure root password.

After setting a very very strong password on mysql root account (phpmyadmin).
You have to manually edit:

sudo nano /var/www/fog/lib/fog/Config.class.php

In my case, for Ubuntu 18.04.1 LTS
sudo nano /var/www/html/fog/lib/fog/Config.class.php

private static function _dbSettings()
enter credentials.

@Sebastian-Roth & @george1421
Thank you for your help. Updated the kernel and inits the way you described it. Now the capture works.
Installed 1.5.4 on august 9th, as far as I can see.

@kratkale Read through this topic, possibly you have many client’s talking to the FOG server (and the DB for that reason) which might cap the connections.

About the printers, I might ask you to open new topics so we don’t loose track of different issues in one thread.

@ablohowiak Maybe play with the image settings (e.g. Image Type and Image Manager) might make those images work again. As we don’t know your settings it’s just a wild guess. But if the images worked on your 1.4.4 server they should work on 1.5.4 just as well if you get the image settings right.

@george1421 It worked the policy was disable on each scope and the secure boot on enable, just had to activate the policy and and disable secure boot

@mxc In the second video I don’t see the client PXE booting at all?!? Maybe I get you wrong?

In the first video it looks like a legacy BIOS PXE boot (not UEFI). Try different boot exit style settings for BIOS (and maybe UEFI just in case)…