Multicast - unable to find image path

[vemoya]

That is the screen I got but then when all of the PCs that are in the group or listed on the client count were connected. The multicast started. I think you just need to make sure all of the clients are connected and PXE booted to FOG to join the Multicast session and start the deployment. Say for example you have a group of computers of let’s say 10 PCs and you start the multicast for them. This screen is what you will get when they are in the cue waiting for the rest to connect to the multicast on FOG. Once all 10 are connected, the image will start.

If you have 1 or 2 PCs in the CUE but not working then select the PCs and cancel the task. This will start the Multicast Task on the ones that did CUE up.

At least that’s what happens with me.

Hope this helps.

[Eruthon]

I understand, but after multiple tries with multiple PCs we tried this only on one PC (screenshot above) and still it’s just waiting.

[Eruthon]

This is the beginning of the multicast task in the log:

[09-21-20 3:58:59 pm] | Task ID: 10 Name: Multi-Cast Task - test is new
[09-21-20 3:58:59 pm] | Task ID: 10 Name: Multi-Cast Task - test image file found, file: /images/stretch16gba
[09-21-20 3:58:59 pm] | Task ID: 10 Name: Multi-Cast Task - test 1 client found
[09-21-20 3:58:59 pm] | Task ID: 10 Name: Multi-Cast Task - test sending on base port 58656
[09-21-20 3:58:59 pm] | Command: /usr/local/sbin/udp-sender --interface enp1s0 --min-receivers 1 --max-wait 600 --portbase 58656 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/stretch16gba/d1p1.img;
[09-21-20 3:58:59 pm] | Task ID: 10 Name: Multi-Cast Task - test has started
[09-21-20 3:59:09 pm] | Unable to find image path

[Tom Elliott]

@Eruthon Do you have an image named stretch16gba that has already been captured first?

[Sebastian Roth]

@Eruthon said in Multicast - unable to find image path:

Unable to find image path

Please run ls -alR /images on your FOG server console and post output here.

[Eruthon]

@Tom-Elliott - Yes, I do:

[Eruthon]

@Sebastian-Roth - I stripped the output of the other images:

root@kraken:~# ls -alR /images
/images:
total 148
drwxr-xr-x 34 root       root  4096 Sep 20 17:22 .
drwxr-xr-x 21 root       root  4096 Sep 18 17:37 ..
drwxrwxrwx  3 fogproject root  4096 Aug 17 10:02 dev
drwx------  2 root       root 16384 Sep 18 17:28 lost+found
-rwxrwxrwx  1 fogproject root     0 Aug 10 18:39 .mntcheck
drwxrwxrwx  2 fogproject root  4096 Aug 10 18:39 postdownloadscripts
drwxrwxrwx  2 root       root  4096 Aug 14 13:09 postinitscripts
drwxrwxrwx  2 root       root  4096 Nov  6  2017 stretch16gba

/images/dev:
total 12
drwxrwxrwx  3 fogproject root 4096 Aug 17 10:02 .
drwxr-xr-x 34 root       root 4096 Sep 20 17:22 ..
-rwxrwxrwx  1 fogproject root    0 Aug 10 18:39 .mntcheck
drwxrwxrwx  2 fogproject root 4096 Aug 10 18:39 postinitscripts

/images/dev/postinitscripts:
total 12
drwxrwxrwx 2 fogproject root 4096 Aug 10 18:39 .
drwxrwxrwx 3 fogproject root 4096 Aug 17 10:02 ..
-rwxrwxrwx 1 fogproject root  249 Aug 10 18:39 fog.postinit

/images/lost+found:
total 20
drwx------  2 root root 16384 Sep 18 17:28 .
drwxr-xr-x 34 root root  4096 Sep 20 17:22 ..

/images/postdownloadscripts:
total 12
drwxrwxrwx  2 fogproject root 4096 Aug 10 18:39 .
drwxr-xr-x 34 root       root 4096 Sep 20 17:22 ..
-rwxrwxrwx  1 fogproject root  235 Aug 10 18:39 fog.postdownload

/images/postinitscripts:
total 12
drwxrwxrwx  2 root root 4096 Aug 14 13:09 .
drwxr-xr-x 34 root root 4096 Sep 20 17:22 ..
-rwxrwxrwx  1 root root  249 Aug 14 13:09 fog.postinit

/images/stretch16gba:
total 837460
drwxrwxrwx  2 root root      4096 Nov  6  2017 .
drwxr-xr-x 34 root root      4096 Sep 20 17:22 ..
-rwxrwxrwx  1 root root         1 Nov  6  2017 d1.fixed_size_partitions
-rwxrwxrwx  1 root root         0 Nov  6  2017 d1.has_grub
-rwxrwxrwx  1 root root   1048576 Nov  6  2017 d1.mbr
-rwxrwxrwx  1 root root       259 Nov  6  2017 d1.minimum.partitions
-rwxrwxrwx  1 root root        16 Nov  6  2017 d1.original.fstypes
-rwxrwxrwx  1 root root       259 Nov  6  2017 d1.original.partitions
-rwxrwxrwx  1 root root         0 Nov  6  2017 d1.original.swapuuids
-rwxrwxrwx  1 root root 486676828 Nov  6  2017 d1p1.img
-rwxrwxrwx  1 root root 369804277 Nov  6  2017 stretch16gba
root@kraken:~#

The full output is here:
Output

[Sebastian Roth]

@Eruthon This seems all fine as far as I can see. Very strange. Can you give us some more background on this? I suppose the server is a fresh install or did you upgrade from an earlier version? Your FOG version is 1.5.9? Image capture and unicast/normal deploy works fine?

Edit: I saw your other topic. So this is an upgrade from 1.2.0. Did multicast work before the upgrade?

[Eruthon]

@Sebastian-Roth
We have old FOG 1.2.0 server, which was used until this summer, from there I managed to copy the settings and images to the new server.

The new server was firstly version 1.5.8-RC2, now it’s 1.5.9. It’s located on a DELL blade system PC running Debian 10 and there with virt-manager is running main FOG server on Debain 10 on IP X.X.143.101 together with the storage node on IP X.X.143.102.

Also firstly we wanted the main server to not work as a storage, so the main node with all the images would be just the .102 storage node. Then I copied all the images from there to the .101 main server, when I realized that the logs in web interface were coming from the .102 node.
Also until recently I had problems with the interface not coming up without any info, which interface precisely - that was resolved by restarting the virtual machines (all interfaces came up in the logs at startup) and probably by copying those images to the .101 main server (that resolved the problem with 0.00Bi sizes of images on server).

Also this is a vlan environment at school, so almost every PC classroom has its VLAN with maximum of 2 classrooms per VLAN and there are 10-26 PCs per classroom.

On the old 1.2.0 server multicast wasn’t working, but unicast did without any problems. Also the WOL and snapins didn’t work.
On the new server it’s similar, but we’d really like to make the multicast work, because one classroom can take up about 4 hours to download image for all PCs with unicast.

That’s why we made another virtual machine on the PC with main server and storage node with the 143 VLAN to check if the problem would be somewhere in the network, but it’s the same for all PCs around the school for every image.

[Sebastian Roth]

@Eruthon Thanks for adding some details to the picture. So essentially this is a sort of clean fresh install and multicast hasn’t worked before.

I have looked through the code and read through most of the topic again and again but can’t make sense of this yet. Can you please double check the Image Path setting in the web UI does not have any hidden space characters in it!

[Eruthon]

@Sebastian-Roth Yes, that’s alright…

One thing coming to mind is network settings… on the way from the FOG server to the classrooms we have:

• FOG server
• DELL blade PC
• DELL blade switch
• Cisco C3750E L3 switch
• Cisco C3560G L3 switch
• Linksys switches in every classroom
• Classroom PCs

I saw that the Cisco switches should be configured in a way to allow multicast, but we have multicast TV all over the school and we can watch it with VLC player perfectly. Also I could find multicast from FOG in the mroute table of the cisco switch…

[Eruthon]

Ok, so I found out why it was showing the “Unable to find image path”… I found out there was an old testing multicast session in the Images->Multicast Image->Current sessions tab, after removing it, it stopped showing the error message.

Nevertheless the testing PC is not getting the image and waits on the PartClone screen.

[Tom Elliott]

@Eruthon After removing the Multicast session, did you restart the PC to try to have it join the proper session?

Is this machine the only one supposed to be in the group?

What’s the Max wait time set? (You should be able to see the multicast command that would have been run in your logs.

Thank you,

[Eruthon]

Ok, I found out the problem for the virtual test PC - the default bridge in QEMU386/KVM bridge system in virt-manager didn’t work with multicast, so we used brct-util explicitly adding bridge interface.

addbr brctl br143

In /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto eno1.143
iface eno1.143 inet manual
    vlan-raw-device eno1

auto br143
iface br143 inet static
    bridge_ports eno1.143
    address X.X.143.23
    netmask 255.255.255.0
    gateway X.X.143.254
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off
    bridge_fd 9
    up /sbin/ifconfig $IFACE up || /bin/true

Checking setting by “ip a”:

1: lo: ...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
3: eno2: ...
4: eno1.143@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br143 state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
5: br143: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
    inet X.X.143.23/24 brd X.X.143.255 scope global br143
       valid_lft forever preferred_lft forever

EDIT: it works on every PC in the network! Thanks for all the support, problem solved!

[Sebastian Roth]

@Eruthon Great to hear you got multicast working. It’s way more convenient to deploy this way! Well done.