@tom-elliott Awesome! Thanks a bunch Tom. I was able to get it resolved with the tips in that post.

Well, I mounted the ISO for 6.5 on the server, copied everything over, recreated the menu and edited the boot.cfg and the same issue:

The bootx64.efi and boot.cfg load as expected The VMWare ESXi installer loads files according to the boot.cfg The VMWare ESXi installer starts, the band/progress bar at the bottom gets past a couple stages and then PSOD on the “storage-stack” portion every time.

(all related to 6.5 U1 A10)
Tested 2x R620’s, one with all newest firmware, both have same issue. Tested on an FC630, works no issues.

ISO burned to physical media runs as expected and works in both R620’s via UEFI DVD/CD boot.

I am going to try and alter the 6.5 install to run over ftp instead of http to see if it changes anything. I had done this prior I think, but want to be sure. I will pass everything via ftp (bootx64.efi, boot.cfg and all modules from boot.cfg).

If that doesnt work I will just give up on the R620’s getting PXE booted ESXi 6.5 U1 A10. As long as its 1 or 2 machines/models that arent critical I can live with that but if the crashes become the rule and not the exception thats going to cause issues for me.

Lastly, is there anyway to via UEFI do something similar to a memdisk/iso load? I know memdisk itself is BIOS only, is there a way to UEFI boot straight from ISO?

Thanks

EDIT: ftp crashes just the same, i give up unless I can UEFI boot the ISO

@ravigon Thank you very much for reporting this. Most definitely this difference is due to Microsoft changing something through a patch made public after our wiki article was initially published. I will get this updated photo into the wiki and again thanks for this! #wiki worthy.

@shad0wguy Looks like it may have been an issue with the AD integration on the NAS I have set up as my storage node. The user account I have set for fog wasn’t able to authenticate.

@george1421 A coworker was able to resolve the problem coming in with a fresh mind. Apologize for the wasted thread

@thebrennan47 That helps out quite a bit. I thought there was a bit more going on here than I originally imagined.

You need to change up your configuration. Your storage node is acting as a gateway between the fog server and the target systems. You need to change the served subnet on each storage node. Each storage node needs to be connected to a unique subnet. On the surface you have a routing problem not a fog problem.

Consider if you are using subnets 192.168.1.x on each storage node. If a computer on SN1 talks to the fog server, and a computer on SN2 talks to the fog server and each has the same subnet, how will the fog server know where/who to respond to.

So how to fix it? Give SN1 imaging network an IP subnet of 192.168.1.x./24. Give SN2 imaging network an IP subnet of 192.168.2.x/24. Give SN3 imaging network an IP subnet of 192.168.3.x/24.

Now go to your internet router and create a static route (or you can do this on your FOG Master node) that describes the subnets beyond each storage node. Like

ip route add 192.168.1.0 mask 255.255.255.0 via {SN1 LAN interface}
ip route add 192.168.2.0 mask 255.255.255.0 via {SN2 LAN interface}
ip route add 192.168.3.0 mask 255.255.255.0 via {SN3 LAN interface}

You will need to change the dhcp server settings on each SN too to match their respective imaging network range.

Once you have routing and unique IP addresses in play FOG should work a bit better.

Hi Tom.

I wanted to update you, I have performed fresh installs of Ubuntu on all 3 servers, and installed the latest working branch version of FOG, 1.5.2.10

This time I did not import my hosts and old images and started fresh by re-registering hosts to test with. This time I am not having issues with the location plug in. Perhaps it was the old host data which was causing these issues.

Anyways, I appreciate all your help and time, and your effort on this wonderful product which makes many other peoples lives much easier.

Fixed in working branch.

If you have ubuntu (likely based on the path of the error log file) AND FOG was working great yesterday and now its not AND you changed nothing, blame it on Ubuntu. Review this document and see if it fixes your issue: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@mrlemur I don’t think there’s a way to set a default. On a positive note, you can use groups to set the location for many hosts at once. You can also temporarily set max clients to zero for the storage node you don’t want to use. Using FOG’s searching functionality, and with know edge of your naming convention, you should be able to quickly sort hosts into groups by location.

@nx-vijay how many routers are between your fog server and your client computers? If its more than the one pfsense server you have in your office then you will need to enable igmp routing on all routers in question.

But then I would have to also question if you really need to multicast (send the same image to each computer at the same time)? Or would unicasting work just as well. Remember with multicasting the slowest computer (link) in the multicast group sets the speed for the entire group. So if you have one site behind a 1Mb DSL connection and one at HQ on 10GbE that computer behind the 1Mb will set the imaging speed for everyone.

Thanks! @tom-elliott

Just had this issue with Ubuntu 16.04 and Fog 1.4.4

Followed these steps and I am back in business!

@sebastian-roth There seems to be an issue with php-fpm and apache on Centos 6.9. For now the quick fix is to disable the link between php-fpm and apache to return php control back to apache. ref: https://forums.fogproject.org/topic/11722/problem-during-upgrade-from-1-5-0-to-1-5-2/18

@librarymark Looks like the binaries failed to download, which caused the later error you are seeing when it tries to unzip & move them to the right spots. Look earlier in this log, you should find an error related to the binary downloading.

Solved by Tom Elliot as per this thread: https://forums.fogproject.org/topic/11717/fog-1-5-2-host-module-settings-don-t-save/7

@george1421 It did work thanks! But now after I deployed it on the same model computer Fog keeps trying to run maintenance restart and also never changed the name If you want I can make a different post instead of in here.

@Tiagoluz we need more information, like the OS your main fog server is using. Concerning that problem, If it’s Ubuntu, odds are you simply need to enable remote access for the fogstorage mysql user. Also, this article outlines all of that as well as other troubleshooting.: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Easy_.26_quick_MySQL_test

@george1421 because of the VM i’m letting fog do the dhcp. I get the white fog screen with the options and when i pick quick reg i get the bzImage and init.xz ok on screen and after it shows this it goes black.

I’m aware of the issue and have already fixed this in the working branch.