@plegrand @plegrand I have not tested everything but it seems to be working fine with Trixie. As mentioned, there were some minor challenges but with the help of @Tom-Elliott posts and posts from others, I got it upgraded. I did a full inventory on a new computer and that worked. I deployed one image and that seemed to work.

php -v
PHP 8.4.11 (cli) (built: Aug 3 2025 07:32:21) (NTS)
Copyright © The PHP Group
Built by Debian
Zend Engine v4.4.11, Copyright © Zend Technologies
with Zend OPcache v8.4.11, Copyright ©, by Zend Technologies

cat /etc/debian_version
13.0

@george1421 Just thinking outside the box as it makes 0 sense for it to be “just these network cards”

I suppose the “real” test would be seeing if outside of this room if the same problem happens?

I know not simple, but if you can move the whole room to an area where we know this issue doesn’t currently exist, and it shows, then it’s likely specific to this equipment. If it doesnt’ show up, it’s likely something specific to that particular room.

@george1421
Hello, it seems that the problem came from the configuration left over on the workstation, which still contained snappins that were no longer needed and no longer applicable.
.

Just for my curiosity why not use sysprep + copyprofile solution ?

For me depends what you want personnalize. Often just need GPO, registry, copy files etc to personnalize user environment.

@plegrand said in upgrade Debian 11 to 12:

127.0.0.1:9000

This is the communication port that apache talks to php-fpm (PHP Execution Engine). For some reason during the update php-fpm was not updated or failed to restart correctly.

Well done getting this resolved on your end.

@plegrand Correct

Not all buttons are supposed to be compulsively clicked. 😉

@plegrand Well done. Good to see you got it done using the instructions from the wiki.

@sebastian-roth
I completed the upgrade without any major problems.
I had to reinstall some php packages that had been removed during the upgrade
(the comparison between the packages installed on the old version and the new one allowed me to reinstall them easily)

I also had to re-run installfog.sh because I had the same problem as here:
https://forums.fogproject.org/topic/15254/503-service-unavailable-after-debian-upgrade.

Also, unrelated to fog, I had to review the configuration of mariadb and more particularly the authentication mode of the “root@localhost” user.
Indeed the user “root@localhost” was still using authentication with a password, but the new method is to use auth_socket :

+-----------+------------------+-----------------------+-------------------------------------------+ | Host | User | plugin | authentication_string | +-----------+------------------+-----------------------+-------------------------------------------+ | localhost | root | mysql_native_password | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | +-----------+------------------+-----------------------+-------------------------------------------+ | Host | User | plugin | authentication_string | +-----------+------------------+-----------------------+-------------------------------------------+ | localhost | root | unix_socket |

this is all I can say

@snmdla said in Snapin group:

@Tom-Elliott
yes, it appears to have no effect, as no plugin task is created as far as I have seen.
Please correct me if I’m wrong.

ah, I think I now understood. The dialogue will associate all group members with the snapin, which will only be fired when, for the individual client “All Snapins” task will be run.

So, to correct my usability suggestion, it would have helped to read “all group members updated” instead of “group updated”.

@plegrand Which Linux OS and version do you use? Which FOG version do you run right now?

@plegrand Testing internet connection is now done mainly with curl.

@plegrand Yes correct, this has been fixed already. This has nothing to do with the fog-client issues you see.

@plegrand Do other clients work properly or do they all show those messages in the client logs?

@dejv said in cannot find disk on system (getHardDisk):

we still need to change to ahci?

Yes this is an Intel and Linux kernel developer issue. There is no resolution at this time.

@plegrand Ops, I forgot to post here. This should be fixed in dev-branch now…

@george1421
It seems yes

@plegrand said in Multicast very slow:

Then there is 2 sessions running (test and test2) and all the target computers have about 1.15GB/min rate

Just so I’m clear on this. When you were able to get 4 computers imaging your transfer rate was 1.15GB/min? That’s still 19MB/sec. You are still above the 100Mb/s theoretical limit.

All the computers have 2 partitions and strangely the first partition is slower than the second : about 700MB/min rate

I can explain this. The number is based on an incorrect calculation. The issue is that first partition is pretty small, like 500MB. It transfers so fast that the speed numbers get skewed. The second partition is typically the contents of the 😄 drive. You can see this if you look at the disk manager in Windows. Look at the size of the first partition.

I might need to explain how image multicasting works. There is one computer (FOG Server) that is sending the image out. As each multicast client boots up it checks in with the multicast sender through a discovery process. The muticast sender (FOG Server) configures the multicast sender service to wait for X number of clients to check in before going, or after the first client checks in wait for XX seconds before going even if not all have checked in. Once the multicast stream starts, no other late clients can check in (they are blocked). So in the image stream the FOG server sends out the first block of data then stops. It waits for every multicast receiver (target computers) to respond with “OK!”. The FOG server will not send the next block until it hears “OK!” from every client. If something happens and one client didn’t get the block correctly it will send “Retrans” back to the FOG server and the fog server will resend that block back to the client computer (while the others sit and wait until everyone replies with “OK!”. This is why we say multicasting can only go as fast as the slowest computer in the multicast stream. Consider you have 4, 8-core desktops all with SSD drives and one with a Penitum-4 and a slow HDD. If you imaged them all in one stream the 8 core systems would image at the rate the Penitum-4 system can write data to its slow HDD. If you have a system with a failing hard drive if the block transferred to it’s checksum doesn’t match the checksum of the block on the disk it will send a “Retrans” command back to the FOG server while the other clients wait. The point is when everything works it works well, when you have one bad actor everyone suffers.

@Sebastian-Roth Very nice.
On a side note do those inits also address the intel raid-1 monitor application too? That one was related to a bootroot issue. Disregard, I see you answer the question in that thread too.