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

@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

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.

@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

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

@Tom-Elliott I figured it was more-so on the internal end of things that we had to take care. But, wanted to make sure. Thank you for your response!

Thanks @Tom-Elliott . That actually makes a lot more sense now. 😁

I saw the greyed-out “Mass edit” button, but hadn’t worked out that I had to select multiple items (turn them blue) from the filtered list of hosts in order to be able to use that button to set values across multiple entries. Once I did, it worked as intended.

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

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

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

@delacroix fixparts went missing from FOS during a Buildroot update. The fix (fos#195) landed yesterday, and the first build with it is EXP_20261021-160109. I checked that release: /usr/sbin/fixparts is present in init.xz, init_32.xz, and arm_init.cpio.gz.

Your debug task boots the init that your FOG server serves, not the one you downloaded. Put the new file in place on the server:

cd /var/www/html/fog/service/ipxe mv init.xz init.xz.old wget https://github.com/FOGProject/fos/releases/download/EXP_20261021-160109/init.xz sha256sum init.xz

The hash must match the init.xz.sha256 on the release page (it starts 8e3457ad4268add5). To check the content without a boot:

xz -dc init.xz > /tmp/init.img debugfs -R "ls -l /usr/sbin" /tmp/init.img | grep fixparts

Then run the capture again. If fixparts is in that listing and the capture still fails, please post the output of fixparts /dev/sdX (or /dev/nvme0n1) from a debug task.

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