@Paladin1 Thanks for the report. You’re right, the docs were out of date.

The installer now asks Install/update the FOG database schema now? (Y/n) and does the schema update itself when you answer yes, which is the default. The browser step only applies if you answer no.

The “Denied” you saw is expected on a new install. With no FOG users yet, the schema page only accepts the link the installer prints, which ends in &fogtoken=.... On an existing install, you log in as an admin instead.

The install pages are updated for both versions:

1.5: https://docs.fogproject.org/en/latest/1.5/installation/server/install-fog-server/ 1.6: https://docs.fogproject.org/en/latest/1.6/installation/server/install-fog-server/

@fierke A correction to my last post. The fix is now merged into working-1.6 and rc-1.6.0. Update your checkout and re-run the installer. The installer now writes default.ipxe without those two lines, so you do not need to comment them out again.

You are right that this can happen on other machines too. Any UEFI firmware that never ends its variable list hangs the same way. The update fixes it for all of them.

I would still like the show efi/SecureBoot result and your BIOS version when you have time. That confirms the cause before the iPXE side ships.

@jmeyer This is a bug in schema step 284 on MySQL. Your data did not cause it.

Cause: on MySQL, an ALTER TABLE re-checks the default of every column. Your hosts.hostSecTime still has the old default 0000-00-00 00:00:00. MySQL’s default sql_mode (NO_ZERO_DATE) refuses that default, so the step stops. MariaDB servers do not show the problem.

Fix: https://github.com/FOGProject/fogproject/pull/1838 is merged into dev-branch. While the steps run, the schema updater now relaxes the zero-date check for its own session.

The fix reaches the stable release on October 11. To continue now, install from dev-branch:

cd /root git clone -b dev-branch https://github.com/FOGProject/fogproject.git fogproject-dev cd fogproject-dev/bin ./installfog.sh -y

The failed step changed nothing in your database, so you do not need to restore the backup. The backup the installer made is still at /home/fogDBbackups/fog_sql_1.5.10.2482_20261009_113907.sql.

@Tom-Elliott
Hi, the new EXP_20261001-163131 work like a charm without the postinit workaround. Thank you!

@mmaus Would you mind updating to the latest RC or even the working-1.6 branch, if that’s too much a leap, what about upgrading to dev-branch? (It will become stable on Sunday if I recall the timing correctly.) See if we already fixed the problem you’re seeing?

@Tom-Elliott I wondered if that was the case, thank you.

This is a bug in the version check on 1.5.10.2482, not in your install. Your version is current, and you can ignore the banner.

The check takes the first tag in GitHub’s tag list as the latest stable release. Newer tags (an archive tag and the 1.6.0 release candidates) now sort ahead of 1.5.10.2482, so every stable install shows this warning.

The fix is merged to dev-branch (https://github.com/FOGProject/fogproject/pull/1823). It asks fogproject.org for the current versions instead. It ships in the next stable release.

@Tom-Elliott So I’ve copied my /opt/fog/snapins/ssl folder, and the ca-key in /etc/fog/pki/root/ca/ folders, then followed your advice above and re-ran the installer. The legacy agent still won’t communicate consistently it seems. Our existing agent seem to be communicating I think, but fresh installs of the legacy agent are having nothing but issues from what my team are telling me.

Hi @Tom-Elliott
After moving from RC-2 to RC-4 the plugin, the WinPE image and the step that closes the task at the end of the WinPE flow all kept working. Only the Apache part needed a change.

With RC-4 the whole vhost sits inside FOG’s managed block, so my earlier Alias plus rewrite exception was gone and /fog/winpe_3400/wimboot started answering 308 (FOG’s rewrite rule sends it to the API). Instead of putting the exception back, I now serve the files from /winpe_3400/ (no /fog/ prefix), with an Alias and a <Directory> in a separate conf-available file enabled with a2enconf. FOG’s rewrite rule only matches /fog/, so it never sees these requests, and nothing in 001-fog.conf should need restoring after an update. The only change in the plugin is its WIMBOOT_HTTP_PATH constant.

Checked after the change: the Latitude fetches wimboot, BCD, boot.sdi and boot.wim from the new path (all 200), WinPE starts, and a full deploy on the Latitude 3400 and one on an HP with the normal FOS/Partclone flow both completed and closed their tasks.

@Cpasjuste I just wanted to let you know that I’ve added in your method of using userland NFS support to my container. I have given you credit for the method in the README. I’d love for you to test it out if/when you get a chance. Thank you again for your work!

@Tom-Elliott
These are the two machines that were just cloned!

I deployed the Snap-in three times:
the two newly cloned machines and one old machine to see if any certificate issues arise with the old computers. All of them were assigned Image B.

The computer, which has not yet been cloned, did not process the snap-in.

ec06f2be-575a-48f2-9f68-3a9f156dd330-grafik.png

------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 28.09.2026 07:38:56 Client-Info Version: 0.13.0 28.09.2026 07:38:56 Client-Info OS: Windows 28.09.2026 07:38:56 Middleware::Authentication Waiting for authentication timeout to pass 28.09.2026 07:40:56 Middleware::Communication Download: http://192.168.0.196/fog/management/other/ssl/srvpublic.crt 28.09.2026 07:40:58 Middleware::Communication ERROR: Could not download file 28.09.2026 07:40:58 Middleware::Communication ERROR: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. 28.09.2026 07:40:58 Client-Info ERROR: Failed to authenticate, will not run Module Looper.

78935d01-cc19-4dd8-b5bc-fb03e7885c58-grafik.png
Resetting the encryption settings, deleting the snap-in that wasn’t running, and restarting it didn’t help…

Rebooting of the pc helped