FOGProject / fos

FOG Operating System
30 stars 33 forks source link

Removing MACs from multicast task without starting over #48

Open Sebastian-Roth opened 1 year ago

Sebastian-Roth commented 1 year ago

danboid said:

I’ve had it happen a couple of times this week where I’ve started a FOG multicast task with up to 50 machines and then I won’t be able to get one or two machines to boot into FOG (or, as happened earlier, one machine started writing the image early for some unknown reason) and then I’ve been forced to stop all of the tasks and start over, rebooting all of the machines etc because FOG is waiting on one or two last machines to appear before it will start the multicast.

I have tried to cancel/remove individual machines from a multicast task but it seems to stop/remove all of the existing tasks. Is there a way to fix this situation and to get FOG to start a multicast task without cancelling all of the tasks and starting over?

Reference: https://forums.fogproject.org/topic/16528/removing-macs-from-multicast-task-without-starting-over

Sebastian-Roth commented 1 year ago

Relevant part in the FOG bootmenu code is done (fogproject commit 45a6120).

FOS init script code needs to be done as well as testing.

Pieshka commented 1 year ago

Speaking of Multicast, I've noticed that if the sessions don't start at all, but still when you cancel all Multicast tasks in the web panel, the udp-sender itself remains running in the background on the server.

Ideally, after cancelling all tasks, the udp-sender should be killed in any case.

Screenshot 2022-11-05 171245

Sebastian-Roth commented 1 year ago

@Piotr86PL said:

Speaking of Multicast, I've noticed that if the sessions don't start at all, but still when you cancel all Multicast tasks in the web panel, the udp-sender itself remains running in the background on the server.

Sorry for the long delay. You are right about this. Though I don't see this to be related to the issue reported here. I just opened a new issue in the fogproject repo (FOGProject/fogproject#523) because this stuff is handled in there.