@sebastian-roth

Update:
The switches were waiting for 260sec (4min 20sec) for the clients to send out a “I still want to receive this multicast stream” but the clients didn’t so the switches stopped sending the multicasts. I’ve changed that so the switches will now wait for 1260sec (21min) before stopping the multicast.

Our networks team had a look and muticasting is now working!

@sebastian-roth @george1421

Thanks the updated kernels fixed it
it now PXE boots and gets into fog and can upload and download images perfectly!

@sebastian-roth

Same as before with both
Gets to starting enp5s0
then enp6s0
SHows failed to get DHCP and then reboots

Hi folks bit of a intresting one, we have new PC’s that have three network cards, one on board the one fog PXE boots from and two in a PCI card.

However when pxe boots and we try and register the PC
It tries to get DHCP on the external cards and then fails after trying both and not the internal network card, any ideas? the internal card is an intel I219-LM

Any ideas would be great?

Hi, seems it was failing to update the DB at the end of the imaging,

We reset the DB creds and now its working perfectly

@sebastian-roth

Thanks Il get the monitor of the client PC connected to a VGA caputure card and have a look remotely, Will report back

When we attept to capture an image the upload proccess seems to be looping with partclone running over and over again

We have left it overnight and its repeated the same steps, have checked to see that the image is uploading and can see that data is being transfered in iftop, not sure what else i should look at

I can see the image files are owned by root in /images/dev/<randomfoldername>

Any advice would be welcome!

drwxrwxrwx 2 root       root       4096 Jul 26 18:02 .
drwxrwxrwx 5 fogproject root       4096 Jul 26 18:02 ..
-rw-r--r-- 1 root       root          2 Jul 26 18:02 d1.fixed_size_partitions
-rw-r--r-- 1 root       root    1048576 Jul 26 18:02 d1.mbr
-rw-r--r-- 1 root       root        285 Jul 26 18:02 d1.minimum.partitions
-rw-r--r-- 1 root       root         40 Jul 26 18:02 d1.original.fstypes
-rw-r--r-- 1 root       root          0 Jul 26 18:02 d1.original.swapuuids
-rw-r--r-- 1 root       root   10365295 Jul 26 18:02 d1p1.img
-rw-r--r-- 1 root       root 2438424831 Jul 26 18:03 d1p2.img.000
-rw-r--r-- 1 root       root        285 Jul 26 18:02 d1.partitions

System: Fog 1.5.9
Ubuntu 20.04 LTS

This may be something really simple we have missed but when we go to multicast it fails and from what i have read on the forums this may be due to the fog multicast manager as it stands we ran /opt/fog/service/FOGMulticastManager/FOGMulticastManager and tried multicasting and it worked brillantly

Is this an application that is supposed to start automatedly? can i just schedule this to start at server boot time? Will that cause issues?

OS: CentOS Linux release 7.7.1908
Fog: Version 1.5.7

@sebastian-roth

Update:
The switches were waiting for 260sec (4min 20sec) for the clients to send out a “I still want to receive this multicast stream” but the clients didn’t so the switches stopped sending the multicasts. I’ve changed that so the switches will now wait for 1260sec (21min) before stopping the multicast.

Our networks team had a look and muticasting is now working!

@sebastian-roth Thanks for replying,

We’ve tried on servral machines and still the same issue, even just multicasting to 1, Unicasting 1 of them works perfectly even at the same speed multicast achives, which is weird?

the log from /var/log/fog/multicast.log.udpcast.1 shows:

~~
Timeout notAnswered=[0] notReady=[0] nrAns=1 nrRead=1 nrPart=2 avg=830
Dropping client #0 because of timeout
Disconnecting #0 (10.255.0.122)
bytes= 27 293 398K re-xmits=0107680 ( 0.5%) slice=0112 - 1
Timeout notAnswered=[1] notReady=[1] nrAns=0 nrRead=0 nrPart=1 avg=830

Dropping client #1 because of timeout
Disconnecting #1 (10.255.0.121)
bytes= 27 293 398K re-xmits=0107680 (  0.5%) slice=0112 -   1
Transfer complete.

Again sorry for the novice questions, Windows Admin here :P

@george1421 thanks for getting back to us i have checked the hardware and they are i7s with samsung evo pro SSDs so pretty beefy
The issue seems to be that every multicast session gets around the same point and dies

I have looked into the logs and it shows client#0 ect timed out
Ive attached some images. Sorry if i am terrible at explaining !

The middle image shows how the network traffic all dies