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)…

Please resolved this post. we went virtual machine route to capture image and it worked.

Thank you for support.

@Wayne-Workman the 6 first of the mac are the same and fog could see somes of theese MAC.

i’m still looking for BUT you’re right @Sebastian-Roth , the forticlient have an integrated FW, maybe the problem… today i will look if I can turn off the FW part and you say after

@afaure Please provide more information. On the FOG server run the following commands and post the full output here: df -h, lsblk, showmount -s

@Cire3 said in Can't see Images in menu after manually uploading.:

The compression scale also must match huh ?

Sorry, I didn’t mean the compression scale but the compression format…

Thanks for all the help! things seem to be back in order!

In fact, i must be wrong.
What is the “*” at the end of the name of the server in the “storage node disk usage”.
It is the Master Node or the current server ?

@Sebastian-Roth I think I found it - I had to add the snapin to the group!

@andy-king said in Fedora 21 version 1.2 to 1.5.4 version update fails:

I would like to oput the large image files on an iscsi device do you think that is possible?

Sure, mount that iSCSI device on your FOG server, move the existing directory structure in /images to the mounted iSCSI device (unmount the old disk/partition in case it was seperate), remount the iSCSI under /images and off you go without much headache.

@Sebastian-Roth

FOG Configuration
FOG Version Information
Running Version: 8179

Kernel Versions
DefaultMember
bzImage Version: 4.6.2
bzImage32 Version: 4.6.2

@Raymond-Bell @Tom-Elliott You had me update to the working-1.6 branch and it fixed the issue in that it would go the next node even if it says there is a non-match file on the first node. The issue of it constantly thinking image files (usually the largest .img) don’t match still has not been fixed. I have been too busy with other issues in our school district to continue testing at the moment though and have been manually updating images using rsync if we ever upload a new version, seeing as how it doesn’t seem to delete non-matching files and /or thinks matching files don’t match. I am able to replicate the issue on VM’s at home and with multiple test machines and our servers at work. However until the work orders slow down I am unable to keep digging into the issue and the rsync has been working as a temporary solution.

@Sebastian-Roth I will give the doc a read through, but I believe it was more or less set up by IT. I plugged in my system to the network by ethernet through an VOIP phone, and gave them the system’s MAC address and then they assigned the box an IP. I do not recall messing with settings other than the systems proxy settings when getting on the network.

@jlad00 Have you searched the forum yet. There is a ton of threads about Surface devices having those kind of an issue. I am fairly sure you will find the right threads.

@Sebastian-Roth So after taking your advice on the multiple DHCP servers, I went and checked for any possible Rogue DHCP servers using Wireshark, and I found a range that is not apart of our usual subnet, was offering and broadcasting DHCP. So the issue was rogue DHCP.

@Sebastian-Roth Thanks that did the trick.