@Wayne-Workman @Quazz Fixed, it was that fixparts was missing from 1.5.4 as discussed from this post https://forums.fogproject.org/topic/12059/fixparts-missing-1-5-4-win-10.

To be on the safe side I manually downloaded bzImage, bzImage32, init.xz, and init_32.xz and put them in /var/www/html/fog/service/ipxe/. I followed the directions “Manual update to latest kernel” on this wiki page https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update.

Nevermind, i went to ipxe and saw how sanboot works.
So here’s what i found out:

101 tutorials later, the simpliest way to get Fog to work as a IT Tools and OS’s deployment system is indeed with an iscsi device.

So here’s what i did:

Step1: Get a Synology or an Xpenology
Step2: Create iScsi drive
Step3: Mount the iScsi drive in your favourite OS and Clone / Install whatever you want it there, treat it as you were installing stuff on a drive you would like to have it bootable, in my case, i had a physical hard drive full of tools , windows installs, and even a partition with an instalation of windows so i can test everything out.
Step4: After creating your Hard Drive just use Fog Project menu to say : Hey IPXE boot into this San device please.
In my case i just added: sanboot iscsi:192.168.0.6::::iqn.2000-01.com.synology:SrSynology.Target-1.43ae68fcff , i’ll leave this one here but this one is leading into my xpenology, you will need to modify yours.
Step3.5: i forgot you should enable multiple clients to access your drives, you can also make them read only if they are windows instalations or hiren’s boot or something, it works with everything and you don’t need to use the dreadful memdisk kernel that only works half o the time and it uses a bunch of unecessary ram.

Anyway, many thanks to this comunity you guys were great , for now, i’m setup.

A special thanks to George who was extremely helpful , it’s guys like you who make the internet awsome

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! 😄