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

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

@Dominique I can’t promise that, no.

1.5.10 is the original release, and it is a long way behind now. It was built and tested against PHP 7.x. It may run fine on PHP 8, but I don’t know which PHP 8 version, if any, would be safe for it.

What we do know works on PHP 8 is the current stable branch. Here is how the branches fit together:

master is the official 1.5.10 release. We don’t work on it directly. dev-branch is where all the bug fixes and maintenance happen. stable gets everything from dev-branch rolled into it once a month.

So stable is 1.5.10 plus a few years of fixes, PHP 8 support among them.

If you want to move to PHP 8 before 1.6.0 comes out, I’d do it in this order:

Snapshot the server first, so you can roll back. Update FOG to the stable branch and run the installer. Do this while you are still on PHP 7.2. Then move PHP to 8.2. On Red Hat 8 the installer will not do that for you; it installs whichever PHP module is enabled. Run dnf module reset php then dnf module enable php:8.2, then dnf distro-sync. Re-run the FOG installer, so it picks up the new PHP packages. Test the web console, a host registration, and a unicast and a multicast deploy before you call it done.

Since this is production, your plan to wait for 1.6.0 and try the RC in a test environment first is a good one too.

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

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

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

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

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

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

@astrugatch Short answer: no, the existing FOG Client does not pull the agent by itself. You push the agent with the tool you already use to deploy software.

What happens when you upgrade the server

Your legacy FOG Client installs keep working against 1.6. The server still serves the legacy client endpoints, so you can run both while you migrate. Nothing on the server needs to change first. Hosts, groups, snapins, printers, power schedules and module settings all carry over. The legacy Client Updater module is gone in 1.6. So the old client cannot update itself into the agent. The FOG server does not host the agent installer. It comes from the GitHub releases page: https://github.com/FOGProject/fog-agent/releases/latest

How to move a machine to the agent

Install the agent MSI on the machine. The MSI finds the legacy “FOG Service” and removes it for you. Do not run the two side by side.

For a silent push (GPO, PDQ, SCCM/Intune, or a script):

msiexec /i fog-agent-<version>-x64.msi /qn SERVER=https://your-fog-server/fog CAFINGERPRINT=<fingerprint> TOKEN=<token> /l*v C:\fog-agent-install.log SERVER is your web UI address with /fog on the end. Old scripts that use WEBADDRESS and WEBROOT still work. CAFINGERPRINT is the SHA-256 on the Root row of FOG Configuration → Certificates. Leave it out if your web UI uses a public or corporate certificate that the machines already trust. TOKEN is optional. Create one under Hosts → Agent Enrollment Tokens. With a token, the host enrolls with no click. Without one, each host waits under Hosts → Pending Agents until you approve it.

The FOG Client page in the 1.6 main menu shows the same command with your server address already filled in.

Images

You can put the agent in your image. Capture the machine as it is, no sysprep needed. A deployed clone detects that it is a different machine and enrolls as itself. If FOG deployed to that host in the last 24 hours, the server approves it automatically.

Docs

Install and migrate: https://docs.fogproject.org/en/latest/installation/client/install-fog-agent (see “Moving from the legacy client”) What changes for an admin (printers, AD join, user tracking): https://docs.fogproject.org/en/latest/management/web/fog-agent Reference: https://docs.fogproject.org/en/latest/kb/reference/fog-agent-reference Troubleshooting: https://docs.fogproject.org/en/latest/kb/troubleshooting/fog-agent-troubleshooting

If an install fails, post C:\ProgramData\FOG\fog-agent.log and the msiexec log here.

@sgennadi Thanks for this, and for the detail. You were right: the check matched no_root_squash anywhere in /etc/exports, not just on the /images/dev export.

It is fixed now, much the way you proposed. The new nfsDevExportHasNoRootSquash() checks only the <share>/dev export. It ignores comments, other exports, and look-alike paths such as /images/dev2. Your ISO export with no_root_squash no longer triggers the warning.

Issue: https://github.com/FOGProject/fogproject/issues/1988 1.6 (working-1.6): https://github.com/FOGProject/fogproject/pull/1989 (merged) 1.6 RC: https://github.com/FOGProject/fogproject/pull/1990 (merged) 1.5 dev-branch: https://github.com/FOGProject/fogproject/pull/1991 (merged)

To get it now, pull dev-branch (1.5) or rc-1.6.0 (1.6) and re-run the installer. It reaches the 1.5 stable branch with the monthly roll-up on November 11th.

The warning was only a message, so your exports were never changed. If /images/dev is already all_squash, you can ignore it until then.