Lets collect a bit more information here.

What version of FOG are you using? You captured an image from a reference computer, what hardware was that reference image created on? Is the hardware you are deploying that image to the same as the source computer? Did you capture the image as single disk resizable? Is the target hardware running in the same mode as the source computer (i.e. bios and bios, or uefi and uefi?)

@vascomorais Do you have a good link for this ISO?

@joe-gill Well in a way I’m glad this issue was a FOG specific one, but rather an infrastructure. I can say multicasting is a bit of a fickle beast no matter what imaging technology you are using. When it works, its great.

It sounds like your network was configured for dense mode multicasting where it would just send the mutlicast stream to all ports even if there were no multicast subscribers.

Thank you for providing solid feedback and sticking with this issue until it is resolved.

@mparlette @george1421 Thanks. I’m not sure what the issue was, but I believe it to have been network related. I didn’t realize it initially when I posted but the pings I was doing, showed dropped packets galore (even while some were successful). I’m working my way through the install guide after creating a new VM, and so far it’s looking alright. No packet loss on an initial test ping. We’ll see what happens when I start the FOG installer!

EDIT:
SUCCESS!

@george1421 Here is a post and a thread (with developer supplied code) that will hot patch the registration file. This thread was actually someone wanting to create a custom registration process.
https://forums.fogproject.org/topic/9754/custom-full-host-registration-for-1-3-4/45

@phil-dosi See George’s last post here: https://forums.fogproject.org/topic/12104/capture-deploy-tasks-hang-on-erasing-saving-partition-tables

@george1421 I left it all alone. I did ran my test and everything deployed just fine. Tried on 20 pcs and everything work just like it was during testing. How do I close? Can you close or how can I?

@svalding Thanks for getting back on this and letting us know!

@tom-elliott DEXTER is the storage group i created. Well after looking in the storage group it was not added in the storage group field, after adding it their it appears to be gathering. I appreciate and thank you sir. I’m sure i will have more coming soon 🙂

@wayne-workman Thank you. So far we seem to be working through them but we aren’t quite back to normal yet.

@vince-villarreal I have same issue and I have been going through all threads regarding this particular issue. I have exactly the same issue and I feel it’s definitely going through a replication loop. I’ve been monitoring the replication log for past couple days and seems like the replication is stuck on one storage node. Keeps deleting the d1p2.img file and begins synching only to come back to the same file and replicate to same node again.

I should also mention I have reinstalled fog from scratch configured all nodes so initial replication of an uploaded image worked fine. It was indeed after an updated image upload when replication loop began.

@george1421 Hi George. You’re right. I’ve seen this post while I was searching for my error. I’ll give it a try this afternoon. Thanks

@pa_fog_man I think we have a bit of confusion here (and the 390 is not helping with clarification). First let me say that the Dell’s will let you dynamically boot in the other mode without changing the firmware (where it gets its default value). You can do this dynamic switching from the F12 boot menu. The other issue with the 390s (I can’t speak for personal experience with the 390s, but we have 790s in our fleet) the 790s were the first generation to support UEFI mode. But as far as I know, the 790s don’t support pxe booting in uefi mode. The 7010s was the first generation to support pxe booting in uefi mode. To pxe boot on the 7010s you would have to enable the uefi network stack on the network adapter settings in the bios. Otherwise you would not get ipv4 and ipv6 entries under uefi on the F12 boot menu.

Back on point. You MUST select the proper boot kernel for the target system bios mode (legacy/bios or UEFI). If you sent the wrong boot file to the system you will not see the FOG iPXE boot menu.

for bios mode you can use ipxe.pxe or undionly.kpxe
for uefi mode you can use ipxe.efi or snponly.efi

The bold text above are the typical kernels to set for dhcp option 67.

You can not mix the boot kernels. This isn’t a FOG issue, but rather a firmware one.

@george1421 Gotchya, that explains it, Thank you! 😄

@msi said in 503 Service Unavailable:

didn’t change routeraddress, plainrouter, and dns address.

Those settings only affect DHCP on the fog server (If you’re using fog for DHCP). They would not affect web gui operation.

hi gencap
thanks for this post, new version MulticastTask.class.php in fog 1.5.4 have different code, if i change code like in image can run?0_1529778534816_fogLimitBitrate.PNG

I figured it out - I forgot you cannot try to take a new image over an existing image. We already had taken an image with the exact same folder name and when FOS tried to move the files, it failed. When I deleted the old folder, the image capture worked perfectly. My bad!

@imagingmaster21 Ahh, now I get what you mean. Thanks for letting us know.

@jmg74 said in dell optiplex 3050 avec windows 10 UEFI:

@verdierr : have you tried different options in your host config in Fog website, about “Host Bios/EFI Exit Type” ?
[FR : As-tu tenté différentes options, pour ton hôte (via le site web de FOG), concernant “Host Bios/EFI Exit Type” ?]

we tried every possible combination but none worked.

for option 60, we have legacy computers and to try the uefi, we saw on the web that you have to activate option 60?