@astrugatch Thanks, I can reproduce this.

Cause: since 1.5.10.2253 the server signs its HTTPS certificate with a “FOG Web CA” intermediate under the FOG Server CA. The client installer only accepts an HTTPS certificate issued directly by “FOG Server CA” when it downloads ca.cert.der, so the download fails and the pin fails. The fix is in the client: https://github.com/FOGProject/zazzles/pull/48. It needs a new client release.

Workaround until then, either one:

Trust the FOG CA before you install. Download http://<fog-server>/fog/management/other/ca.cert.der (plain HTTP works), then run certutil -addstore Root ca.cert.der as administrator. Then run the HTTPS install as before. Or install with HTTPS off. The client downloads the CA over HTTP, and the server redirects it to HTTPS after that.

@Mikeee89 Thanks for the detailed report. It pointed straight at the cause.

Cause: when udp-sender exits, the multicast manager closed the session and marked every host’s task Complete at the same time. The clients were still post-processing (UUID reset, NTFS flag, hostname). So when each client then reported back, its task was already gone: “No Active Task found for Host”. The imaging log row stayed open, which is where the “2026 years” duration comes from. This came in with the fix for #820.

Fix: the manager still closes the session when the sender exits, but now leaves each host’s task for that host to close itself. PR #1776 (dev-branch), #1777 (working-1.6). I reproduced your exact error against a copy of a 1.5.10 database, and the patched code returns success and closes the imaging log.

On your other observations:

msClients is reset to 0 when a session completes, so 0 after the run is expected. -2 is the marker for a session created from Image Management, not a counter underflow. The multicast.log.udpcast.<id> file is deleted at the end of every session, and has been for years. That is a separate question, not part of this bug. “has been killed” is printed even when the sender exited by itself. The wording is misleading, but nothing is actually killed.

Once it merges, update to the latest dev-branch and the task should close normally.

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

@AUTH-IT-Center I do believe snponly would be the recommended, rather than iPXE’s driver.

The developers at iPXE wrote the driver on their own (of course using documentation and stuff, but for all intents/purposes it is still a handrolled driver) so anything is possible.

We shipped the native iPXE 2.0.0 mainly because of the feature it allows with actual Secureboot capabilities and instead of embedding everyfile with a custom script, a more dynamic approach for when iPXE releases new version we can upgrade more easily.

For what it’s worth, I would almost want more people to default to snponly.efi (or secureboot/snponly-shimx64.efi if using/wanting secureboot after enrolling your machines of course) because this is supposed to be using the generic driver for EFI boot protocols on the NIC rather then attempting to discover the NIC using a driver loaded.

Glad you have a workaround. I think the cause is the Windows boot manager certificate change, not the image.

Your golden Optiplex installed Windows with Secure Boot on. Windows servicing then added the “Windows UEFI CA 2023” certificate to that machine’s db, and switched the boot files to a boot manager signed with it. The other Optiplex 3000s only trust the 2011 Microsoft certificates, so they reject that boot manager. bcdboot works because it copies the older 2011-signed boot manager.

Can you confirm with two checks, in admin PowerShell, on the golden machine and on one target?

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' mountvol S: /s (Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi).SignerCertificate.Issuer

If the golden machine says True and the target says False, that is the cause. A newer Dell BIOS may include the 2023 certificate in its default keys. I am also looking at having FOS add it during the Secure Boot enrollment task.

@gmaurice resetting the host encryption in the gui and then restart the fog service and it should be back up and running. You can also use the api for this, the FogApi powerhsell module (links in my signature) I have this Reset-HostEncryption function https://fogapi.readthedocs.io/en/latest/commands/Reset-HostEncryption/?h=reset+host which will also handle this reset.

Your other other option is to look into post download scripts, there’s some examples in the forums and the docs. If you’re using sysprep and unattend.xml you can inject domain join information into the unattend.xml after imaging and before windows launches for the first time, so the computer is joined to the domain before the fog service or any ui is reachable.

@Balage80 Thanks for confirming the enrollment fix.

UEFI boot: I think the cause is two new lines in default.ipxe. They read Secure Boot state from the firmware. iPXE reads it by stepping through every firmware variable, and some firmware never ends that list, so iPXE hangs there.

Please test this: take the new 979-byte default.ipxe and delete only these two lines. Keep everything else.

param secureboot ${efi/SecureBoot} param setupmode ${efi/SetupMode}

Does UEFI boot with that file? Please also post the make, model, and BIOS version of the machine. Note that re-running installfog.sh writes a new default.ipxe, which replaces a manual edit.

Pending MACs: these are not related to default.ipxe. They come from the legacy FOG Client’s Host Registration module. That module reports every adapter Windows sees, including Wi-Fi, Bluetooth, and virtual Wi-Fi Direct adapters. FOG stores each unknown MAC as pending, up to FOG_QUICKREG_MAX_PENDING_MACS per host (default 4). iPXE cannot see those adapters. You can delete the pending MACs. To stop new ones, add MAC fragments to FOG_QUICKREG_PENDING_MAC_FILTER (comma separated), or turn off Host Registration.

@kratkale 09-08-26 seems to me that the FOGMulticastManager service isn’t started or died somewhere.

Can you run:

sudo systemctl restart FOGMulticastManager sleep 5 sudo systemctl -l status FOGMulticastManager

On a separate window it might be helpful to see your php-fpm www-error logs (see my footer to see where to find that information)

FYI for anyone else running into this issue - I believe the problem was that I didn’t erase the /tftpboot images when I switched from http to https. I’m not really sure why that would matter, but when I did that, then re-ran the server reinstall and selected https, the images got but back in /tftpboot and my hosts didn’t see the mac error anymore.

@Priyankha We need a lot more details.

FOG Version

What bootfile is your boot server trying to send?

Is you server sending the right FOG server for option 66/67?

What OS are you trying to capture?

What does the error show or maybe a screen shot? (UEFI Boot looks different from Legacy boot from Mac from arm, etc…)

What type of machine are you trying to image?

What have you tried?

@JJ-Fullmer @edvandro This should be fixed in dev-branch as well, but I agree with JJ here, please upgrade to working-1.6.

@astrugatch Okay thanks and sorry there was that issue.

Can you pull and try installing again?

Thank you!

@Tom-Elliott

I can’t modify the company’s switches or other hardware since the system is in production. I’m currently rebuilding the FOG server on a VM on my PC and doing everything locally; it’ll be easier to troubleshoot that way. Gemini has wiped out all the previous messages and is giving me nonsense—I can’t seem to recreate the environment up to the capture stage anymore. Could you give me a rundown of everything that needs to be done—downloads, decompressing specific files in binary mode, etc.?

Thanks.

@maxcarpone I would ask you, if you’re daring/willing (it’s considered beta but uses the same pipeline with a lot more modern ui, I need people testing, and Fog_newb can likely attest the new ui look and feel though I think they ran into an issue and needed to get functional right away so the snapshotted back)

Upgrade to working-1.6.

I have a goal (along with @JJ-Fullmer ) to try to get working-1.6 to be master/stable branch by October.

1.6 has been “stagnant” since around 2017 and was in relatively stable grounds back then even.

With AI (as you undoubtly can see I’m using to help drive some things) it’s allowed us to get a lot more coding/refactoring and will hopefully present a much better experience of things on the UI side. Without testing I cannot fix UI bugs though.

AI can do some cool things, but it doesn’t know what “wrong/right” looks like, and JJ and I are only 2 people.

There are others on working-1.6 but more feedback is always good.

This can be closed. Thank you.

And I can’t add any hosts—whether via the web interface or by booting over the network—; ultimately, the new host doesn’t appear in the database…

Failed to query: Error: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1 Error Message: Error Code: "22007", Error Message: ["22007",1366,"Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1"], Debug: SQL: [629] INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`) VALUES (:hostID_0,:moduleID_0,:state_0),(:hostID_1,:moduleID_1,:state_1),(:hostID_2,:moduleID_2,:state_2),(:hostID_3,:moduleID_3,:state_3),(:hostID_4,:moduleID_4,:state_4),(:hostID_5,:moduleID_5,:state_5),(:hostID_6,:moduleID_6,:state_6),(:hostID_7,:moduleID_7,:state_7),(:hostID_8,:moduleID_8,:state_8),(:hostID_9,:moduleID_9,:state_9),(:hostID_10,:moduleID_10,:state_10),(:hostID_11,:moduleID_11,:state_11),(:hostID_12,:moduleID_12,:state_12) ON DUPLICATE KEY UPDATE `msHostID`=VALUES(`msHostID`),`msModuleID`=VALUES(`msModuleID`),`msState`=VALUES(`msState`)

@Tom-Elliott thanks Tom - using the excellent fog-docker from 88fingerslukee - so will wait to hear his response

@Tom-Elliott I did update to version 1.6.2254 and the first multicast that worked was the first one I tried after the upgrade. This second one is now hanging like the one that prompted this thread.

Where in the logs can I find any clues?