@Joe-Gill i successfully ran through a pallet of these - 27 - and no issues. this was my process:
boot into BIOS setup.
Click enable UEFI network stack, scroll down to AHCI and click it. hit Apply.
on the left, select secure boot. disable using checkbox - it will ask if you’re sure. hit yes, hit apply. hit exit.
it reboots, hit f12, network boot ipv4
it works
if it doesn’t work for you, make sure your ipv4 UEFI boot settings are setup on your dhcp server (ipxe.efi instead of undionly.kpxe)
@victorkrazan6267 oooh nice something I can help with.
So I tried exactly what you are trying times 1000, and the very last thing I could get to work was adobe. In fact, I saved the command to finally install it as a txt file called F**ingfinallyabletoinstalladobe.txt lol.
What worked for me in the end was using JUST the installer exe by itself but with a command switch. It basically extracts to a path, uses a switch called
(Exe path) -sfx_o”c:(path to extract)” /sALL msi EULA_ACCEPT=YES
this worked for me. I found it off an adobe forum titled “how to download reader dc 2017.009.20044 msi”
the below entry, opening max connections for sql - was indeed a fix.
default is 151, and i now have been a solid 200 connections for a week with no issues.
in debian 11, i did the following :
sudo su -
mysql -D fog
SET GLOBAL max_connections = 512;
To make this a permanent solution, refer to the link in the previous post.
@wayne-workman thanks man but turns out it was due to my crappy netgear switches. actually used a cisco enterprise switch and all the clients connected on meraki AP’s, didn’t do all at once but it did send out office 13 (800mb) and a slimmed down version of smart (1.2) to ~10 at once at any one time.
worked well.
i can’t tell you how awesome this software is - i just got a new job, they gave me this new client to us with 350 machines, 2 weeks to reimage them all and i have a baby due in that 2 week period.
started yesterday, only 320 more go to lol.
Thanks again!
@Wayne-Workman never before. i’ll check it out - thanks.
the makefogmobile project would help me out probably too (for little one and done labs here and there)
Thanks for that!
i’ll see if it helps my current issue. if not i’ll just reinstall them all.
@brakcounty could be.
its interesting that its getting to IPXE already, so its getting SOMETHING from SOMEWHERE.
try it out and lets see.
@brakcounty to confirm, you mention that with UFW disabled, there is no delay. is the script running however?
@brakcounty what is the DHCP server that you’re using for this environment? are there managed switches in between subnets?
the below entry, opening max connections for sql - was indeed a fix.
default is 151, and i now have been a solid 200 connections for a week with no issues.
in debian 11, i did the following :
sudo su -
mysql -D fog
SET GLOBAL max_connections = 512;
To make this a permanent solution, refer to the link in the previous post.
unsure of this being a permanent fix, or if this is specific to my environment -
further troubleshooting of this environment showed that a specific storage node was behind NAT (and as such, mysql_error was showing a connection failing from a gateway IP, versus the storage node IP)
after shutting this storage node off toward the end of business, the error seemingly cleared until the next day, and a bulk of imaging/client checkins began.
couldn’t tell if its because lots of client checkins happened at start of business as a lot of machines turned on, OR something else. the error returned around 10AM.
i found a link (https://www.thegeekdiary.com/mysql-error-too-many-connections-and-how-to-resolve-it/)
which pointed me in the direction of temporarily opening up max connections for SQL.
this has so far resolved the issue, even with the errant storage node. i was at 151-152 just prior to this bump, now i’m hovering around 160-165. i might have been hitting this ceiling organically.
@george1421 yeah man. used that tutorial (from you 
already on innodb.
TBH, it seemed that when this issue happened earlier, it happened when we were using ISAM. after migration, they went away, until recently.
(we’re adding 200-250 hosts a day however)
@george1421 from the multicast not starting thread?
https://forums.fogproject.org/topic/15960/fog-multicast-not-starting-anymore
@george1421
mariadb is between 30-50% roughly.
currently have given the box 32 cores, 32GB RAM. RAM util is only hovering around 1.25GB though.
so far, approximately 6000. around 7500 in the host DB. most of those are on during the business day.
In reference to some previous posts I’ve made, this post is probably in relation to the size of the environment where my FOG install resides.
The exact errors as they are stated from this link
https://mariadb.com/kb/en/aborted-connections/
What I have seen is that after some time in production, between many simultaneous images being deployed from around 40 storage nodes, as well as thousands of clients connecting to the main FOGserver with db…
Pages and images start to fail with a ‘database connection failed!’ blank html page (with a url pointed to schema) or ‘valid database connection could not be made!’
The mariadb/MySQL logs start out fine at startup, followed by a few errors that say data inconsistent, then start to slowly get flooded with the aborted connections error until that error persists 5-10 times per second constantly until the service is restarted.
This has shown up occasionally in the past however was usually resolved by a reboot and wouldn’t come back after several weeks. This time however we’re seeing this 2-3x an hour.
A quick netstat-plant shows what looks to be a lot (if not all?) storage nodes connecting over 3306, and established - a LOT of time_wait to all sorts of hosts on 127.0.0.1:9000 and quite a few on 80 as well.
This issue causes all tasks to fail, from imaging to client check in.
Because I see the mariadb KB pointing to .net, I was wondering if this is related to the FOG client?
I currently have agent check in time at 8 minutes and have migrated to innodb.
@george1421 yeah the error was something from funcs.sh, no OS ID passed, call determineOS.