@mmoore5553 Understood and appreciate the return with new information.

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

@romprager The simple answer is depends on the iso image and what OS will boot from the ISO image.

I do have several how tos in the forum that shows how to net boot several different installers.

https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@rodluz I know you were talking to the other person, but if you like you can send me the kernels for testing.

@Tom-Elliott Hi Tom,

Thank you, that clarifies a lot. I now understand that hostSecTime represents the expiration time, not the creation time, which fully explains the consistent +30 minute offset I was seeing. That part now makes sense and resolves my question.

The only remaining actual issue I’m trying to understand is the snapin behavior: in several cases, snapins did not execute on some hosts. I don’t see any errors in the logs. Only that the snap-in task doesn’t start, but I will work on this and gather some more data. Thank you!

@Tom-Elliott Yep, I caught that workaround in the earlier post. I moved the image folder from /images/dev to /images, but still resulted in the same error.

One thing I noticed this morning, is that the image capture process is hanging at 99% on the task page, as in for at least 45 minutes. Not sure if that is a symptom or the cause.

The previous post was suspect of a very recent init version – but i’m on the most recent dev-branch.

Thank you!

Thank you george1421 that 's was the solution.
I was troubleshooting remotely, and the technician on site insisted that images had already been downloaded onto it.

I understand your point of view, but I also have to remain anonymous to my colleagues.

Solved !

@george1421 noted. When I was initially testing, I did not know this and it took some digging in the forums to find this tidbit of knowledge. Given that having separate storage groups stops replication between the nodes in my mind it makes most sense to have a more distributed setup of normal servers at each site to handle all of my requirements. Thanks for the input!

@Sebastian-Roth Can I bother you with this quick question ^^^

I am confident I have ruled out NFS. I can now connect to the NFS from localhost and Ubuntu to /images & /images/dev without issue and all the permissions that come with it. The only thing failing now is FOG, any guidance would be great!

@rodluz
Problem solved - the disk with the image was damaged

@lmoysidis I’m not using fortigate but check out the following article: https://docs.fogproject.org/en/latest/installation/network-setup/proxy-dhcp/?h=
I needed to dynamically assign a boot file based on vendor class and dnsmasq did the trick!

@Tom-Elliott Thank you so much Tom, as always I appreciate your support and guidance.

I’m going around replying to all these old Docker request threads so people can try out my work. Check out my thread here:

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

and provide feedback in the comments.

the actual github repo is here:

https://github.com/88fingerslukee/fog-docker

I’m going around replying to all these old Docker request threads so people can try out my work. Check out my thread here:

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

and provide feedback in the comments.

the actual github repo is here:

https://github.com/88fingerslukee/fog-docker

I reverted back to a snapshot I had on the same version and it’s working as expected. Unsure how things got corrupted but I would say it’s safe to assume this is working unless others report the same issue.

@chevengur there is not enough information to help you in that picture. If we could see more of the error message that partclone threw (i.e. just above the top of your picture) we would know what happened. At the point in the script all we know is that partclone wasn’t happy.