@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

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

@JJ-Fullmer Thank you, In the end I opted to add a second disk, structurewise couldn’t add the nfs,
Regards.

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

Thank you 2 for the assist. I figured it out. I had to add vendor arch 00009

solved

I disabled Windows 11 fast startup and the image could be captured.

Thank you for your answers

@bsedash You are going to have two areas where you will have difficulty here.

You re using an older version of FOG and FOS kernels. Newer hardware support will be missing. FOG is primarly focused on desktop imaging and you are trying to image a server class hardware. I’m not saying its impossible to use fog for this, you might just need a custom kernel that has the qlogic network driver enabled.

Where the booting process is failing is where iPXE tries to get an IP address. This is where ipxe boots and then tries to get an ip address, none is received. FIrst make sure you are using nic1 on the server since this ipxe build is configured for workstation class computers and it will stop looking after the 3rd found network interface. Also since you are using fog 1.5.9 the version of delivered ipxe is quite old. Lets recompile and install the latest version of iPXE. If that gets you to the fog iPXE menu then that will solve the first problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

For the next problem, update the fos linux kernel (bzImage) but going to the webui and fog configuration -> kernel update. Update to the latest 6.x kernel to get the latest hardware support.

@kylian001 Yeah I am thanks for the help. How do I mark this as solved?

@Tauric I don’t think any amount of rollback is necessary, but you’re more than welcome to. Pretty sure there weren’t any schema updates or major component changes between 1.5.10 and 1.5.10.34

that said, this looks more like a problem with the kernel, not a problem with FOG and its ability to capture/deploy images.

You could download the kernels from the FOG GUI Kernel Updates

@EuroEnglish I haven’t been able to recreate the issue. I would suggest maybe trying an update to the kernel and init, if you’re on the latest dev-branch version there should be a July 5th dated bzImage and Init available from the fog configuration kernel update and init update menus.
The only other things I can think of might be your Windows 11 partition layout being non standard or something? It should all be booted into RAM at that point though, so that doesn’t make much sense, but it’s possible that the efi partition is too small or something, that’s just a hairbrained theory though. Other thing could be a custom background image? Maybe it stops liking the size of it?

Hopefully trying the newer kernel just solves the problem though.

@maximefog said in Deploy Image:

it is mandatory to register the workstation

This is not a requirement under certain conditions. There is a method I call “load and go”. It is a process that system builders use where once they load the OS on the target computer they never see the computer again. In this method you can not use the FOG Client for any of its function. The install process must be self contained or use a FOG post install script to make the install time adjustments to the target computer. Using this method you do not need to register the computer with FOG. Once the image is deployed to the target computer FOG forgets it ever saw this target computer. Once you have the master image setup as needed you deploy the image from the FOG iPXE menu “Deploy Image” menu. You never have to touch the FOG web ui for image deployment.

@Bhav Just for clarity, do you have an isolated imaging network or are you trying to image on your business network?

If you have an isolated imaging network then you should have configured FOG to setup a dhcp server. The configuration will work for both bios and uefi computers.

If you plan to image on an existing business network, then your primary dhcp server needs to be configured to support pxe booting.

So lets start with how do you plan on imaging?
Second if you are planning on imaging using your business network, what device is your current dhcp server?

@Tom-Elliott I had to reinstall my ubuntu server and installed the fogproject as you suggested. However, the installation still wasn’t able to run to the end. I have attached the error log. I do appreciate your assistance.fogserver error log.txt

Finaly i have reinstalled my server again and just take exports from all sections (snapins, images etc…)

only gruops not working. nevermind ill setup again.

the problem was about the whole configuration with ISCSI disk attach, now i use an NFS and directly mount my image storage on /image.

works like a charm.

see yann

yann

@george1421
I resolved the issue by testing 1.5.10 on a laptop after trial and error I am able to have the same setup as our desktop environment. I will most likely upgrade our desktop server to 1.5.10 and recapture a new golden image.

@processor You set the replicator sleep time (and sleep time for all services.)

FOG Configuration -> FOG Settings -> FOG_IMAGEREPSLEEPTIME

It’s defaulted to 600 (10 minute cycles.)
If you set it to 86400, that should do the checks once per day.

@professorb24 said in How to use fog with two different VLANs:

Yes, I can ping the 192.168.54.X network.

This is positive. OK hopefully last question, what is device the dhcp server on the 54.x subnet? Is it the fog server on the 52.x subnet or something else?

@Tom-Elliott @george1421 I’ve done it, Winscp’d the files from my PC build lab FOG and added them to the directory on the SRV build lab FOG… PXE now working!!! woop

@Nicolas-Bricet This really sounds like a spanning tree issue vs dot1x authentication (unless your authentication process is taking a really long time to authenticate the port). Make sure the port is configured for port-fast, fast-stp, rstp or whatever your switch manufacturer calls it.

Secondly if TIME is the resolution then this can probably be addressed too.

First of all we have the ability to update the iPXE boot loader from a fog install. This tutorial is intended to solve a different problem but you will need this in your solution: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

So at this point you know that you can rebuild iPXE right from your fog server. Now we need to adjust iPXE to wait 30 seconds before requesting an IP address (FWIW, by default spanning tree it take 27 seconds to start forwarding data, so the timing is suspiciously similar).
When iPXE boots up it runs a FOG custom script file that tells iPXE how to configure itself. If you can remember back to the DOS days, this was the autoexec.bat files function. iPXE has a similar script. Within the iPXE source directory the file is call ipxescript (a look on github) https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript#L1 This is the script that runs inside iPXE to configure the network.

To take this concept one step more, the FOG developers have already created a version of the iPXE that has a 10 second boot delay (remember you need a 30 second delay). An example of this 10 second delay startup is here: https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript10sec#L3 All you need to do is either update that 10 to a 30 or copy that line over to the ipxescript main script and change it to 30. Once that is done recompile ipxe using the instructions above.

The FOG delivered 10second delay versions of iPXE are located in the /tftpboot/10seconds directory. So you have two paths to get this done, but I would surely look into spanning tree first to make sure port fast is enabled and make the above second way unnecessary.