@Shuttleu Thank you for testing on the HP. That confirms the fix on real firmware.

The task error after a menu enrollment. This is a FOS bug, not the agent. The menu item runs the enrollment with no task scheduled. When the enrollment finishes, FOS tries to close the task. The server answers “No Active Task found”, and FOS shows an error. The enrollment itself succeeded. The fix is in FOS release 20261106-134043. After a menu run, FOS now says that no task is scheduled and ends normally. The server records the enrollment on the host only when you schedule the task from the web UI.

FOG Agent. You found the cause. Uninstall keeps C:\ProgramData\FOG on purpose. It holds the machine’s key, its certificate and the trusted CA, so a reinstall keeps the same identity. The reinstall kept the CA of your earlier server, so every connection failed and the token was never used. Agent v0.1.21 fixes this. Setup now checks the stored trust against the server. If it no longer verifies, setup settles trust again like a first install, and the host enrolls again with the token. Until you install v0.1.21, deleting C:\ProgramData\FOG before the reinstall is the right workaround.

Your server certificate comes from your company CA, which Windows already trusts. So no fingerprint is needed, as the probe said. Leave CAFINGERPRINT out on these machines.

@Tom-Elliott

Hopefully I’ll have the answer to that question within the next two weeks!

@fgaudin Good to hear it works.

UEFI alone does not need secureboot=1. The setting is only for computers that have Secure Boot turned on in the firmware. With secureboot=0, FOG does not sign its boot files, and a computer with Secure Boot on refuses to boot them.

If Secure Boot is off on your computers, keep secureboot='0'. If Secure Boot is on, set secureboot='1' and run ./installfog.sh -y. Do not use -C or -K. Each computer then enrolls the FOG key one time at its first PXE boot.

Install sudo before you set it to 1. The Secure Boot signing helper needs /etc/sudoers.d.

@Tom-Elliott All is working now

Hey Tom, updated to 1.6.0.97 this morning and everything checks out:

Exports: migrated to /etc/exports.d/fog.exports, and my kubuntu.exports came through untouched.
SSH keys: fog@fogger key landed in authorized_keys, works on my custom port. Pulled the Match password exception, so the box is key-only again.
Dashboard: 1.5 history is back, and the Nov 3 runs are on Nov 3 now.
Capture: new capture shows local time, no asterisk, and moved out of /images/dev over the key with no errors in the log.
Ports: FOG_SSH_PORT now shows up under FOG Settings → General Settings with my 2416, and the per-node fields are blank, so it falls back to that.

Seriously impressive turnaround. Thanks for taking the reports seriously and running with them!

@Tom-Elliott Hey Tom, updated to 1.6.0.97 this morning and everything checks out:

Exports: migrated to /etc/exports.d/fog.exports, and my kubuntu.exports came through untouched.
SSH keys: fog@fogger key landed in authorized_keys, works on my custom port. Pulled the Match password exception, so the box is key-only again.
Dashboard: 1.5 history is back, and the Nov 3 runs are on Nov 3 now.
Capture: new capture shows local time, no asterisk, and moved out of /images/dev over the key with no errors in the log.
Ports: FOG_SSH_PORT now shows up under FOG Settings → General Settings with my port, and the per-node fields are blank, so it falls back to that.

Seriously impressive turnaround. Thanks for taking the reports seriously and running with them!

@Tom-Elliott All good! Thank you and keep up the awesome work!

@rogalskij Glad to be of help and your finding did notice an issue that was also addressed on the dev-branch so thank you!

@Tom-Elliott As always, thanks for the answer and quick fix 😊

@Tom-Elliott Thanks fo the quick reply!
I did rerun the installer today and it seems to be working now, thanks a lot for the quick feedback and fix!

@Coolguy3289 I believe we fixed the problem, please confirm and I can solve this thread, thank you!

@piaFOG26 Are you able to confirm if things are now working for you?

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