Ok, as I hate people that don’t come back. I try my best not to be that guy.

FOG problem = Nope… As usual.

Problem with dropouts, scrambled data. Proxmox 8 is very angry with my onboard nic. It uploads without issue (and very fast I may say) But deployment it just crapped out. Every time it re-connected, Fog just tried to do it’s job over and over. The blast of data just shut the nic down.

Finally found this looking in the Proxmox log. Found ethernet adapter hang detected, then reset.

Also a great excuse to finally order that dual 10Gb card. She’s happy now running full speed. Hopefully faster when the 10Gb switch shows up 🙂

Thanks to all that looked over this, and even more for the reply. !

@El-Fogito So with that can you reboot the machine (outside of the task) and perform a chkdisk /f on it, then disable the hibernation:
powercfg.exe /h off

Then attempt again? I apologize in advance

@PierreM59 If the computer cannot operate on HTTPS sites, and is using current software, I don’t know there’s anything we can provide to help you.

“Some work and some don’t” seems contradictory. While sites will use different versions of certificates, the fact that you cannot even reach the site tells me you are behind some kind of “gate access” preventing you from even reaching the “some don’t” category.

If you take that same machine, and run it on a network other than where you are currently, does it have the exact same problems? If it does, then is this “gateway” that’s preventing access likely installed locally on the machine? If it doesn’t have the same problems, then it’s the network from where you’re currently operating.

@Tom-Elliott Was going to try, but discovered that after the last CHKDSK, the FOG Client wasn’t running correctly. Now I can’t uninstall or reinstall it correctly. I think for now I am going to re-create this image from scratch. I am speculating that since this was an older image that we had added onto several times, that a Windows update of some kind caused partition issues of some sort. I plan to format and install Windows from Scratch, and then build the image and pull it tomorrow. If this works I will report back with my findings.

In the meantime, are there any logs that I could send that would help you or anyone else who also finds themselves having this issue? Happy to assist in any way I can. I sincerely appreciate all the support and assistance on this.

@Tom-Elliott

Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!

OK. I wrote a trigger that will pull the IP of the client from the history table and add the host to appropriate group based on the subnetgroup table. To test I exported my history table, truncated it and reimported the records with the trigger in place. Seemed to do the job. Files are attached if anyone wants them.

Mat

fog.sql

It does look like things are working. I added a host to a group and then did a simple Basic task in the group and it pushed it out to the host. Now I just need to figure out a way to get hosts assigned to groups based on IP.

We have like 600 systems to image so trying to automate as much as I can.

Mat

@Tom-Elliott version .41 has solved the issue. Thank you so much!

@Cire3 Honestly we don’t know.

The information didn’t make sense to any specific “thing” being wrong or what even truly was wrong.

I just had this issue with a few HP models. If you look in the bios, do you have an option to use a unique system mac address OR adapter address? That one drove me nuts for a minute…

It’s great if you use a dongle so you aren’t accidentally uploading over the wrong image due to using the dongles MAC address. But it’s only great when you remember it’s a setting.

When I get off lease systems in, I like to clear the bios and security settings to factory. However doing so will set it to use a system unique MAC address during pxe boot and not the ethernet address.

I think it’s only on business class models without a lan port.

Hope it helps.

@george1421 Every time I think I’m a nerd, I see George break down a setting in a 3 paragraphs, dissecting it in the craziest detail.

You guys rock. That level of detail is seriously helpful. Allowing us to learn other things in the process to help us later. When I see that effort to help someone, I just like to call it out !

I’m the kind of guy that needs to take everything apart to see how it all works. You guys definitely help to paint the picture.

@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