@Enigma It appears that the isc-dhcp server (the one that FOG uses for sending dhcp info to the pxe booting clients) is not loaded. So that would explain why your clients are seeing that message, there is nothing to configure them.

You can install the isc-dhcp server after the fact too. Its easier to do when you install FOG, but can be done after fog has been installed too.

@Enigma ok lets run these commands:

netstat -an | grep :69
That should return something that looks like this 0:0:0:0:69

ps aux | grep isc
It should respond with something M says isc-dhcp

Make sure the the firewall isn’t turned on the fog host server.

@Enigma Sorry, that really didn’t answer my question. So let me ask it another way. Do you have the FOG server configured as a dhcp server? This would have been one of the questions it asked as you installed the FOG software.

@af-pw I’ve reread your OP several times and its not clicking in my head to what the problem is.

I can tell you that its possible to have 2 standalone fog servers and have the images from server A replicated to server B using the fog UI. All of the images from server A can be replicated to server B and then server B can add its own images to its own server only. But there is a caveat with this solution and its not supported by the Developers. Let me explain.

For a fog “image” there are two components. The first is the raw data files stored in /images. The second is the data base record (meta data).

You can do this by on server A going into the storage nodes and add server B as a slave storage node. Then add server B to the storage group for storage A. This will start to replicate the images from FOG server A to FOG server B. If there are images you don’t want replicated to server B, on server A go into the image definition and disable replication for that image.

Now for the caveat. The process above will replicate the raw data to server B. What it will not do is copy over the meta data. You will have to do that manually. on FOG server A go into the image definitions and export them as csv. Edit the csv with your favorite editor removing image definitions you don’t want to appear on server B. Then on server B’s web ui import the image definitions from server A. This step really only needs to be done if/when you add new images to server A that you want to see on server B.

@Enigma What device is your dhcp server for this isolated network?

@rodluz If you have an idea, I’m interested since I can’t seem to get the FOS kernel to boot on this hardware, and without having the hardware in hand its difficult to debug the issue too.

The FOS Linux original kernel configuration to start with is here: https://github.com/FOGProject/fos/blob/master/configs/kernelx64.config

@sopinv FOG doesn’t have controls to limit the number of devices that can register or the number of systems that can deploy.

This type of control is not a typical request of a FOG Administrator. What is your use case/purpose/problem you are trying to solve?

@george1421 Thinking about this a bit more, lets have you run through this tutorial to rebuild iPXE to the latest version. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1696626440791

I can’t say it will work (the act of rebuilding) with 1.6 since its been several years since I last installed it. But lets see about rebuilding iPXE and that might get you past that error message.

@jmeyer I would not consider fog 1.6.0-alpha for any type of productive use. While it has been kind of kept up in sync with the 1.5.x series it really hasn’t had much love in about 2 years.

IMO it really needs to get pulled until the developers can spend time with it working out its issues or they can get additional resources to spend time with the version.

@Gcostiou Ok if you solved the problem then its done. Just be aware that you can get fog installer to work through a proxy server if needed. By default the fog installer doesn’t know about the company firewall.

@garrett-stevenson said in Could not download init.xz:

Securly for our webfiltering

Do you have a on-prem proxy server that you need to configure your browsers to use?

@Gcostiou For installation your FOG server needs internet access and to be able to resolve DNS names like www.fogproject.org for the installation to work. Its failing to download the recompiled binaries from the github repo.

@DARUN974 Just be aware that FOG doesn’t create any uefi boot manager entries. Those entries can be added programmatically but the OS does that not FOG.

If by chance you wanted fog to create those entries you would need to create a fog post install script and use the linux bootmanager command to add those entries. The point is they are not automatically created by FOG.

@skyborne98 Lets see if this document will answer your questions: https://docs.fogproject.org/en/latest/management/web/storage-node/

@baovipboy156 said in Golden image problem:

install a fresh window 10 using MDT/WDS
update window, update all application,…etc
sysprep using unattend file
capture image using fog

This is the process we’ve used for years. I think we were at about 12 minutes from bare metal to first login. So it shouldn’t take 30 that’s abnormal.

Here is a copy of my sanitized unattend.xml file: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/6

Just glancing through yours it looks complete but I didn’t go over every line,

@Yanni That is typically a setting in the bios to set the boot order. When windows installs, it thinks it knows better and changes the boot order for you to have hard drive first. But I don’t think I seen it with pxe booting first in the order it only pxe boots without the hard drive.

@baovipboy156 said in WDS and Fog with Syslinux - Need Help!:

some how the network card only use 100mbps of 1Gbps,

Its probably best of you open a new thread since the issue it not related to the topic of the thread.

But in general WDS/MDT is a file level imaging solution, where FOG is a block level imaging solution. The file level solutions are more flexible and deal with deployment time decisions. But they are slow(ish). About 45-60 minutes bare metal to fully deployed. Where fog is a block level imaging deployment. Not flexible for deployment time conditions, but deploys super fast (~6GB/min), with a 25GB image taking just over 4 minutes to first OS boot.

Same task different tools, different results. Each tool has its strengths and weaknesses.

@boros said in WDS and Fog with Syslinux - Need Help!:

This is what should go into the Fog custom Menu right?

Yes fog custom menu akin to how the tutorial I linked worked. It goes in the parameters block

Do I need to create NFS shares on the WDS or Fog side?

You don’t need to create nfs shares anywhere. If you have dhcp setup right it will pxe boot to the FOG menu, then from the fog menu you will chain to the custom menu which will load and boot the WDS boot loaders.

Again be aware that the WDS server has a netboot service that you need to stop or you will never get to the FOG iPXE menu. You can do all of this via the FOG web ui. There is no need to hand edit files like with syslinux.

@Yanni That isn’t exactly what I asked for, but it does tell me what I suspected. See the target computer at .10, its trying to tftp the boot file from your firewall and not the fog server. If you set your capture filter (not display filter) to port 67 or port 68 it will only pick up the DORA communications. You want to look at the offer packet, my bet is the firewall is setting its own IP as the boot server. Your picture kind of shows the results of what I’m saying.

If you have a misbehaving soho router, we can fix that by installing dnsmasq on your fog server to override what your dhcp server is telling the client to do.

@boros said in WDS and Fog with Syslinux - Need Help!:

So I would have to remove the syslinux files from WDS?

Well WDS has its own netboot option that uses a proxydhcp server. You will need to stop this service since it overrides options being set by dhcp options 66 and 67.

The idea is that you would boot directly into the fog iPXE menu and from there if selected boot into WDS. The following command should boot from fog into WDS. But be aware I have not tested it only glued the bits together. You would need to change the 192.168… IP address to the IP address of the wds server.

set wdsserver:ipv4 192.168.1.12
set net0/next-server ${wdsserver}

iseq ${platform} efi && set bootfilenam Boot\\x64\\wdsmgfw.efi || set bootfilenam Boot\\x86\\wdsnbp.com

chain tftp://${wdsserver}/${bootfilenam}