@WielandPP1 Thanks for the log line. It shows the cause exactly.

PHP 8 is supported, so you do not need a different PHP version. The problem is a missing PHP extension. On Linux Mint, the installer adds the ondrej PHP repository. In that repository, php-fpm installs PHP 8.4, but php-ssh2 installs the ssh2 extension for PHP 8.5. Your web server runs PHP 8.4, so ssh2_connect() does not exist and the snapin upload fails.

To fix your server now, install the ssh2 extension for PHP 8.4 and restart PHP-FPM:

sudo apt-get install php8.4-ssh2 sudo systemctl restart php8.4-fpm

Then try the snapin upload again.

We are also fixing the installer in working-1.6 and rc-1.6.0:

The installer installs the ssh2 extension for the PHP version that PHP-FPM runs. On Linux Mint, the installer uses the distribution’s own PHP, as it already does on Ubuntu and Debian. If the extension is missing, the upload shows “SSH Connection has failed” instead of a 500 error.

@piaFOG26 One more item, about the “Access Denied” in the disk usage box on the VM dashboard.

Your VM and your master node are two full FOG servers, and each has its own database. The master node only trusts requests from the storage nodes in its own database, so it refuses the VM. I fixed this in FOG: a request signed with a shared node key is now accepted. The fix is on dev-branch now and reaches the stable release on November 11.

To use it, both servers must have the same key. First, finish the schema update on the master node. Then:

Make a key on either machine: openssl rand -hex 32 On the VM, open Storage Management, then edit the master node (NComun). Paste the key into Node API Signing Key and click Update. On the master node, run this from the fogproject folder you installed from: sudo php bin/fog-node-key.php --set <the same key>

If you need it before November 11, install dev-branch on the master node. The fix must be on the master node, because that is the server that checks the key.

@Tom-Elliott sorry tom yes i am, sorry for the late reply, tbh i think its just hp machines that do this

@Tom-Elliott

Thank you!

As you thought, it was a double DHCP server… Even though .6 was in bridge mode, the DHCP server on it was still enabled, unlike the other MikroTik switches we have. Disabling it brought the iPXE booting back. I’ve run a re-inventory task and am now running an image capture task.

I’ll have to keep a future eye open for that as we expand our classroom network.

Cheers!

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

@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

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

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

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

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

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

This can be closed. Thank you.

Awesome and thank you. Confirmed working.

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.

@mp12 Thanks for the logs. This is a bug in 1.5.10.2482, not your node passwords.

A security change in 2482 removes the storage node password from the node data that the API returns. The image and snapin replicators read their node list from that same data. So they now send an empty password, and every node rejects the login. The Undefined property: stdClass::$pass warning is that missing field.

The fix is merged to dev-branch: https://github.com/FOGProject/fogproject/pull/1770

To get it now, update from dev-branch:

cd /path/to/fogproject git checkout dev-branch git pull cd bin sudo ./installfog.sh -y

Or wait for the next stable release. Your stored passwords are correct, so you do not need to change anything on the nodes.