@Tom-Elliott @sideone @MatMurdock
I can confirm this is fixed in the latest

@sideone @MatMurdock @Tom-Elliott
I just tested this and I’m getting the same thing too. This was working previously, we’ll work it out.

@MatMurdock

First I would ask you to check the php error log
cat /var/log/php-fpm/www-error.log
And post any relevant errors or warnings occurring at the same time this happens.

Then 2 things I would try

I’d start with trying ipxe.efi instead of snponly.efi. I don’t remember if the kernel is loaded at that point so a different pxe boot file could help.

The other thing to do is update the kernel and Init to the latest “experimental” versions. There’s a wizard to do it in the gui for both under the configuration menu. Then give it another go.

@fogcloud Pxe boot has to get to the boot.php file. It does this over port 80 or 443 if you have https enforced. When you enforce https ipxe is compiled with the fog ca and the certificate generated by said ca as trusted certs within your local version of ipxe.
I’m not quite sure what you mean by restricting access only to the web UI. Do you mean close all other ports? Because that will likely break tftp and nfs as they use other ports and imaging and pxe boot will be broken. ipxe itself will be fine if you’ve booted to it outside of native pxe boot where the ipxe boot file (i.e. ipxe.efi or snponly.efi) is downloaded via tftp. ipxe then downloads the boot.php file from the fog web server and boots to it to get to the fog pxe menu.

@MatMurdock You can also do a full host registration and that allows you to set the group and the snapin associations at registration and kick off the image from there.

I use the API powershell module (see my signature) and have created custom functions and powershell tools to manage most my assignments. That takes a bit more work to get setup at scale but gives you more customization options.

Starting fresh, well depends on how fresh, the best answer depends on how you’re going to use Fog. Like if these are all brand new computers that aren’t in any other system yet, then doing quick reg on them all might be best.
I myself do full registration and inventory for new hosts. If all your computers already exist on the network or in Active Directory you could get the host information and import. Many moons ago I made this host scanner example https://forums.fogproject.org/topic/9560/creating-a-csv-host-import-from-a-network-scan?_=1721413305258 that will create a csv of all hosts and their macs on your network in the provided subnets.
If you can get them all in before hand, then mass-setting the snapins would be much easier.

@MatMurdock A newly imaged machine will automatically deploy any assigned snapins.

The design is flexible and you can do it in many different ways but here’s a general example that would utilize a group.

• You have a group named ‘Group A’ with computers you want to image with the same image and join the domain in the same ou and have them use the same bunch of snapins
• You assign the image via group management, they all now have the same image
• You assign the AD information, they all now have the same AD info
• You assign some snapins, they all now have those snapins assigned (in addition to anything else those hosts already have assigned, you could also do a group remove of all snapins first if desired)
• You push the task to deploy or multicast deploy on the group
• All the machines in that group now have a deploy task for the image and a deploy task for the snapins associated

@MatMurdock That is correct.
If git pull gives you trouble (sometimes happens on upgrades) then do this within your git folder (i.e. /root/fogproject)

git fetch --all
git checkout working-1.6
git reset --hard origin/working-1.6
git pull

Then the cd bin and installfog.sh are good.

Also lols to CrowdStrike

@sideone https://forums.fogproject.org/topic/17575/snapins-not-downloading-to-client-hash-check-error just linking to your other post.

@MatMurdock Are you using the persistent groups plugin? When you set something in group management I believe it doesn’t save persistently unless you’re using that plugin. The idea is that you’re setting that settings on all hosts in that group the one time. I might be remembering that wrong, but that’s what I recall.

@nathan67 That sounds like the image doesn’t have the nvme driver.
There’s a potential easy solution, first check the bios settings on the nvme machine, if there are settings for intel VMD or intel optane make sure those are off. They require a different storage driver that isn’t including by default in windows.

You could also try recapturing the image from the nvme based machine

The more complicated solution involves recapturing the image and ensuring you use sysprep and add a set of basic storage drivers that don’t get wiped so they’re embedded and at the ready for multiple use cases. If the other options don’t work I can find some time to help with that. If it requires the intel vmd driver though, I’ve had experiences where that driver makes older non-vmd intel chipsets fail to boot. So I eventually gave up on having VMD enabled, it’s a pretty sweet feature and can add some performance, but not enough to matter for the operational complexity within a controlled and mixed business environment (at least that’s what I went with for me).

@IT-MAN
Where are you capturing your image and are you using sysprep to generalize the image without any drivers?

The only way for driver injection to work on the windows side automatically is to use sysprep via an unattend.xml. Well I guess technically setupcomplete.cmd may run after setup without it according to https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-custom-script-to-windows-setup?view=windows-11 but utilize sysprep and an unattend.xml is far more robust.

It is possible to inject just the driver files into the disk in a post download script but without sysprep to kick it off, you can run into issues.

This requires capturing your image with sysprep and an unattend.xml. One thing you can do with unattend.xml is remove the drivers from the image so that conflicting drivers don’t exist, then you can add the pnputil portion in the specialize phase of sysprep.

This post is what I used and I added some of what I’ve done on top of it that may be of help.

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection
Also this one
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

At a high level, driver injection being dynamic per model has some assumptions

• You captured an image that doesn’t have model specific drivers (this is easiest when capturing from a VM and using sysprep)
• You have drivers organized within your /images nfs share
• You have a postdownload script that detects the model, finds the drivers, mounts the windows disk, and then injects them into a known path
• You have a method to kick off a script that installs the drivers into windows
  • For example, I have a synchronouscommand in my specialize phase of my unattend that runs pnputil against the injected path, so drivers are loaded as early as possible in the process

@alexpolytech94 I’m still a bit confused. So have you had working images with fog in the past and they suddenly stopped working?

@paranoid64 Technically the menu is just ipxe, but when capturing or deploying images, getting hardware inventory, stuff like that you’re booting into fos which is in the kernel and init.
You can manually make a backup of the old kernel and init that can be just as easily restored. I believe in working-1.6 this happens automatically but to be safe you can just run this on your fog server linux terminal

sudo mv /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage.old
sudo mv /var/www/html/fog/service/ipxe/init.xz /var/www/html/fog/service/ipxe/init.xz.old

To revert you can simply reverse those like this

sudo mv -f /var/www/html/fog/service/ipxe/bzImage.old /var/www/html/fog/service/ipxe/bzImage
sudo mv -f /var/www/html/fog/service/ipxe/init.xz.old /var/www/html/fog/service/ipxe/init.xz

You can also name the new kernels different and specify a different kernel per host, but since this is happening before registration is recognized, it’ll be better to update globally to test it out. I am currently using the ‘experimental’ kernels in production with 0 issues.

Another thing to look at is some log files.
See if you have anything helpful in /var/log/php-fpm/www-error.log and post it here

@alessandro19884 Is that working-1.6? I would update your fog server, that error should be fixed in the latest version.

@paranoid64 Can you add the macs of the 4 intel lan ports to the host in the web ui? One of those macs may be being used to query the host. It should be able to see all of them and find the match but something is off.

You could try updating to the latest experimental kernel and init. If you update to the dev-branch or working-1.6 branch you can update the init in the web GUI or you can do it manually by downloading it from https://github.com/FOGProject/fos/releases and putting the init.xz on your server manually.
See also https://docs.fogproject.org/en/latest/manual-kernel-upgrade
The reason that might help is we recently added functionality for better handling of pass-thru macs. That’s not quite the case here, as it’s mostly for laptops that require a USB ethernet adapter to pxe boot, enabling mac address passthru in the bios/firmware of such systems now works as intended within fog with the new kernel and init as it will find the correct mac when there’s a passthru mac, but the new behavior may also benefit you here.

@steveballantyne Did you also update the Kernel and Init? What version fo FOG are you on?

@alexpolytech94

Firstly what version of Fog are you on?

Also are you saying that your images disappeared overnight? Or are you saying you can’t create just an image object in the web UI to then capture to?
We need a little more information and context I think

So this will not work for a few reasons, but it is possible to use windows.

Why it won’t work

When you boot into fog (FOS - Fog Operating System) it has loaded on the client machine.
The client machine then mounts an nfs share to upload/download an image from.
If your nfs share is pointing to another file share, the client only has access to the first NFS share, nfs won’t share out that smb share. I once tried to do something similar in a subfolder of /images for drivers. It has to be local.

However, it is possible to create a storage node that is just an nfs share, and you can create an nfs share on a windows machine (preferably a windows server install).

We need to update the this doc still to be in the fog docs site and to apply to newer versions of windows but the general principles outlined in this wiki article https://wiki.fogproject.org/wiki/index.php?title=Windows_Storage_Node should still apply.

Essentially you need to

• Add the nfs server feature/role to the windows machine
• Create an nfs share on windows
• add a storage node definition in fog that points to the windows nfs share (see also https://docs.fogproject.org/en/latest/storage-node for info on storage nodes in general)
• there are some other steps to ensure you capture to the storage node as you configure the storage group/node that I don’t recall off the top of my head

@Rudolf So Fog can do what you want there’s just a few steps you skipped.

Fog will essentially do the same idea of copying the SSD from one to another but in a more centralized manner with more customization capability.

Basically, you need to

• Install and configure the OS on a Virtual or Physical machine (virtual is easier to maintain if you already have a virtual infrastructure)
• Capture the image of that machine with fog
• Deploy the image to hosts

See https://docs.fogproject.org/en/latest/capture-an-image and https://docs.fogproject.org/en/latest/intro for some more info.

You can also expand further with customization of how you update your reference image, with windows there’s sysprep and other tools to help create a reference image, I’m sure linux has tools as well, I’m just not as well versed in them.

You can also edit the fog pxe menu to boot to an iso, I’m sure we have some examples in the forum for that.
There are also pre/post scripts so you can have a linux bash script that runs after an image is complete to do further customization of the image.

It sounds like Fog is the tool that will do what you’re trying to do, there’s just a bit more setup.

@Mr_____T I would also agree with @Tom-Elliott that the proxy dhcp with dnsmasq is the way to go. Especially with a router from your isp like that, it’s unlikely you’d be able to set those settings. I have seen the needed DHCP options on my Asus router at home but haven’t played with that just yet.

If you get us the particulars on that failure (error message, deploy or capture, os being deployed/captured, etc) we will gladly help with that too.