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

I think this is an issue envolving this kind of nic hardware (Intel I226-V). I opened an issue (18125) where I have some appliances for pfsense, they have got four NICs with this kind of hardware, and we are not getting successfull to deploy an image because it’s not processing authentication, even typíng correct user and password.