Managed to figure it out after looking in the wiki for instructions to uninstall FOG with the intention of reinstalling it. Delete that file, delete the fogproject user, and run the install script again. Now it works.

@gabriel-pissoto

I often record this with a phone then you can pick out the error in that micro flash of text.
I think most of the time picking a different X.pxe file resolves this for me.

@Nono Without going through the web interface you can check the file in /var/www/fog/lib/fog/system.class.php.
Toward the bottom of the file there is a line that start with define('FOG_VERSION'

@hammerc807

This is what I had to do, was in the same boat.

Go to /opt/fog/.fogsettings

Remove the sysv-rc-conf entry from the packages line from there. (Reference: https://github.com/FOGProject/fogproject/issues/797)

Lower down in the same file, set “php_ver=‘8.2’” to “php_ver=‘8.4’”

Exit and save.

Then I had to remove symlinks in Apache that were using the old php modules:

sudo unlink /etc/apache2/mods-enabled/php8.2.conf
sudo unlink /etc/apache2/mods-enabled/php8.2.load

Then add the new links:

sudo ln -s /etc/apache2/mods-available/php8.4.conf /etc/apache2/mods-enabled/php8.4.conf
sudo ln -s /etc/apache2/mods-available/php8.4.load /etc/apache2/mods-enabled/php8.4.load

@bond007fink A new version of ntfs-3g, which is the parent package for ntfsresize, has finally been released last week. That’s after 4 years of no updates. If all goes well, I will be doing an experimental release this weekend with the newer package.

As @Tom-Elliott stated, this is not an issue with FOG itself, instead FOG relies on tools like ntfs-3g and partclone to handle all the NTFS filesystem changes. Hopefully this updated version fixes your issue.
I will update the thread once the experimental release is available.

@Tom-Elliott

This is fixed, too, and can be marked as solved. The reason was stale WOL power action. I deleted those manually from the DB, and the CPU went back to normal.

I’m not sure about the SSH and replication issues, but I deleted my physical storage node, and I’m not seeing those anymore.

@mashina Ah, thank you for that and sorry for my denseness. Indeed this is a bug and I’ve replicated and figured out where this is occurring.

I have pushed a few mroe adjustments in an attempt find and fix more bugs (thanks AI review and whatnot)

Please pull and let me know if there’s any other issues.

@mashina
I’m still having huge problems. Updated Fog. Rebuilt the Windows 11 image. … Windows 11 changes the boot order.
The image works for a few days—then it stops working.
Multicast only works sometimes—just now the image worked with one computer, but not with three in multicast—it just stops at 94% for no reason. What surprises me the most is that with this computer, only BOOT EXIT TYPE: SANBOOT works. I don’t understand much about this, but it seems wrong to me.

@Bhav There is not at this point in time.

Secure boot is meant to be… well, secure.

There are people attempting to get there, but I can say, right now, FOG just isn’t there right now.

On the forums you can see this at:
https://forums.fogproject.org/topic/17949/fog-secure-boot-with-shim

Which might help lead you in the direction as well hopefully.

@heix75 No.

Not because it’s not a QOL improvement (it is) but because what you see in 1.5.x.x is NOT what is the end goal.

If you want to see what the UX is moving toward install the version of FOG on working-1.6.

You’ll understand (I hope), then, why I’m saying this.

@pillbox1234567 Thanks for the suggestion. I turned Viridian off on the cloned VM, and it did not make a difference.

Interesting note that you’ve seen it cause boot issues on certain Linux VMs. I have not experienced that behavior yet but will keep an eye out for it.

@Preston Wow that was a super answer, thanks Preston! I’ll give this a go in the week. 🙂

@Exsival When you say “Causing the fog server to crash” what exactly do you mean?

If it’s just a “saying” I can understand that but from a technical standpoint what this means is completely different and would need logs. If all you mean is the machine in quesiton is hanging, that’s a different issue altogether. I highly doubt the whole FOG Server is crashing.

@lucamathuse No, I would not move the files manually yet.

If the capture reports “Cloned successfully” but the task remains In-Progress, then the capture itself may have finished, but the post-capture process is not completing correctly. Under normal conditions, the host should finish the task and then reboot or shut down automatically based on your settings.

So, before moving anything by hand, I would want to know whether the host is actually stuck there indefinitely or whether it is still finishing something in the background. If it never updates the task status, that could also explain why your image set ends up incomplete or inconsistent.