@sgoodman Is the server set to Delayed auto?

@Gilberto-Ferraz
Try this running this PowerShell script as a snapin. What it does is moves the first non-windows boot selection to the top, in your case it will move “IP4 Intel Ethernet Connection I217-LM” to the top of the boot order.

Works for me…

Thanks, I should have searched a little harder.

How would I go about changing the colors of the graphs?

as you can see above they are all pretty much all shades of blue.

I had a similar problem but I found that it was my max connections.

mysql -e"show status like '%used_connections%'"
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 224   |
+----------------------+-------+

mysql -e"SHOW VARIABLES LIKE '%max_connections%'"
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| extra_max_connections | 1     |
| max_connections       | 1000  |
+-----------------------+-------+

Mariadb max_connections default Value: 151
I increased mine to 1000 and my DB connection issues seem to have gone away.

I know this isn’t a very good fix but It works for me…
Windows boot manager always gets added to the top of the list in boot order, I found this powershell script here:

This PowerShell script moves the first non windows entry to the top of the list.

# This script looks for the first non-Windows Boot Manager entry in the UEFI/GPT boot order and moves it to the top
# For preventing newly installed Windows from hijacking the top boot order spot on my UEFI/GPT image testing VMs
# by mmseng
# https://github.com/mmseng/bcdedit-revert-uefi-gpt-boot-order

# Notes:
# - There's very little point in using this on regular production machines being deployed. Its main use is for machines being repeatedly imaged, or might be useful for lab machines.
# - AFAICT bcdedit provideds no way to pull the friendly names of the devices in the overall UEFI boot order list. Therefore, this script only moves the first entry it identifies in the list which is NOT "{bootmgr}" (a.k.a. "Windows Boot Manager"). It's up to the user to make sure the boot order will exist in a state where the desired result is achieved.
# - In my case, my test UEFI VMs initially have the boot order of 1) "EFI Network", 2) whatever else. When Windows is installed with GPT partitioning, it changes the boot order to 1) "Windows Boot Manager", 2) "EFI Network", 3) whatever else. In that state, this script can be used to change the boot order to 1) "EFI Network", 2) "Windows Boot Manager", 3) whatever else.
# - This functionality relies on the completely undocumented feature of bcdedit to modify the "{fwbootmgr}" GPT entry, which contains the overall list of UEFI boot devices.
# - AFAICT bcdedit is really only designed to edit Windows' own "{bootmgr}" entry which represents one of the "boot devices" in the overall UEFI list.
# - Here are some sources:
#   - https://www.cnet.com/forums/discussions/bugged-bcdedit-349276/
#   - https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi
#   - https://www.boyans.net/DownloadVisualBCD.html
#   - https://serverfault.com/questions/813695/how-do-i-stop-windows-10-install-from-modifying-bios-boot-settings
#   - https://serverfault.com/questions/714337/changing-uefi-boot-order-from-windows


# Read current boot order
echo "Reading current boot order..."
$bcdOutput = cmd /c bcdedit /enum "{fwbootmgr}"
echo $bcdOutput

# Kill as many of the stupid characters as possible
echo "Removing extraneous characters from boot order output..."
$bcdOutput = $bcdOutput -replace '\s+',''
$bcdOutput = $bcdOutput -replace '`t',''
$bcdOutput = $bcdOutput -replace '`n',''
$bcdOutput = $bcdOutput -replace '`r',''
$bcdOutput = $bcdOutput.trim()
$bcdOutput = $bcdOutput.trimEnd()
$bcdOutput = $bcdOutput.trimStart()
$bcdOutput = $bcdOutput -replace ' ',''
echo $bcdOutput

# Define a reliable regex to capture the UUIDs of non-Windows Boot Manager devices in the boot order list
# This is difficult because apparently Powershell interprets regex is a fairly non-standard way (.NET regex flavor)
# https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expressions
# Even then, .NET regex testers I used didn't match the behavior of what I got out of various Powershell commands that accept regex strings
# However this seems to work, even though I can't replicate the results in any regex testers
$regex = [regex]'^{([\-a-z0-9]+)+}'
echo "Defined regex as: $regex"

# Save matches
echo "Save strings matching regex..."
$foundMatches = $bcdOutput -match $regex

# Grab first match
# If Windows Boot Manager (a.k.a. "{bootmgr}" was the first in the list, this should be the second
# Which means it was probably the first before Windows hijacked the first spot
# Which means it was probably my "EFI Network" boot device
$secondBootEntry = $foundMatches[0]
echo "First match: $secondBootEntry"

# Move it to the first spot
echo "Running this command:"
echo "cmd /c bcdedit $bcdParams /set `"{fwbootmgr}`" displayorder $secondBootEntry /addfirst"
cmd /c bcdedit $bcdParams /set "{fwbootmgr}" displayorder $secondBootEntry /addfirst```

I noticed that the fog version after the upgrade was not showing:

After I manually changed the fogstorage password in MySQL the versions started populating for the storage nodes that were upgraded but not for the storage nodes that were not upgraded.
is it possible that the upgrade corrupted the fogstorage MySQL password in the database on upgade or was it the mysql dump that was generated by Configuration Save> Export Database in the fog gui?

The more I think about it it would have to be the MySQL dump… I installed fog on a new Centos 8 build and imported the database after installing fog.

snapins are now downloading with the correct file sizes.

Thank you everyone for helping me with this issue!

@Sebastian-Roth
the contents of the file read:

"A valid database connection could not be made"

Here is the access_log:

10.13.100.144 - - [02/Dec/2019:16:38:13 -0500] "GET /fog/management/other/ssl/srvpublic.crt HTTP/1.1" 200 1749 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:13 -0500] "POST /fog/management/index.php?sub=requestClientInfo&authorize&newService HTTP/1.1" 200 326 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:14 -0500] "GET /fog/management/index.php?sub=requestClientInfo&configure&newService&json HTTP/1.1" 200 322 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:14 -0500] "GET /fog/management/index.php?sub=requestClientInfo&mac=00:0C:29:62:EB:A0&newService&json HTTP/1.1" 200 10697 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:14 -0500] "GET /fog/service/getversion.php?clientver&newService&json HTTP/1.1" 200 7 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:15 -0500] "GET /fog/service/getversion.php?newService&json HTTP/1.1" 200 8 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:16 -0500] "GET /fog/service/snapins.checkin.php?taskid=9546&exitcode=-1&mac=00:0C:29:62:EB:A0&newService&json HTTP/1.1" 200 73 "-" "-"
10.13.100.144 - - [02/Dec/2019:16:38:16 -0500] "GET /fog/service/usertracking.report.php?action=login&user=13WIN10-IT%5Cgp1001&mac=00:0C:29:62:EB:A0&newService&json HTTP/1.1" 200 105 "-" "-"```

@EduardoTSeoane said in snapin hash does not match on storage node (1.5.7.55):

@Greg-Plamondon
Have you try to execute the file manually?
Have you compared the size?
Maybe the download is not correct.

After doing some more investigating I found that the file sizes are indeed not the same. I was getting the information 2nd hand. I checked the "C:\Program Files(x86)\FOG\tmp folder for the snapin and it is only 1kb in size.

Sorry for the confusion.


@Sebastian-Roth said in snapin hash does not match on storage node (1.5.7.55):

Get-FileHash

I did as you asked and used Winscp to download the file from the storage node and ran Get-FileHash and CertUtil

@Greg-Plamondon said in snapin hash does not match on storage node (1.5.7.55):

@Sebastian-Roth said in snapin hash does not match on storage node (1.5.7.55):

@Greg-Plamondon When did you upload/update that snapin last? Possibly the FOGSnapinHash service just didn’t update the hash sum in the database yet.

Are alll your nodes using the same FOG version?

the nodes that are working are on Version: 1.5.7.4

Sorry I was wrong on the storage nodes that were not upgraded to 1.5.7.5 working correctly. They all seem to be having the same issue.

If I set the location of the host to the Fogserver instead of the storage node it works as it should. But this is not acceptable as the files are being pulled across the wan.

@Sebastian-Roth said in snapin hash does not match on storage node (1.5.7.55):

@Greg-Plamondon When did you upload/update that snapin last? Possibly the FOGSnapinHash service just didn’t update the hash sum in the database yet.

Are alll your nodes using the same FOG version?

the nodes that are working are on Version: 1.5.7.4

@EduardoTSeoane I can execute the file manually and it installs fine. The file size is a match.

@EduardoTSeoane It is replicated. I even deleted it and waited for it to replicate again.

@Sebastian-Roth said in snapin hash does not match on storage node (1.5.7.55):

Get-FileHash C:\Program Files (x86)\FOG\tmp\TeamViewer-AllSites.sfx.exe

fogsnapinhash.log
[11-26-19 4:43:20 pm]  * Trying Snapin hash for: 01 - MTS-TeamViewer, ID: 129
[11-26-19 4:43:20 pm]  * Getting snapin hash and size for: 01 - MTS-TeamViewer.
[11-26-19 4:43:20 pm]  | Hash: 8de8056083825bd98a731ede61073f59f8d472b957e20e4bcbce103abd05c9d722d37c26c633c2e831e9628fb4fdeca998e719ffd9b16dd0f3c4dd63df2ab0af

[root@10fogserver ~]# sha512sum /opt/fog/snapins/TeamViewer-AllSites.sfx.exe
8de8056083825bd98a731ede61073f59f8d472b957e20e4bcbce103abd05c9d722d37c26c633c2e831e9628fb4fdeca998e719ffd9b16dd0f3c4dd63df2ab0af  /opt/fog/snapins/TeamViewer-AllSites.sfx.exe
[root@10fogserver ~]#

[root@13Storage ~]# sha512sum /opt/fog/snapins/TeamViewer-AllSites.sfx.exe
8de8056083825bd98a731ede61073f59f8d472b957e20e4bcbce103abd05c9d722d37c26c633c2e831e9628fb4fdeca998e719ffd9b16dd0f3c4dd63df2ab0af  /opt/fog/snapins/TeamViewer-AllSites.sfx.exe
[root@13Storage ~]#

I installed a new storage node with Centos 8, disabled the firewall and Selinux.
I then copied the snapins from the old storage node to the new storage node because it’s on the same subnet and would be faster than letting the snapins replicate.
I then installed fog as a storage node. everything looks and acts as it should. I then Imaged a PC using the storage node and it imaged correctly and joined the domain, the snapins however will not install because of a snapin hash mismatch.
I then deleted all of the snapins in the /opt/fog/snapins folder on the storage node and let it replicate. I am still getting a hash mismatch error in the logs.

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 11/26/2019 4:14 PM Client-Info Client Version: 0.11.16
 11/26/2019 4:14 PM Client-Info Client OS:      Windows
 11/26/2019 4:14 PM Client-Info Server Version: 1.5.7.55
 11/26/2019 4:14 PM Middleware::Response Success
 11/26/2019 4:14 PM SnapinClient Running snapin 01 - MTS-TeamViewer
 11/26/2019 4:14 PM Middleware::Communication Download: http://10.13.40.39//fog/service/snapins.file.php?mac=44:85:00:3E:01:52|44:85:00:3E:01:53|46:85:00:3E:01:52|00:23:24:AA:FA:05|44:85:00:3E:01:56&taskid=9461
 11/26/2019 4:14 PM SnapinClient C:\Program Files (x86)\FOG\tmp\TeamViewer-AllSites.sfx.exe
 11/26/2019 4:14 PM SnapinClient ERROR: Hash does not match
 11/26/2019 4:14 PM SnapinClient ERROR: --> Ideal: 8DE8056083825BD98A731EDE61073F59F8D472B957E20E4BCBCE103ABD05C9D722D37C26C633C2E831E9628FB4FDECA998E719FFD9B16DD0F3C4DD63DF2AB0AF
 11/26/2019 4:14 PM SnapinClient ERROR: --> Actual: 4629994E3A40C689A4F178F68E37A944EC8202717F20555CB8C0E1E6A31F11E2258CDD27EA3450F53D0BE1B9461D04C437637C58C1599A71EFEA2B20AF1D8A13
 11/26/2019 4:14 PM Middleware::Communication URL: http://10fogserver/fog/service/snapins.checkin.php?taskid=9461&exitcode=-1&mac=44:85:00:3E:01:52|44:85:00:3E:01:53|46:85:00:3E:01:52|00:23:24:AA:FA:05|44:85:00:3E:01:56&newService&json
------------------------------------------------------------------------------

I just went ahead and password protected the whole PXE menu with the ESC option.
Thanks anyways.

I have Parted Magic as a PXE menu item and would like to password protect it.

currently, my PXE menu entry looks like:

login
kernel http://${fog-ip}/pmagic/bzImage edd=off load_ramdisk=1 prompt_ramdisk=0 rw vga=normal loglevel=9 max_loop=256 boot=live ip=dhcp noapic sleep=0 loglevel=0 keymap=us splash quiet
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/PMAGIC_2013_08_01.SQFS.cgz
boot

It prompts you for a login and password but will continue to the Parted Magic regardless of what is entered for credentials.

@Tom-Elliott I have access to the DB so I can work around it.