@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.

Hello,

excuse-me for awakening a quite old post, I’m not asking for help but adding some contribution in case of someone else has same problem. I also had yesterday the same message when trying to capture a syspreped Windows 10 pro 1709 image (with Virtual Box)

0_1524123955382_Capture6.PNG

I tried several basic steps suggested in this post, but the thing that simply worked for me was tu upgrade fog server… (It was not updated since two or three months)

I can’t reproduce the issue, but it can be a step to try before recreating a new Windows sysprep image 🙂

@Quazz True, but I wan’t to see what can be done with UEFI. In the future I will make almost all my deployment by UEFI boot. So I hop it will work find, I see than UEFI is not standardize as Legacy. So it was to understand.

what device is providing your dhcp or proxydhcp services?

@zeltron80 said in Storage Node different for capture and deploy:

Could you explain me if it’s normal operation or it’s a bug?

It’s normal operation. FOG uses the first server it finds that has available slots - unless you’re using the location plugin which changes this behavior.

I have try to skip this problem to set Max Clients to 0 on my default Node it’s work but when i want to see my Nodes on the Storage Management web page i have a blank page…

This is a known bug in 1.5.1 and 1.5.2 where if the max clients is set to 0, it causes a problem. This will be fixed in the next release candidate.