I quickly read about your issue, could this be related with your problem ? :

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy?page=1

@RogerBrownTDL I believe the 24.04.3 LTS is supported by FOG in the Dev-branch.

If wanting to stick strictly to the 1.5.10 “latest official” release, I believe Ubuntu 22.04 is the latest supported.

@Tom-Elliott I think this post helps fix the issues:
https://forums.fogproject.org/post/154920

@Tom-Elliott Thank you so much for your verification. I was a little panicked haha. Have a good day!

@Tom-Elliott

@Tom-Elliott said in Multicast timeout:

You created a table in FOG called hostsIP?

Yes, in our environment hosts, have ip reservations and I did not found in FOG tables last used ip by hosts (may be I missed something) so I created a table associating ip to hosts names.

@Tom-Elliott said in Multicast timeout:

Note: This isn’t a bad thing, I’m just trying to reference the information.

No worries.

@Tom-Elliott said in Multicast timeout:

The way I understand this, you’re looking at the mutlicastSessions table, getting a group, and getting the name of the hosts.

First I get all running mutlicast sessions. foreach sessoin I guess the group associated. I get max number of machine in the group I get the current current associated machines to the session As if a machine is finished, it is removed from the sesssion machine list, I compare the group machine number and the current machine running for this session. If the two differ it means that at least one went to the end but not the others. Now you make me talk on it I understand the specificity of our setup, all of our machines names start with group name (ex : all machines in rooms 1 will have such a name pattern : R1-P1, R1-P2…R1-P10), So as I have group name and I know that hosts which belong to it have it in their name, I get all machines with name starting with the group name we are working on. The same way I get machines IDs If not already done I get image ID Same for task ID (one client is enough as in mulitcast if I kill on client it kills all multicast) For each remaining hosts, I store ID, and Name in an array. I kill the task and do a 1 sec sleep loop till the mutlicast session disappear. (It can take few seconds for the multicast to be removed and without this loop some clients can’t be reinstalled because they are still part of another process. and finally for each hosts in created array, I create a unicast session (using host id) and reboot the pc using host ip.

@Tom-Elliott said in Multicast timeout:

You’re at least aware of the IPs which most others will not be, but just trying to think this through.

I searched for a more elegant way to get hosts ip and which could be universal, but the lack of time lead me to this rude behaviour 😉

But if someone has an idea on how to do it I would be very please to update this.
To be honest I thought to modify more the init.xz to populate automatically the hostsIP table when it loads but I have a working solution and it’s not even a priority for us but something more comfortable, if I had spent more time on this, someone would have come to break my fingers 😉

Sorry for the long post.

@simon said in probleme sur les taches planifiers pour une décente d'image:

j’ai bien fait cette configuration mais cela ne fonctionne toujours pas

Can you re-run the FOG installer or restart the FOG Services that deal with scheduled tasks?

This should force all existing services to reload, and I apologize for forgetting the services need restarting as well, just didn’t think about it.

You should have logs, that will show you the time that things are running, which will also help.

These can be seein in the UI under FOG Settings -> Logs, Scheduler I think.

Pouvez-vous réexécuter le programme d’installation de FOG ou redémarrer les services FOG qui gèrent les tâches planifiées ?

Cela devrait forcer tous les services existants à recharger, et je m’excuse d’avoir oublié que les services doivent également être redémarrés, je n’y ai tout simplement pas pensé.

Vous devriez avoir des journaux, qui vous montreront l’heure à laquelle les choses fonctionnent, ce qui sera également utile.

Ceux-ci peuvent être consultés dans l’interface utilisateur sous Paramètres FOG -> Journaux, Planificateur, je pense.

For anyone who stumbles across this, I got this working. I’ve written up how here;

@george1421 I just want to give you a quick update that we have not found any other Dell laptop with that issue. The ones we found turns out that a reboot just fix it. If I found any laptop with this issue, then I can get the requested information, thank you

@processor Don’t feel ashamed. Mistakes happen and that’s what we are all here for.

The example I was asking for was the output, but then it all clicked. You were doing a Get request 🙂

@Tom-Elliott

Thanks Tom.

I since went with 1.5.9 and was able to re-install the server with that, I did have to run the installer a few times to load all the missing packages.

I ended up putting the kernel, init files there manually. Then with the installer running and adding the --ignore fail switch installed the files that way.

Then I updated to the latest kernel in the FOG GUI so I have the latest kernel running as I need this for current HP Z2 G9 mini and small form factor computers.

This is running so I considered this solved.

Matt

I noticed that on the old database if you registered the client and went to the hosts section and then service settings.  You would see all the boxes unchecked.  If you tried to check them and hit update it would appear to work.  But if you went out and back into the client all the boxes were still unchecked.

If anyone runs into this, I wanted to post what I did for this issue.  I performed a clean install of fog on a new server.  I then restored the images and the database.  After that, I still had the same problem.  I put a blank database on the server and tried registering the computer again and it worked.  So, we worked around the problem by starting with a clean database.  Luckily, we are replacing over half of our computers this summer, so we don’t have that many to register again.

Bumping this topic. I too see the issue. I only see imaging events for registered hosts. I have a lot of field techs imaging unregistered hosts and need to have these events logged.

@TaTa

Thank you for your reply. I didn’t try your solution but after IGMP Snooping was configured on the VLAN, the multicasting worked immediately.

I left all the Fog multicasting settings as default.

@Kureebow Kernel Update resolved the issue. Thank you JJ Fullmer for the assistance!

@1337darkin The image can be captured in any state (PXE/UEFI)

But to boot the system, you need it in the “original” state of creating in the image:

For example::

You have a UEFI booted machine, and you capture the Image over PXE (Legacy) network via Virtual Box

That will be fine, as long as the system that boots is booting in UEFI mode. The “boot” mode is the important piece if that helps?

@rodluz That got it!

You are the man!

Let me give a feedback to this issue, as I faced it recently. In my case, the culprit was faulting parameters in Microsoft DHCP.
Captura de tela de 2024-05-03 12-15-42.png
It was faulting “MSFT Quarantine” User Class and PXE Vendor Class is not properly configured (It was typed “PXEclient:Arch:00007” instead of “PXEClient:Arch:00007”).
Captura de tela de 2024-05-03 12-15-26.png
After doing this corrections, PXE got successfully redirected Boot instructions to FOG Server.

@Tom-Elliott said in Ftp_login(): Maximum number of tried exceeded:

@nkduy1508 You need to resync your FOG FTP credentials and all.

https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

fog shouldn’t be the user in use anymore unless you’re using a very old version of FOG?

From the INIT version, it seems maybe from 1.5.7?

Version Fog: 1.5.9 RC2
I checked password TFTP server the same with jogsetting file