@wayne-workman Hey Wayne, thanks for your help. You can close this. We are migrating to a new image anyways and I don’t have a ton that are deployed out, so I’m just going to start from scratch. Thank you very much. : )

@benc Good to hear that you could make it work. I still suggest you should read up more about UEFI and think about moving all your systems that direction.

@gabbas Ok, thanks for letting us know. I talked to the fog-client main developer about this and we both were kind of puzzled by this. I’ll mark this solved then. Please open a new thread and post fresh new logs if you have an issue again.

I think the hostname policy of our company is the problem. We use year numbers and consecutive numbering as names for the hosts. And exactly in the query with one of the consecutive numbers results in several results of the query. Just there.
If I enter the entire name, it will only display that one host.
The case can be marked as solved.
Thank you for your cooperation.

@jjsplitter said in PXE / TFTP booting is slow:

I find it hard to believe that it is a network issue. Even after I know a computer is imaging slowly, I can start another one simultaneously and it will be imaging at a normal speed.

The issue is probably not the network itself but a combination of network driver on the client and your setup. The only way we can figure this out is by looking at the network packets. You’d first have to figure out which network interface is used in the FOG server (sudo ip addr show).

On the other hand it might be a very hard thing to nail down and fix anyway. So I do understand if you don’t want to spend more time on this. I’ll mark this thread solved for now. Feel free to open a new one and post a reference here if you want to keep debugging this.

@andreiv I moved your last post to here since it’s a separate issue that you found: https://forums.fogproject.org/topic/11157/checking-schedule-shutdown-after-task-completion-causes-the-running-task-to-hang/2 Please follow it there.

@wanderson We’ve lost track of this issue, sorry. Have you looked into MySQL max_connection limit yet? See here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Increase_maximum_simultaneous_MySQL_connections

@caw001 @rboan ???

@Seydoo Is this still an issue? Do you use proxy authentication?

Marked this solved as the initial issue can be circumnavigated and we have a github issue open on that topic.

@fry_p Any news on this? From your point of view, is there anything we can do right now?

@CoxM Did you solve the issue together with the help of @george1421 ?

Marked as solved…

@Jim-Graczyk Sorry we’ve lost track of this. Are you still in need with this issue. We hardly have enough time to fix all the big and small issues and try to push the next release forward. So writing documentation about all the services is way beyond what we can do right now. I know this is sad. But hey, why not you join in, check out the stuff and write it all down?

@kevin-talbot said in Capture speed very fast, deploy starts at nearly 7mb/min and at 10% starts slowing down gradually to 3mb/min!! please help?:

SA400S37

So far I haven’t found people talking about speed issue with those drives anywhere on the net. But looking at the specs I see that this drive uses TLC NAND flash.

To quote someone from this reddit post

There are different types of FLASH that are vastly differing in reliability. Read up on SLC, MLC and TLC. Basically the Pro series store less data in each FLASH cell. The more data you cram into each FLASH cell the less reliable the disk is.

@bardwood said in FOG UEFI image sync with storage node seems to be looping\failing on UUID info.:

When I was capturing these images, all the disk info would get captured but it would error on ‘d1.original.swapuuids’.

We need to know the exact error - otherwise it’s just guess work going the wrong way.

Though I am not an expert on the replication logic yet I think the issue could be that you’ve deleted that file on the master. Please move that d1.original.swapuuids on your storage node out of the way (so you still have a backup copy of it just in case): mv /images/X1CG2-UEFI-FC-V1/d1.original.swapuuids /root

Then see if replication stops looping.

Replication is a very tricky thing to get right and so messing with it (deleting files by hand) makes it even harder.

@fredlwal any news on this?

@Jarl2-0 Thanks for letting us know. Marking this solved.

@george1421 said in Log file 1tb. After removal FOG web service not working:

What you have is unique, so I can say this isn’t how FOG should work.

Since you are using ubuntu I’m suspecting this post speaks to your issue: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

My bet is if you look at the apache2 error logs in /var/log/apache2/error.log (I think, I’m a rhel guy so the path is different). You will see error message that refer to database issues.

That post fixed my issue.

Thank you!!!

@cklemm You are welcome and thank you for letting us know.