@Wayne-Workman +1 to the mixed HDD modes. I about tore my hair out one week over some hosts being set to IDE and others AHCI.

@Wayne-Workman

systemctl enable mysqld

Typo correction!

I will reboot my FOG server later today and give you the results of your suggestions. Right now I am reveling in the wonders of 5GBps imagine speed. 1.2.0 on my old hardware topped out at 1.2GBps

@Wayne-Workman

Bad sectors on the hard drive caused disc part to fail after 2.7gb of 63gb, so I imagine windows was literally waiting to load files that did not exist… solved! Different machine, Fog uploaded the image and deployed it flawlessly!

That’s very promising to hear Wayne! I must admit that you shot beyond my skill set with your bash script and use of the API. I look forward to your “generic” solution!

@Tom-Elliott Yes Tom, I am in no way demanding, I am fully aware of the volunteer nature of FOG. I am merely determining the scope of the current functionality, as the Wiki, which is just as volunteer maintained, is somewhat behind the current release. This is one of the times where my understanding of system features and internal mechanics did not match up to the production environment.

@Quazz Would the exclude prevent snapin deployments on Wi-Fi? If so that would be crippling.

@Quazz You are absolutely correct, but its the end users productivity being affected. I can not bring down the facility for hours.

@Tom-Elliott Is that an option? If so how is it implemented? I suspect the Wi-Fi Mac’s are what keeps annihilating my pending MAC’s list.

@Quazz The network in the facility is a hodgepodge of whatever we could get our hands on, and as a result the multicast throughput is abysmal. 300MB per min. Whereas Unicast I get upwards of 5GB per min.

Thanks for everyone’s hard work regardless of the outcome of this discussion!

I suppose I should edit the topic title, but I realize what I’m truly looking for, in an end-game sense is a rolling deployment. With my current hardware, I have reduced my queue depth on our single node to 2, and deploying to 50 in-use hosts causes mass panic akin to a zombie apocalypse. I do not have the option to gather the hardware and do a multicast, because the facility is run 24-7 with each shift using the same computer systems, and there are not enough of them to go around as it is.

Running Version 1.4.0-RC-14
SVN Revision: 6069
Client: 0.11.12

I have configured all my hosts with their Ethernet MAC address in our FOG server. I have not configured their Wi-Fi MAC as I do not know of a way to PXE boot on Wi-Fi given my current hardware. But much to my horror, the FOG client will task restart the host when connected to Wi-Fi, which ends up in a boot-loop and a very concerned end-user.

What are your thoughts on this matter?

I’m not familiar with the specifics of the internal mechanics, but it occurred to me that it may also be handled server side, by pushing the deployment schedule for all not-in-progress tasks to a future time, then when the in-progress deployment complete successfully, change the time to instant, then after two begin, push the rest to a future date. Also sounds shaky…

I would like to request that the Task Reboot function of the FOG Client be aware of the image queue depth. In this way the users productivity is not impeded when rolling out an image as they stare at a PXE screen informing them they are in line. The end result would be a rolling image deployment as the fog client would not trigger a reset unless there was an open slot.