Just for notice,
I’m using Fog 1.5.4 normally with ubuntu 16.04 and this function is working fine. Both this option you mentioned and the option to go in the option “power management” work the same.

Best regards, Igor.

@mparlette said in Date off in dashboard #253 - Github:

CentOS 7 w/ FOG 1.5.4
/etc/php.ini date.timezone entry was commented out.
corrected with:
date.timezone =“America/Vancouver”

Technically that may not help you. In a normal world it would. But in FOG’s case its using php-fpm which has its own opinion of things and if you have php 7.x installed then the /etc/php.ini file is typically not referenced since php 7 has this file in a different path.

But having the OS and fog menus in agreement should get you to where you want to be. So good job!!

Something you might consider.

login kernel nfs://10.100.0.55/winimgs/iso/Winpe/wimboot gui iseq ${platform} pcbios && goto mem_bios || goto no_mem :mem_bios initrd -n bootmgr.exe nfs://10.100.0.55/winimgs/iso/Winpe/bootmgr.exe bootmgr.exe goto mem_cont :no_mem initrd -n bootx64.efi nfs://10.100.0.55/winimgs/iso/Winpe/bootx64.efi bootx64.efi :mem_cont initrd -n bcd nfs://10.100.0.55/winimgs/iso/Winpe/BCD bcd ...

Also realize that ${fog-ip} is a variable that expands out to the IP address of your fog server. If you use the variable it makes your pxe menus portable between FOG servers.

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!