@george1421 Do you boot on MDT with en iPXE entry or did you make a new Task Type for it ?

@AUTH-IT-Center Should be addressed in the latest.

@Tom-Elliott me neither!

I have run a search on the server (Debian 11) and it appears I do not have one at all?

I found a couple of other posts saying to upgrade to the latest version. I have done that and it’s solved.

@Tom-Elliott @AUTH-IT-Center
Thank you both very much for the fast and detailed responses! NFS mountd was indeed the culprit. Port 20048 was allowed, but I wasn’t aware that this needed to be configured in the nfs.conf file. Confirmed that imaging is working now.

Thank you! My question has been answered. The server is connected to a KVM and is only a few steps away from where I work. I’m just following the general rule of only allowing what is necessary and since SSH isn’t necessary (yet), I’ll keep it blocked.

@AUTH-IT-Center with the dev-branch the created folder after the image capture has the correct permissions.

83223c8f-3d3a-46ab-af0b-c3634e6768ce-image.png

will wait for the update on stable branch to deploy to the production server.

Thank you!

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

@Tom-Elliott

Thanks Tom, that fixed it right up. I guess I overlooked that file when copying everything from the original /images.

Yeah, that fdrive number… 🙂 It is the serial number of the drive.

The NVME drives initialize differently each time during boot. I guess that is a thing, so nvme0 would sometimes be nvme1. It was a mess. Then I learned drive size could be used to differentiate between drives under Host Primary Disk. Now that both of my NVME drives are the same size, I have to use the drive serial number.

@HorizonG

Hello Sorry for the late reply, but I’ve deleted the host concerned and the problem is gone.

Using the latest experimental fos kernel I am able to deploy via task without issues. https://github.com/FOGProject/fos/releases/tag/EXP_20240720

Thank you all for your help in getting this to work.

This can be marked as Solved

Finally finished a brand new image this morning where we started from a fresh Windows install. The image captured without an issue. I suspect the age of our previous image was to blame for the issues with the capture. I think recent Windows updates by Microsoft to the recovery partition may have modified the size or something else in those recovery partitions.

New image pulled using the 6.6.34 Kernel, and then deployed successfully as well. If anyone is having issues related to the errors I posted above, I would try the CHKDSK + defrag/trim, and if that doesn’t work I recommend rebuilding your image from a clean Windows install with the absolute latest Windows enterprise installer.

Thank you Tom and crew for all the excellent technical assistance!

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 🙂

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

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!

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.