@amir3161 Usually it’s better to open a new post as your question (Ubuntu 16.04, FOG 1.4.4) does not match the topic. Describe what you did, post your ipxe config and post a picture of the error.
One would think that if 14.04 worked as ISO 16.04 would also do. But maybe there is a difference. Read through this (talks about extracting the ISO because it does not boot otherwise) and open a new topic in case you still can’t make it work.
@badhonsoam What exactly have you tried this time and what error did you get?
You need to understand that it’s impossible for us to help if we only know “is not working”…
@sudburr Just a quick idea… maybe SELinux or the firewall? Forgot to disable? https://wiki.fogproject.org/wiki/index.php?title=CentOS_7
@davidjor I think things are being a bit mixed up here. Let’s step back and take the whole picture. In your initial post you said you wanted a FOG standalone setup and you thing dnsmasq could cause the issue. Let me ask, why do you use dnsmasq at all. What is providing DHCP in this scenario? Looks like an external server is doing this. What is it? Why can’t you add PXE boot options to that DHCP server?
If you can’t modify that DHCP server then dnsmasq is the right way to go. But as it can be a little tricky I first wanted to check if we really need to go that way.
Looking at the config you initially posted I see a line pxe-service=X86PC, "Boot from network", pxelinux which could be causing that we see pxelinux in the pcap file. Please make sure you only use Georges config (not a combined one) and put in your IP addresses where needed.
@tmerrick Do you actually see Wake On LAN packets in your network?? Maybe it’s something completely different. What if you shut down the FOG server? PCs still turn back on?
Either that or we have different block size disks, 512 vs. 4096
@BREIT Please schedule a deploy or capture task as debug and run fdisk -l /dev/nvme0n1 when you get to the shell. Do this with all the different types of disk you have, take pictures and post those here.
@coxm said in Dashboard Bandwidth graph not showing traffic:
For reference POR (Master) and ATL (Storage Node) are on 1.4.4
PHX (Storage Node) is on 1.5.2
Though I am not an expert on the inter FOG node communication I’d advise you to run the same version of FOG on all your nodes and see if that helps.
@Critchleyb Yeah it’s not as simple as pushing a new IP to your FOG server via DHCP. But thanks to Wayne we have a script available that does the Job for you. See if that is enough for your scenario: https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP
@Critchleyb said in Changing IP's on a portable FOG Server:
I see it mentions DHCP, however I’m not using fog to run DHCP, will there be any issues there?
Nope, won’t be an issue as long as you have your “external” DHCP setup correctly.
@dclark good you went to the dev-branch as I have fixed a snapin replication problem there which we had in the 1.5.5 release…
As you have a fair amount of storage nodes you might want to test the updates I will push to the dev-branch fairly soon?! Will improve the web UI speed use even less traffic between the nodes.
@lschnider Ok, so client can reach the server but firewall is enabled. Disable it for now and see if the deploy is working then. This looks like a CentOS ruleset. So I may ask if you have followed our wiki article on CentOS and disabled SELinux (and the firewall)??! I wonder how you were able to capture an image if the firewall was enabled all the time. Run the following command to switch off the firewall temporarily and then try to do another deploy: systemctl stop firewalld
@george1421 @Wayne-Workman I just pushed a change to check for SELinux and firewall, inform the user and ask if it should be disabled. Hope we won’t see those issues anymore. Or at least then we can say… told you so. 
@iot You seem to be using the EFI Network boot option. In this case you need to set ipxe.efi as boot filename (option 67) in your DHCP server.
For more information on the difference between legacy boot and UEFI boot read our wiki article here: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence
@PITSKing As we’ve had this kind of question a couple of times lately I just want to add that the image definition/metadata needs to match the settings you had on your previous FOG server for each image exactly. If it was set to be a non-resizable image on the old FOG server and you create it as resizable it will fail to deploy…
@cary1102 As mentioned in the other thread you need to push the option routers x.x.x.x to your clients or they won’t be able to reach the server that is in a different subnet. It’s as simple as that!
You seem to have already added the option but commented it again. Why? Don’t you have a router/gateway that can forward the traffic between those two subnets?
@nvdp2002 Do you have a direct Internet connection or going through a proxy?
@SPaceSkillz1 Do you run the installer as root (sudo su - instead of sudo ./installfog.sh)?
Post the last 20 lines of the error log you find in fogproject/bin/error_logs/fog_error_1.5.5.log!
By the way, 1.5.6 was released a couple of days ago. Do you have a good reason to still use 1.5.5?
@Wayne-Workman Sure, good point!
@MFuchs135 This is what the installer does at this point (I guess you are using the latest release version 15…6 with git and not the development branch dev-branch
cd fogproject/tmp
curl -kOL https://fogproject.org/binaries1.5.6.zip
curl -kOL https://fogproject.org/binaries1.5.6.zip.sha256
sha256sum --check binaries1.5.6.zip.sha256
@yas1 George is right, FOG is doing DNS queries mostly as part of a routine check to see if hosts are up. If you don’t like this you can disable the whole service in the web UI (FOG Configuration -> FOG Settings -> FOG Linux Service Enabled -> PINGHOSTGLOBALENABLED) or increase the service sleep/inactive time (FOG Configuration -> FOG Settings -> FOG Linux Service Sleep Times -> PINGHOSTSLEEPTIME) or you can take the big hammer and just disable the whole Linux service (systemctl stop FOGPingHosts ; systemctl disable FOGPingHosts).
I think that’s why every device in the database is shown as offline(“unknown”).
While this is related it’s not the fact that FOG cannot resolve it’s name but that it cannot connect to port 445 on your host(s). The word “ping” might be a bit misleading here, it’s not a standard ICMP ping we are doing but a kind of Windows specific check to see if TCP port 445 is available. Both checks definitely have drawbacks but some years ago the FOG devs decided to go the port 445 way and this is still the case today.
If you got hooked up by the idea to use the host status more there is also a plugin you can enable called “host status”.
Just wanted to add to George’s great list:
@Neil said:
An entry appears in the all task list for each, but only 1/3 appear in the active snapin task list.
Can you please check the fog-client log on these machines when this happens. My guts say that it’s more the clients not properly finding the snapin task rather than a DB issue. But that’s just a guess.