@Tom-Elliott

This is fixed, too, and can be marked as solved. The reason was stale WOL power action. I deleted those manually from the DB, and the CPU went back to normal.

I’m not sure about the SSH and replication issues, but I deleted my physical storage node, and I’m not seeing those anymore.

@mashina
I’m still having huge problems. Updated Fog. Rebuilt the Windows 11 image. … Windows 11 changes the boot order.
The image works for a few days—then it stops working.
Multicast only works sometimes—just now the image worked with one computer, but not with three in multicast—it just stops at 94% for no reason. What surprises me the most is that with this computer, only BOOT EXIT TYPE: SANBOOT works. I don’t understand much about this, but it seems wrong to me.

@pillbox1234567 Thanks for the suggestion. I turned Viridian off on the cloned VM, and it did not make a difference.

Interesting note that you’ve seen it cause boot issues on certain Linux VMs. I have not experienced that behavior yet but will keep an eye out for it.

@Preston Wow that was a super answer, thanks Preston! I’ll give this a go in the week. 🙂

@Exsival When you say “Causing the fog server to crash” what exactly do you mean?

If it’s just a “saying” I can understand that but from a technical standpoint what this means is completely different and would need logs. If all you mean is the machine in quesiton is hanging, that’s a different issue altogether. I highly doubt the whole FOG Server is crashing.

@lucasgfaj have you turned off secure boot?

@Tom-Elliott
I did not update yet to 1824, but i did SELECT * FROM HISTORY;

MariaDB [fog]> SELECT * FROM history; +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | hID | hText | hUser | hTime | hIP | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | 1 | [2026-04-01 08:33:55] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 08:33:55 | 10.10.3.116 | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ 1 row in set (0.000 sec)

the new session i create are not shown, and dont work until i run the maintenance queries

then it shows in history table:

MariaDB [fog]> SELECT * FROM history; +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | hID | hText | hUser | hTime | hIP | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | 1 | [2026-04-01 08:33:55] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 08:33:55 | 10.10.3.116 | | 2 | [2026-04-01 09:10:37] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 09:10:37 | 10.10.3.116 | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ 2 rows in set (0.000 sec)

@devle I’ve made a couple of edits, though I still cannot replicate the problem you’re seeing.

You shouldn’t see the errors any more (just saying), though I don’t know if these things will fix whatever problem you’re seeing.

@Tom-Elliott All good the last update fixed the issue!

@BLT I don’t necessarily have a timeline for the final release but I did just release an experimental kernel with a newer nic driver. It may work for you if you want to give it a try.

@Infojoe And a real question : How can I mark this as “solved” ?

My workarounds for update on Debian Trixie are:

A)
git checkout master ; git pull
userdel fogproject
cd bin ; ./installfog.sh

or
B)
apt install lastlog2
git checkout master ; git pull
ln -s /usr/bin/lastlog2 /usr/bin/lastlog
cd bin ; ./installfog.sh

Peter

@george1421 I probably found the reason of disSYNC of fog password and FOG settings. My old fog generated password included an & char (password looked like q&Y**********) but after some updates I found q&#38#38#38…********** in FOG_TFTP_FTP_PASSWORD and Storage Management Password.

To solve thi issue , I used https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password bit first I changed password in /opt/fog/.fogsettings.

Then update

update FOG_TFTP_FTP_PASSWORD update Storage Management Password, delete fogproject user (debian 13 installer bug lastlog vs. lastlog2) rerun installfog.sh

Now kernel update (tftp access) is working again.

As a workaround, we’re doing deploy in these Appliances by Schedule Deploy Tasks, as it bypass the authentication screen. But i would be interesting if we could do deploys without this need.