@rdr You found a real bug. Sysprep is not needed, and it would not have helped.

Cause: the image carries the agent’s key and certificate from MMF-LAB2-00.
The agent compared the machine’s SMBIOS identity with that key only when it
had no certificate. A deployed copy has one, so every PC connected as
MMF-LAB2-00 and took its name.

fog-agent 0.1.7, released today, makes the check on every start.

To fix the PCs you already deployed:

Go to FOG Configuration > FOG Settings > General Settings and set
FOG_AGENT_DESIRED_VERSION to 0.1.7. Every enrolled agent updates itself,
including each PC that thinks it is MMF-LAB2-00. After the update, each PC sees that it is not MMF-LAB2-00, makes a new
key, and enrolls as itself. FOG matches it to its host by MAC. If FOG deployed to that host in the last 24 hours, the enrollment is
approved automatically. If not, approve it under Hosts > Pending Agents.
The agent then renames the PC to its name in FOG.

Please post back whether the names come right.

@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

Multicast. The version number does not show what fails. Queue a multicast task, start the clients, then post:

the output of tail -n 40 /opt/fog/log/multicast.log a photo of one client screen

–public-web-cert. Correction to my last reply: this flag helps only when your web server sends a complete, publicly trusted chain. The flag removes FOG’s own CA from the check, and curl then uses the system trust store. That check also failed. So the system store cannot verify the chain your web server sends. Run this on the FOG server and post the output:

openssl s_client -connect fog.mm.htlwien10.at:443 -servername fog.mm.htlwien10.at </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'

It shows who issued the certificate and which certificates the server sends.

Power management. The server sends the schedule in the same format as 1.5. The FOG Client runs it on the PC, at 18:55 PC time. Check that Power Management is enabled in FOG Configuration > Service Configuration and on the host. Then post C:\fog.log from one PC. The lines that start with PowerManagement show whether the client got the schedule.

Snapin after cloning. No C:\fog.log means the FOG Client service has not run yet. The server only queues the snapin. The client starts it. Add net start FOGService after the client install line in SetupComplete.cmd.

All Snapins. FOG shows All Snapins when a host has more than one snapin queued. The Active Snapin Tasks tab lists each snapin by name. The “/ of (/min)” text in the Progress column is a display bug. It is fixed in 1.6.0-beta.5346.

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.

Thank you Tom, I got updated to Working-1.6beta.4105 and that issue is fixed. Not sure if it is just this particular install or not.

Some Issues I am noticing is Host registration is not showing up whether from the fog menu or the client. I can see it is trying but does not appear to be writing to sql.

36f170d3-0a3b-4de3-b327-4233bc53534b-image.png

Deployment: Getting invalid mac errors it seems on all devices. The task seems to be populating alright.

No viable macs to use

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?

What version of FOG are you running?

@rpycroft Please attempt to update to 2231.

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.