@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.
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.
@george1421 I called the fog.download script and got ‘no OS defined’ which must have been the kernel reload you mentioned.
how did you reload the kernel params like that? i dont see in any code anywhere to issue a reboot command unless its in functions.sh, which seems to be the common dump
@george1421
Sweet. This will be my project tomorrow.
Today I ended up automating the server node installation, was pretty fun actually. Learned a bunch of the inner workings. Never written a bash script before, or modified the fog.man.reg in the way that I have. The man.reg only asks
Hostname:
LocID:
ImgID:
GroupID:
Then deploys.
This poses the question though, I still don’t understand the workflow enough…how DID you end up having the machine image without rebooting?
Client time has been adjusted but its being adjusted on-the-fly. Imaging workflow is mostly completed on new laptops, however NOW will be pre-existing computers. Pre-Existing will expand that range from the 4000 as it stands now, to an additional 10k. I’m glad you guys mention that though, as I will need to definitely change that over ASAP before I roll out the FogClient deployment (via PDQ actually, george…however in this engagement we’ve noticed PDQ only scales sooooo much :))
It turns out that after setting the images to replicate with the functionality you guys mention (Group > Group Image Replication) worked. I might have been a little impatient when testing it before. I guess it makes sense that at the time I’ve been impatient with it, but it is what it is. I’ll have to monitor the Master Nodes in their respective groups - but I set one overnight to replicate and it worked as expected…prior to that it did not (Seemingly? perhaps firewall issues though…I watched the log as this one happened)
In most situations I wont be making storage group slaves, luckily. However the infrastructure is there to “make” the images at the HQ site. Massive ESXi farm, lots of existing snapshots, and already open firewall to everywhere.
I now understand what you’re mentioning about the database design. Any guides you have to work on this and migrate it over?
I’m getting to a point in this project where I have to offload nearly everything as I’m leaving the country soon. But all the preparation I can do in advance, the better. Going to go build 70 storage nodes today and tomorrow 