Task 0

[kratkale]

@Tom-Elliott
Goups -> List all Groups -> 01_CAD_1 -> Tasks -> Multi Cast
Abort … []
Shutdown … []
WAKE UP [x]
Debug … []
SCHEDULE IMMEDIATELY … [x]
[Create]
Displayed in
Task ->
Aktive Tasks (ervery PC)
Active Multicast Task (Group Entry)

[kratkale]

@Tom-Elliott
I dont use snapins asingned to PC’s
There was always a problem about Time, Restart, Update,
Unpredictable effects; something different with every $MS update
When cloning is realy finished I manually send a Snapin Teacher PC to the group Teacher PC and student to stundent.

[kratkale]

@Tom-Elliott
OK I’ve groups e.g. CAD 1 (a room with 36 PC’s) I want now to bring out a new image there.
I’ve now to
Host -> List All Hosts - > Select by Hand the 36 PC’s out of 64 / or take Column search and enter CAD1 - > Mass edit

That is the new way?

[Tom Elliott]

@kratkale You were right on all three counts, and I was wrong to push back. Thank you for staying with it — your report turned up three genuine bugs, all of which are now fixed.

Multicast was completely dead on 1.6, not just from a group. Nothing you did was wrong. A schema step I added on 2026-08-29 converted a batch of columns from 0 to NULL, and multicastSessions.msState was one of them. The FOGMulticastManager daemon looks for sessions whose state is in a list of numbers, and NULL matches no list — so every multicast session you created sat there forever and the sender was never started. That is exactly the “all hosts are waiting, nothing starts” you described. It affected the host list and the group path identically, which is why my “try it from the host list” suggestion would not have helped.

If you want to confirm it on your own server before and after, watch the log while you queue a task:

tail -f /opt/fog/log/multicast.log

Broken, it prints * No new tasks found every ten seconds forever, even with a session queued. Working, it picks the session up and starts talking about the image. You don’t need a client booted to see the difference.

The fix also repairs sessions already stranded in your database — the upgrade sets any that still belong to a live task back to queued, and cancels the rest so they don’t sit in the list.

“Single Snapin” showing as “All Snapins” was a real bug too. Tasking one snapin on a host that had no task running inserted the row typed as All Snapins and named “Multiple Snapin – orig Single”. The task itself ran correctly — only the snapin you picked was ever queued — but it read wrong in Active Tasks, in the task list’s Task Type column, and in the history. A guard that used to protect that code path went missing back in 2018. The same request made for several hosts at once went down a different path that was always correct, which is why you saw both labels for what you thought was the same action.

The “O” — I was wrong twice there.

First, I said it likely means On. It doesn’t necessarily: “On”, “Off” and “Not set” all truncate to a single character in that width, so “O” could be On or Off and you can’t tell which. On the host I checked, the “O” was Off.

Second, I told you to make the column to the right smaller. There is no column to its right — State is the last one, and the last column has no drag handle of its own. You’d have had to shrink Module Name, on its left. Sorry for sending you the wrong way.

The underlying cause was mine: the select box is styled to fill 100% of its cell, which means the cell has no natural width of its own, so the column collapsed to the width of the word “State” and then got locked at that size. It now sizes itself to fit its longest option, so you’ll see the whole word without touching anything.

On the “0” task from your first post — a task row pointing at a snapin that no longer exists. Those can no longer be created, and the upgrade sweeps out any left over, so it should be gone once you’re current.

Two things that are working as intended, not bugs:

Groups grant, they don’t copy. A group is now an envelope: put a host in a group that has a snapin or a printer and the host gets it, take the host out and it loses it. Nothing is written onto the host, which is why the group no longer offers to set an image on its members.

To set an image on a lot of hosts at once, use Host Management → List All Hosts, filter or search the list down to the ones you want, tick them, and use the mass-edit controls at the bottom — image is one of the fields there. For your 36-of-64 case, the per-column search boxes plus select-all-on-filtered is the fast way to pick them. If you make those 36 a group, that group also shows up as a filterable column, so next time it’s one click.

Where the fixes are: the multicast and snapin-labeling fixes are in 1.6.0-beta.5325 and newer. The State column fix is queued behind it and will be in the next build after that. Please update and let me know what version you land on and whether multicast starts for you — and if it doesn’t, post the multicast.log output from the ten seconds after you queue the task.

[kratkale]

@Tom-Elliott
OK—let’s try again
Hosts -> List All Hosts -> Groups contains “CAD_1_Group_2.6” -> Select All -> Multicast

[Tom Elliott]

@kratkale http://forums.fogproject.org/post/158665

[kratkale]

@Tom-Elliott
The web server IS serving FOG at:
https://fog.mm.htlwien10.at/fog/management/index.php?node=schema
but this host cannot verify the certificate it presents.

TLS verification failed (curl 60). The page rendered when verification was skipped,
so this is a trust problem and not a broken site – the
install continues.

Likely causes:
- the certificate is managed outside FOG (acme.sh, certbot)
and FOG has not been pointed at it: make
/opt/fog/pki/web/leaf/.webLeaf.pem resolve to your
certificate (a symlink is enough)
- the served chain does not terminate in the anchor FOG
resolved (/opt/fog/snapins/ssl//CA/.fogCA.pem)

Note the schema deploy verifies strictly and will NOT
continue past this – it carries an install token.

• Backing up database…Failed

  We were not able to backup the current database!
  Reason: curl exited 60 requesting https://fog.mm.htlwien10.at/fog/maintenance/backup_db.php: curl: (60) SSL certificate problem: unable to get local issuer certificate
  More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could

Proceeding means this upgrade has no pre-upgrade dump to
restore from. Press [Enter] to proceed anyway, or Ctrl+C
to stop the installer.

[kratkale]

@Tom-Elliott
multicast is not working …

Please note the installation errors …

[Tom Elliott]

@kratkale That’s not a bug and it’s not stopping you — press Enter and the upgrade will finish.

What it’s telling you: your server presents a certificate that FOG didn’t issue (a real one for fog.mm.htlwien10.at, from acme.sh/certbot or your school’s CA). During an upgrade the installer makes a few HTTPS calls to itself, and it verifies those against FOG’s own CA. Your certificate doesn’t chain to FOG’s CA, so those calls fail. The only thing you actually lose is the automatic pre-upgrade database dump.

So take a dump of the fog database yourself first, with mysqldump or from phpMyAdmin — whichever you normally use. Then press Enter and let the installer run.

To stop this happening on every upgrade, point FOG at the certificate you are actually serving. Symlink both halves of your ACME pair into FOG’s leaf directory:

/opt/fog/pki/web/leaf/.webLeaf.pem  ->  your fullchain file
/opt/fog/pki/web/leaf/.webLeaf.key  ->  its matching private file

FOG checks whether those resolve outside its own PKI directory. Once they do, it treats the certificate as externally managed: it stops regenerating it, and it stops replacing your system trust store when it calls itself — so verification just works. Running the installer with --public-web-cert declares the same thing up front.

Once you are through you will be on 1.6.0-beta.5332 or newer, which carries the multicast, snapin-labeling and State column fixes. Let me know whether multicast starts for you.

[kratkale]

@Tom-Elliott

multicast ist not working …

[kratkale]

@Tom-Elliott said in Task 0:
Running the installer with --public-web-cert declares the same thing up front.

Feature does not work:

[kratkale]

@Tom-Elliott
Scheduled Power Management Task is not working

Maybe it’s a Windows bug; I’ve often had to shut down not just once, but two or three times with 24H2 LTS.

But none of the 36 + 25 student computers are shutting down.

[kratkale]

@Tom-Elliott Manually deploying a Snapin after cloning does not work—you must first manually restart the system. There is no Fog log even before the restart. The Fog Client was run using C:\Windows\Setup\Scripts\SetupComplete.cmd

[kratkale]

@Tom-Elliott

Here, too, I’m just launching a simple snap-in—it would be cool if it also showed which snap-in it is. As I mentioned before, due to timing issues, I stopped automatically deploying snap-ins—they often didn’t work properly, even though they worked in the Command Prompt. From this, I concluded that there’s a timing issue between Windows Update… and the snap-ins. That’s why I’ve always preferred to do this manually.

[Tom Elliott]

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

[kratkale]

@Tom-Elliot
Unfortunately, I had to get the PCs up and running right away, so I wasn’t able to work through everything on the list. For now, I’ve cloned them without multicast. Next week, I’ll get back to you—I’ll test the rest then.
–public-web-cert.
root@fog:~# 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:’

0 s:CN=fog.mm.htlwien10.at, O=FOG Project, OU=FOG Web UI
i:CN=FOG Web CA, O=FOG Project, OU=FOG Web UI
root@fog:~#

Power management.

SERIAL Number from SSD
I had another PC that wouldn’t clone because of an error when entering the SSD’s serial number…
The number BNE7N774610407R8O ends with an “O” and contains a “0” in the number. Unfortunately, the second SSD was listed in Inventory Static, and I had determined the number of the relevant ssd using lsblk -o SERIAL. There my mistake happend

[kratkale]

@Tom-Elliott
Hi
I don’t know enough about certificates. I tried to use ChatGPT to implement your answer—and this is what came out:

This is important

The original instructions you received essentially say:

    “Your server is using a certificate that was not issued by FOG.”

That doesn’t match your current configuration.

Your current web certificate was clearly issued by the FOG Web CA.

Therefore, I wouldn’t create a symlink to any `fullchain.pem` file right now. We also have no indication so far that you’re using an external ACME certificate at all.
What’s likely happening

I suspect that the message you’re getting during the upgrade is related to the FOG PKI or the internal trust chain, and not to the fact that you’re using a Let’s Encrypt certificate.

It’s interesting to note that your current Apache configuration uses:

SSLCertificateFile /opt/fog/pki/web/leaf/.webLeaf.pem
SSLCertificateKeyFile /opt/fog/pki/web/leaf/.webLeaf.key

.

The older configuration also included:

SSLCertificateChainFile /opt/fog/snapins/ssl/CA/.fogCA.pem

The current configuration does not have an SSLCertificateChainFile line.

That might be relevant.

That’s where I stopped…

[kratkale]

@Tom-Elliott
Multicast

root@fog:~/FOG_SERVER_Updates_durchführen# tail -n 40 /opt/fog/log/multicast.log
[09-08-26 9:49:42 pm]  * No new tasks found
[09-08-26 9:49:52 pm]  * No new tasks found
[09-08-26 9:50:02 pm]  * No new tasks found
[09-08-26 9:50:12 pm]  * No new tasks found
[09-08-26 9:50:22 pm]  * No new tasks found
[09-08-26 9:50:32 pm]  * No new tasks found
[09-08-26 9:50:42 pm]  * No new tasks found
[09-08-26 9:50:52 pm]  * No new tasks found
[09-08-26 9:51:02 pm]  * No new tasks found
[09-08-26 9:51:12 pm]  * No new tasks found
[09-08-26 9:51:22 pm]  * No new tasks found
[09-08-26 9:51:32 pm]  * No new tasks found
[09-08-26 9:51:42 pm]  * No new tasks found
[09-08-26 9:51:52 pm]  * No new tasks found
[09-08-26 9:52:02 pm]  * No new tasks found
[09-08-26 9:52:12 pm]  * No new tasks found
[09-08-26 9:56:33 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting =====
[09-08-26 9:56:33 pm] Interface Ready with IP Address: 10.10.3.196
[09-08-26 9:56:33 pm] Interface Ready with IP Address: 127.0.0.1
[09-08-26 9:56:33 pm] Interface Ready with IP Address: 127.0.1.1
[09-08-26 9:56:33 pm] Interface Ready with IP Address: 192.168.0.196
[09-08-26 9:56:33 pm]  * Starting MulticastManager Service
[09-08-26 9:56:33 pm]  * Checking for new items every 10 seconds
[09-08-26 9:56:33 pm]  * Starting service loop
[09-08-26 10:00:14 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting =====
[09-08-26 10:00:14 pm] Interface Ready with IP Address: 10.10.3.196
[09-08-26 10:00:14 pm] Interface Ready with IP Address: 127.0.0.1
[09-08-26 10:00:14 pm] Interface Ready with IP Address: 127.0.1.1
[09-08-26 10:00:14 pm] Interface Ready with IP Address: 192.168.0.196
[09-08-26 10:00:14 pm]  * Starting MulticastManager Service
[09-08-26 10:00:14 pm]  * Checking for new items every 10 seconds
[09-08-26 10:00:14 pm]  * Starting service loop
[09-08-26 10:08:36 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting =====
[09-08-26 10:08:36 pm] Interface Ready with IP Address: 10.10.3.196
[09-08-26 10:08:36 pm] Interface Ready with IP Address: 127.0.0.1
[09-08-26 10:08:36 pm] Interface Ready with IP Address: 127.0.1.1
[09-08-26 10:08:36 pm] Interface Ready with IP Address: 192.168.0.196
[09-08-26 10:08:36 pm]  * Starting MulticastManager Service
[09-08-26 10:08:36 pm]  * Checking for new items every 10 seconds
[09-08-26 10:08:36 pm]  * Starting service loop
root@fog:~/FOG_SERVER_Updates_durchführen#

I use two network cards—the “192” network is the one with the PCs, and the “10” network contains only servers and my backup servers …

[Tom Elliott]

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

[kratkale]

@Tom-Elliott said in Task 0:

systemctl -l status FOGMulticastManager

root@fog:~# systemctl -l status FOGMulticastManager
● FOGMulticastManager.service - FOGMulticastManager
     Loaded: loaded (/usr/lib/systemd/system/FOGMulticastManager.service; enabl>
     Active: activating (auto-restart) (Result: exit-code) since Thu 2026-09-24>
 Invocation: 492c9b19a1cf4b3aa088147dbfb9573d
    Process: 3399372 ExecStart=/usr/bin/env php /opt/fog/service/FOGMulticastMa>
   Main PID: 3399372 (code=exited, status=255/EXCEPTION)
   Mem peak: 11M
        CPU: 110ms

Sep 24 13:27:28 fog env[3399406]: FOG autoloader: "FOGCore" is a core class and>
Sep 24 13:27:28 fog env[3399406]: PHP Fatal error:  Uncaught Error: Class "FOGC>
Sep 24 13:27:28 fog env[3399406]: Stack trace:
Sep 24 13:27:28 fog env[3399406]: #0 /opt/fog/service/FOGMulticastManager/FOGMu>
Sep 24 13:27:28 fog env[3399406]: #1 {main}
Sep 24 13:27:28 fog env[3399406]:   thrown in /opt/fog/service/lib/service_lib.>
Sep 24 13:27:28 fog systemd[1]: FOGMulticastManager.service: Main process exite>
Sep 24 13:27:28 fog systemd[1]: FOGMulticastManager.service: Failed with result>
Sep 24 13:27:29 fog systemd[1]: FOGMulticastManager.service: Scheduled restart >
Sep 24 13:27:29 fog systemd[1]: Started FOGMulticastManager.service - FOGMultic>
lines 1-19/19 (END)...skipping...
● FOGMulticastManager.service - FOGMulticastManager
     Loaded: loaded (/usr/lib/systemd/system/FOGMulticastManager.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2026-09-24 13:27:26 CEST; 279ms ago
 Invocation: 492c9b19a1cf4b3aa088147dbfb9573d
    Process: 3399372 ExecStart=/usr/bin/env php /opt/fog/service/FOGMulticastManager/FOGMulticastManager (code=exited, status=255/EXCEPTION)
   Main PID: 3399372 (code=exited, status=255/EXCEPTION)
   Mem peak: 11M
        CPU: 110ms

Sep 24 13:27:28 fog env[3399406]: FOG autoloader: "FOGCore" is a core class and core is no longer aliased into the global namespace. Use FOG\Base\FOGCore -- either as a `use` import or fully qualified. See ADR 0013.
Sep 24 13:27:28 fog env[3399406]: PHP Fatal error:  Uncaught Error: Class "FOGCore" not found in /opt/fog/service/lib/service_lib.php:62
Sep 24 13:27:28 fog env[3399406]: Stack trace:
Sep 24 13:27:28 fog env[3399406]: #0 /opt/fog/service/FOGMulticastManager/FOGMulticastManager(24): require()
Sep 24 13:27:28 fog env[3399406]: #1 {main}
Sep 24 13:27:28 fog env[3399406]:   thrown in /opt/fog/service/lib/service_lib.php on line 62
Sep 24 13:27:28 fog systemd[1]: FOGMulticastManager.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 24 13:27:28 fog systemd[1]: FOGMulticastManager.service: Failed with result 'exit-code'.
Sep 24 13:27:29 fog systemd[1]: FOGMulticastManager.service: Scheduled restart job, restart counter is at 11.
Sep 24 13:27:29 fog systemd[1]: Started FOGMulticastManager.service - FOGMulticastManager.

root@fog:~# tail /var/log/php*-fpm.log
[24-Sep-2026 12:14:14] NOTICE: [pool www] child 3259939 exited with code 0 after 8438.624140 seconds from start
[24-Sep-2026 12:14:14] NOTICE: [pool www] child 3351823 started
[24-Sep-2026 12:14:18] NOTICE: [pool www] child 3260061 exited with code 0 after 8432.972562 seconds from start
[24-Sep-2026 12:14:18] NOTICE: [pool www] child 3351887 started
[24-Sep-2026 12:14:29] NOTICE: [pool www] child 3260439 exited with code 0 after 8408.483139 seconds from start
[24-Sep-2026 12:14:29] NOTICE: [pool www] child 3352010 started
[24-Sep-2026 13:17:35] NOTICE: [pool www] child 3300912 exited with code 0 after 8461.325294 seconds from start
[24-Sep-2026 13:17:35] NOTICE: [pool www] child 3392980 started
[24-Sep-2026 13:19:31] NOTICE: [pool www] child 3302049 exited with code 0 after 8470.012033 seconds from start
[24-Sep-2026 13:19:31] NOTICE: [pool www] child 3394228 started
root@fog:~#