@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

@robertkwild The issue most likely is not coming from the flip of Secureboot On/Off.

Unsigned or test-signed boot drivers. This is where a real BSOD can happen. If the machine has bcdedit /set testsigning on or nointegritychecks, and a boot-start driver depends on that (an unsigned storage or RAID driver, some sketchy anti-cheat, a dev build), turning Secure Boot on makes those settings get ignored. If the storage driver doesn’t load, you get INACCESSIBLE_BOOT_DEVICE. That one only happens in the off-to-on direction.

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.

Now I read the AI summary and got what I need:

It stores one row for each address in the hostNetwork table. Limits of this method The sleeping host must run fog-agent. The server uses the sleeping host’s own last report to find its subnet. A host with the legacy FOG Client, or with no client, has no rows, so the relay cannot help it. The old path still runs for it.

So If I populate the hostNetwork table for the hosts that I need manually, It will work. Thank you for the details.

@Paladin1 Thanks, that explains the registration error. Registration reads the machine’s disk, so it needs a disk attached. With no disk it stops with that message every time. That is expected, so you do not need the debug task.

For your question: neither. Do not reinstall anything yet.

The BIOS boot mode on this machine applies to both the network boot and the installed OS. Your image is a UEFI install, so this machine has to network boot in UEFI too. We can try a different iPXE file for UEFI that loads its own network driver. That can avoid the firmware error.

On the FOG server:

Edit /etc/kea/kea-dhcp4.conf. In the classes FOG-UEFI-64-1, FOG-UEFI-64-2, FOG-UEFI-64-3 and FOG-Surface-Pro-4, change "boot-file-name": "snponly.efi" to "boot-file-name": "ipxe.efi". Run sudo systemctl restart kea-dhcp4-server. Set the target BIOS back to UEFI and network boot it.

Tell us if you get the FOG menu or the same ASSERT. If it fails, change the file back. A re-run of the installer also puts snponly.efi back.

@Tom-Elliott said in Login to delete image not passing correct username.:

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

I attempted to migrate to the 1.6…my server looks like it just migrated from 1.5 to the same 1.5 version, but it does look like it cleared up whatever issue it was having. Feel free to close this ticket.

Thanks

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

@astrugatch I don’t think it matters really. The issue was more about the initial pinning of the certificate during the install process. After it is pinned I think this is the correct expectation (it should only communicate to the FOG server over HTTPS).

@Tom-Elliott
thanks it was lighttpd so i purged it

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

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

@Tom-Elliott
Hi!
I have updated to the latest dev-branch version.
No more updating database … failed error.
The multicast session closing the right way.

Thank you!

Awesome and thank you. Confirmed working.

@ahaeder A final setting - you have to set Bios exit type = GRUB (not the default SANBOOT) or the boot hangs at ‘Booting from SAN device’.

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

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

Hi Tom,

In my case the culprit was /images/postdownloadscripts/fog.postdownload.

echo "Activating boot partition..." sfdisk --activate /dev/sda 1 echo "Rebooting..." reboot -f

Fix was simply commenting out (or deleting) those lines. After cleanup the file looks like this:

cat /images/postdownloadscripts/fog.postdownload #!/bin/bash ## This file serves as a starting point to call your custom postimaging scripts. ## <SCRIPTNAME> should be changed to the script you're planning to use. ## Syntax of post download scripts are #. ${postdownpath}<SCRIPTNAME>

Thanks for the pointer, Tom — saved me from chasing GPT partition tables for a problem that had nothing to do with them.

@servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.

The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.

There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.

The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.

It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773

It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.