@Balage80 This is fixed in working-1.6 (PR #1755).

The agent routes were being blocked by the FOG_API_ENABLED setting. With the API turned off, every /fog/agent/v1/ request got a 308 redirect to the login page, so the agent could never enroll. Now the agent routes work whether that setting is on or off.

To update: pull working-1.6 and re-run installfog.sh. After that, you can turn FOG_API_ENABLED back off if you want. Enrollment still needs an approval in the UI.

The legacy FOG Client 0.13.0 problem has a different cause. If those clients still loop on requestClientInfo after the update, please post the fog.log from one of them.

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

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

@jmeyer Would you be willing/able to try again without bypassing it to help confirm the fix?
@rogersk4132 thank you for testing and confirming!

@astrugatch Okay thanks and sorry there was that issue.

Can you pull and try installing again?

Thank you!

@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

@Tom-Elliott Thanks Tom. 1.5.10.2344 seems to be capturing fine. No additional null tasks were created and the PC had no problem checking in and starting the capture.

I’d swear, not only with this version but the earlier ones that were malfunctioning during check in and creating additional tasks, I had to create the task twice. Like I went through the process of setting up a capture but nothing showed up under tasks then had to do it again.

I can’t seem to duplicate it though. Setting up a 2nd capture for the laptop, I only had to do it once (and no additional null tasks were created).

PC finished the capture no problem and laptop checked in and is capturing now. Looks like 2344 did it!

Thanks again.

Resolved. I’m sharing FOG with as many people as I can. Love this project!

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`)

Just fyi, I resolved my issues with this by turning off DMA protection in the bios/uefi.

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

Encountered the same issue, version: 1.5.10

I can successfully capture the image and then see the size of it in the web panel but then it’s not being moved to /images/ by fog. Requiring me to move them manually which works but I’m kinda concerned.

FTP works fine even though I am afraid I don’t understand why I need FTP to move some files inside a directory on a singular server.

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

@Strahd Have you been able to make progress?