@sega I don’t know enough to answer your question intelligently.

I can tell you that for multicast imaging FOG uses the linux commands udpsend and udpreceive.

I don’t see any command line switches to pick which igmp mode is being used.
https://users.soe.ucsc.edu/~kent/test/udpcast.html

I can say its rare that there is ever a question on the revision of igmp being used.

The purpose of me using Capone for me is because we use all hps so I already have Capone configured to serve the golden image based off of the system-manufacturer matching HP

@theyikes Well the first thing I would do is look to see what the kernel name is in the casper directory. Ubuntu does change this kernel name from time to time. I do think the file name listed looks suspicious. I would expect something like vmlinuz without the extension. But look to see the kernel name and adjust accordingly.

@Tom-Elliott

You’re right, I created a storage group without making the storage node.

Here’s what I did:

Storage Management => New Storage Group => Storage_Group Snapin => New Snapin => Powershel script => Member of Storage_Group

The second part was to use the

$ALL_Snapins = Get-FogObject -type object -CoreObject snapin $ALL_Snapins.data $All_Snapins_Target = ($ALL_Snapin.snapins | where {$_.storagegroupname -like "Storage_Group"}).name

foreach ($ALL_Snapin in $ALL_Snapins)
{
Start-FogSnapin -hostID $FOG_HostID -snapinname ($ALL_Snapin.snapins | where {$_.storagegroupname -like “Storage_Group”}).name
}

@HorizonG said in FOG Golden Image, Sysprep and unattend post install:

’d also try renaming the post as explained:
with the command: sed -i “/ComputerName/s/*/$hostname/g” $unattend >/dev/null 2>&1

The variable $hostname comes from FOG, the variable $unattend must come from your script to define the location of the unattend file on the target hard drive.

Something to know, If you are questioning if each script is being called, place an echo some text at the top of each script. This way you can see each script being called.

One other tip I use for debugging post install scripts is to run a deployment in debug mode. Schedule a deployment, but before you hit the schedule task button tick the debug checkbox. Now schedule the task. PXE boot the target computer you will be met with several screens of text that you need to clear with the enter key. This will drop you at the fos linux command prompt. Now key in fog to start single stepping through the deployment. At the end of the image push you should see the post install scripts executing. If you use the debugPause; command at certain locations in your script you can stop the execution and wait to press enter. If you were to hit the ctrl-c key you can exit the deploy process. What this will do is give you the exact environment where your script is running. You can try different commands or fix the post deployment scripts. If you enter the command fog again you can restart the deployment process again without rebooting.

One last tip is that when you are interacting with the deployment process you are executing on screen 1, if you need command shell access you can press alt-f2 to go screen 2 run some comands and then pop back to screen 1 with alt-f1 to continue your script.

The pather location is the location where microsoft recommends you place the unattend.xml file, because it will look for the file there first. Where you get things confused is if you have an unattend.xml file in both locations because it will aways use the pather location first.

@Tom-Elliott said in 1.6.0-alpha.1377 not showing available images on host:

Now, we have heard occasionally people have UI loading slowdowns when they’re suing FOG Client in their environment and the number of machines and check in times are just too frequent for the FOG Server to keep up and respond to all of them.

Sounds about right, I’ve turned it to 5 minutes but maybe I’ll try it at 30 and see what happens. We have about 1300 host entries (although they’re probably not all active now) but most should be off during the summer holidays. Thanks

@Tom-Elliott Thank you for the response. That answers the question. I’ll consider the proposed workaround. I’m going to look into other options, such as keeping FOG on an isolated network, and the practicality of those options.

@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

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!

@zguo There are two things I can think of to create the initial error message.

You have the fog client installed and the services hasn’t been disabled before image capture. The fog client is starting to do its action before windows is fully installed. You have a driver install that is forcing a spontaneous (all of a sudden) reboot of the computer before windows is installed.

hello, i’m the original author of the Subnet Groups plugin: I wrote and committed the first version of its code back in 2019 (https://github.com/FOGProject/fogproject/pull/289).

i just wanted to inform you that in our environment (currently equipped with the last stable version of FOG) everything is working alright, we never had issues with the plugin even though we are used to update our systems on a regular basis.

as @Tom-Elliott mentioned, problems might arise due to incorrect IP addresses mapping: on our system, we had to set up a dynamic DNS server which has the job to automatically keep track of the actual host IPs based on their hostname; without this (or some alternative solution to correcly associate IPs with hosts) the plugin is not going to work properly.

best regards.

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

@elchapulin remove hibernation file (shown hidden files) or use sysprep
FOG won’t run with those on the system.

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. !

@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

I haven’t gotten around to it yet, sorry about that. unfortunately I’m only working part-time.
But without this one pc, fog is just great 🙂

@Cire3 Honestly we don’t know.

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

solved

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

Thank you for your answers

Disregard I was not selecting deploy image.

@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.