Developers

@Critchleyb said in Hosts drop out of Multicast Session on Partition switch:

Intel l219-V

Maybe it really is a driver issue. Makes me wonder if other people have same problems. On the other hand you said that it would unicast to all PCs just fine, right?!

I found this kind of old topic. It talks about i219-LM cards but I have heard about issues when offloading is enabled and drivers cannot handle it properly. As well here is another topic talking about disabling energy saving. So in the same script where you added the iperf stuff you might comment that and add the folling two lines to test:

ethtool --offload eth0 gso off gro off tso off
ethtool --set-eee eth0 eee off

Then schedule a normal multicast task for your clients and see if it’s any better or even worse?!

@Critchleyb I have thought about this a bit more. Most issues arise when you try to multicast across switches and even more across routers/subnets. This can be very hard to get to work properly if you’re not one of these network wizards. But you said you had the problem even when multicasting clients all being on the same switch. This rules out the switch from my point of view as all switches I have seen handle multicast within their own fabrics fairly well.

You might want to test with iPerf to see if you get the same results. Using iPerf you might get a feeling of what’s going on in your network. For that edit /images/dev/postinitscripts/fog.postinit on your FOG server (be careful, this will be used by every client doing a task so better don’t do this in an environment where someone else might be using this FOG sever to deploy clients at the same time) to look like this:

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>
curl -ko iperf https://iperf.fr/download/ubuntu/iperf_2.0.9
chmod +x iperf
./iperf -s -u -B 224.0.0.1 -p 9000 -i 1

Now also install iperf on your FOG server. Make sure it’s version 2.x as the newer 3.x does not support multicast testing anymore. Most distros should have it in the repos or you can get it here.

Get together a couple of clients you want to test with and manually schedule a debug task for those (doesn’t matter if it’s capture or deploy as we don’t want to run the task itself anyway). You cannot schedule as debug via group so this has to be done individually for each host. Let them all boot up and hit ENTER twice to get to the shell. Then start the iperf test simply by running the command fog. Do this with all your test clients and let them wait there.

Now back to the FOG server run this command to start the test: iperf -c 224.0.0.1 -u -p 9000 -i 1 -b 1000M -t 10

This will do a first 10 second test with max bandwidth of 1000MBit/s. Adjust the last two parameters and start the test runs from your FOG server as often as you like. Once the clients are up and waiting you can start testing from the server again and again without touching the clients.

Although you only get the interesting results watching the client’s screens. You see transfer rates and more importantly lost packets (in total and percent).

Hint: The logic of client/server is a bit reverse in this iPerf test. In multicast mode you want one client (the FOG server) to send data to all your multicast server listeners (hosts).

@pietroaretino Sorry for the late reply. We’ve lost track of this issue. Let’s see if we can work this out for you.

I’m just trying to upload a zip file of MS-Office 2016 install.

I am wondering if it’s just file size issue? I have just installed FOG 1.5.5.3 on Debian an created a couple of SnapinPacks. First smaller ones than bigger ones. All working great up to 250 MB. So I can’t replicate the issue as you describe it.

Would you mind updating to FOG 1.5.5 or even the dev-branch (currently 1.5.5.3) to see if you still see the issue? We’ve adjusted some of the php-fpm config values since then. So maybe this is fixed for you already.

@pberberian @Sbergeron I am sorry to bring up this kind of oldish topic again. Lately I have been working on a couple of things and stumbled upon something that makes me think that ARM support never made it into FOG completely (exit type calling ARM binaries that don’t exist in FOG). So I am wondering if you are still interested or maybe got it worked out yourself? I am more than happy to add what is needed to fully support ARM clients but on the other hand I don’t fancy maintaining the ARM support if it’s not used at all.

@AsGF2MX said in Compatibility check for X1 Carbon 2018:

I’m not using the default IP range on the fog server but the key seems to be using 192.x.x.x. I’m not sure how to get it to start imaging.

When creating the USB key there is a variable you need to change… here is an excerpt of the script:

...
echo Create the grub configuration file
cat > /mnt/boot/grub/grub.cfg << 'EOF'

set myfogip=192.168.1.100
set myimage=/boot/bzImage
set myinits=/boot/init.xz
....

No need to recreate the USB key. Simply mount it and edit boot/grub/grub.cfg on that key. Put in your FOG server’s IP and you should be fine. Manually register the host’s MAC, then simply schedule a task for it and boot right into the task via USB.

@The-Dealman As George said, take a look at the logs to see the current status of replication going. It replicates image by image but kind of parallel to all storage nodes.The actual replication of one image to one storage node is started as a background job and so it is mostly going all in parallel.

@Tom-Elliott in fact, in my testing, it was 10% faster

@sbenson No, we don’t use Avahi/LLMNR in FOG. The FOG installer does not set this up so I suppose you installed/configured it on the server manually?!

There is no Software inventory.

Hardware inventory is performed either through the deployment/capture process of a registered machine, or via a dedicated Inventory from the FOG GUI. @george1421 the FOG Client does not perform “hardware inventory” in the level of telling a user what information the machine has. It simply registers an unregistered machine and allows the admins to approve/disapprove machines in a semi-autonomous methodology. (Not that I think you were saying otherwise, just wanted to make sure the information was more clear.)

Software deployment is not the “strong” element of what FOG does. We do have snapins which could potentially be used to install software, but snapins, in and of themselves, are not really a “software deployment utility”. This would be better suited for some other programs out there. Neither is it a patch management system. Again, you could use snapins to do these things, but this was not what snapins were designed for.

Unattended installation is managed particularly by how you want to manage the installation process. FOG, as @george1421 stated, doesn’t care what “state” your reference machine is in. It only captures the current state of the hard drive in a block level format. I would, personally, recommend using Sysprep (in the case of Windows) to generalize the machine before capture. This will allow you the ability to create what we call a “hardware independent” image. This, however, is not a requirement and FOG will happily capture your disk in any state you feel is sufficient for your needs.

Hardware inventory works just like an imaging task in fog works. (At least if you’re meaning what I think you’re meaning.) You create a task (deploy, capture, or inventory). FOG Uses PXE to load the machine from the network. This passes to a bootfile called iPXE. IPXE then handles checking for the task, and if there is one found booting the machine into the FOS (FOG Operation System) to perform the task. This data is stored in the FOG MySQL database linked to the registered host’s identifier.

Hopefully this helps. @george1421 already stated most of this, but I figured I could potentially help a little too!

@george1421 To be fair, Zstd at 11 doesn’t seem to be any slower, to me, than gzip at 6.