Just replying to this with some updated information after my latest upgrade to Ubuntu 20.04 so I don’t forget on the next upgrade. I couldn’t get the fog installer to work without the -X option but figured out what the issue was. I needed to edit the /etc/pam.d/common-password file and change the following line to 10000 instead of 1000.

password [success=3 default=ignore] pam_krb5.so minimum_uid=1000

This was because the fogproject user was more than 1000, so changing it to 10000 let the installer work without needing the -X option and the password was updated properly. I then switched it back to 1000 so kerberos would work with my AD accounts.

@george1421

I installed fully new OS on a PC.

I get a new error message.
20240821_114507.jpg

@kalmarteve How did you delete the old FOG? It looks like the web server folder still exists and the database probably still exists.

This wiki article outlines a method for fully removing FOG if you’re looking for a fresh install.

https://wiki.fogproject.org/wiki/index.php/Uninstall_FOG

If you have a backup you can restore too, you should also be able to just do an in-place upgrade.

@berenyia

What switch, and what network card? I’ve been seeing a similar issue, I’m working on a theory as to what is happening. I’m not currently at work so I can’t be sure yet on my replies to those questions but I’ll let you know

@kalmarteve so you’re running 1.5.9

the “master” branch is on 1.5.10

While the 2 files may not have been changed, you should really install the latest version if you’re going to try to implant files from newer version on your fog server.

That said, since it doesn’t seem broken (from a usability) standpoint, i’m not sure what question you’re asking.

I don’t know how to fix the problem if you haven’t tried the suggestions.

For example “This number of slots available” is based on the Storage node.

This is configured from the UI.

I don’t know what you did or didn’t do and can’t really provide much more direction than make sure the node that is in use (since you’re not providing IPs I cannot really give any more information).

@Tom-Elliott Thank you

Took me a while to circle back to this, but it’s nice to have it working as expected.

@falko I have added our own version of str_contains if the php library doesn’t already contain it. This is in latest.

Thank you!

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