@mactuan12 The content you posted a good half an hour ago has nothing to do with FOG. I removed the external links as it’s considered spam…

I know this is a very old topic but it seems like people find this and follow it blindly. Please be aware that using the installer parameter -C (or --recreate-CA in long form) will overwrite your FOG internal certificate authority and break all fog-client installs because of this. The fog-client is pinned to this CA when installing the software on the machine and you need to re-install fog-client (or magically exchange the CA cert) on all your machines!

@george1421 Great, thank you! I appreciate the help.

@RipAU Can you give us more detailed infos on the ZIP file contents?

Could you upload the picture to some image share and post a link here?

@Tom-Elliott Hi Tom, sorry, I didn’t reply with that info, but yes, I did run the command you suggested to explicitly turn off bitlocker, but it was still giving me the same error. The error only went away once TPM was disabled in the BIOS. Thanks for your help trying to figure this out!

@Sebastian-Roth
I took your advice with certificate issue, and solved it easiest way, by preparing a new image, and voila, workstation joined the Domain with no problem. Need to prepare two more images, but its easier than searching for another solution. thank you!

@Salman-KB123 You’re on the wrong forums for this. FOG in this forum is a computer imaging software. iFogSim is something else entirely.

@zyzhang When a deploy fails it will set this value to zero. I know this is not great behaviour but that’s how it was in FOG 1.5.4. Nothing we can do about it. You’d need to update to the latest developer version (called dev-branch on github) for it to be fixed.

@CpServiceSPb said in ERROR: Not able to find a network interface that is up on your system:

And is got the same error.

What exactly do you mean by that?

Please run ip a s as root and post full output here.

@davide1611 said in No configuration methods succeeded: DHCP failed:

Thanks Sebastian and sorry for asking something already resolved

You are welcome. No trouble at all. It might not be too easy to find the answer to this in the forums if you don’t know what is causing this.

@Mightmar said in New computers- no configuration methods succedeed:

I got a new problem now

May I ask you to open a new topic for this? We try to keep things sorted here so others can find solutions to same or similar issues better.

@altitudehack To me it looks like you have found and fixed what was causing the error in your case. So I’ll mark this solved. Thanks for posting here. I am sure it will be useful for others in the future!

@Sebastian-Roth Thank you

@JYost As far as I know the inner workings of the fog-client installer I don’t hink you actually need to uninstall older versions first. Just install 0.11.19 and it will take care of an older version if it is installed - remove it and install the newer version.

@JYost The images themselves have not much to do with the fog-client software. It just does the host management (reboot on imaging tasks, domain join and so on).

But I do understand your question! Between 1.5.0 and 1.5.8 there were many changes in FOG and FOS (FOG Linux OS) which does all the actual work when imaging. We moved to newer versions with many tools in FOS, especially also partclone. But as far as our testing shows you should be able to use your old images without any change. Give it a try, just do a deployment to one of your hosts and see if it works. It should.

@alansopro Do you still see the issue happen?

@Sebastian-Roth
I have found the error by myself, it was a misconfiguration of the variable no_proxy. I have change it and restart fog, it’s ok now:
export no_proxy=127.0.0.1,IP.OF.SRV.FOG,[…]
Thank you for your help!

@FuriousGamer065 So did you use my tutorial and config file exactly to setup your dnsmasq service? https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@george1421 Hi! I’ve received a shipment of the laptops I am using this for, and for whatever reason those ones are booting from FOG properly. The computers I was testing on (which have the same BIOS software) did not boot from it. I am guessing that this was due to some BIOS configuration error on my part, as the computers have the same BIOS. Thanks for your help, though!

@george1421 I found a solution. I am not totally sure why the problem occur, but now i know what i have to do to get the PXE boot running. There is selfbulid captive portal running on 10.0.2.2 that uses IPTABELS to allow access to the internet. By logging on captive portal an other rule is added to the IPTABELS PREROUTING nat chain

ACCEPT all -- anywhere anywhere MAC 44:37:E6:B8:85:78

In this chain there are some standard rules on top and bottom.

DNAT tcp -- anywhere anywhere tcp dpt:domain to:10.0.2.2 DNAT tcp -- anywhere anywhere tcp dpt:domain to:10.0.2.2 ACCEPT all -- anywhere anywhere MAC 44:37:E6:B8:85:78 ACCEPT all -- anywhere 10.255.255.255 ACCEPT all -- anywhere 224.0.0.252 NFLOG all -- anywhere anywhere DOCKER all -- anywhere anywhere ADD RTYPE match dst-type LOCAL ACCEPT tcp -- anywhere anywhere tcp dpt:ssh DNAT tcp -- anywhere anywhere tcp dpt:https to:10.0.2.2:443 DNAT tcp -- anywhere anywhere to: 10.0.2.2:80 DNAT udp -- anywhere anywhere to: 10.0.2.2:42

Usually it is not a problem to reach IP addresses in the LAN if you are not logged in to the captive portal. I explicitly tested it today. If I am in windows and am not logged in to the captive portal, I can access all other websites in the LAN in the browser, except the FOG management portal on 10.0.32.180.

It looks the same with the boot process. If the computer is logged on to the captive portal then the PXE boot works without any problems.
If the computer is not registered on the captive portal then I always get the “TFTP timend out” message.

I just didn’t get the captive portal to play a role in this.

Many thanks to george1421 und Sebsatian Roth for the help.