Can't multicast on latitude 3310
-
@alicevintage Wow my eyes are getting bad. I get the basics of the error message.
On the FOG Host server console. post a clear shot of the output of this command.
ls -la /images/CharlotP
(or what ever that image name really is) Partclone is saying that the file d1p3.img is missing from that directory. -
@AliceVintage Are you able to multicast to other machines?
-
@george1421 said in Can't multicast on latitude 3310:
ls -la /images/CharlotP
@Sebastian-Roth yes, i can multicast other machine just fine
-
@AliceVintage Did you see an error message in the blue partclone screen beforehand. I am fairly sure what we see in the picture is the result of an earlier error.
-
@Sebastian-Roth the only error i get during the multicast is the one shown in the picture
pigz: skipping: <stdin>: corrupted -- incomplete defl data pgiz: abort: internal threads error
-
@AliceVintage Do you get this error always on the same hosts? Please try scheduling the multicast task for only 2-3 hosts in one go. See if it deploys properly on some hosts and note down those that fail. See if you can find out hosts causing it and run memtest on those.
-
@Sebastian-Roth The multicast fail on every 3310 but at various time no matter how many host i try. I can’t run a memtest because none of them succeed the multicast. They all get the same error at different time
pigz: skipping: <stdin>: corrupted -- incomplete defl data pgiz: abort: internal threads error
-
@alicevintage said in Can't multicast on latitude 3310:
I can’t run a memtest because none of them succeed the multicast. They all get the same error at different time
What do you mean by you can’t run memtest? This has nothing to do with those being able to multicast or not.
On the other hand I can understand that the fact all your latitude 3310 show this issue is not pointing to it being a memory problem. Do you have other hosts to test with (non latitude 3310)? All those multicast fine?
-
@Sebastian-Roth The memtest task doesn’t work on the 3310 and multicast work fine on other dell latitude or lenovo. Also all our other model use the undionly.kpxe file and the 3310 use the ipxe.efi.
-
@alicevintage said in Can't multicast on latitude 3310:
The memtest task doesn’t work on the 3310 and multicast work fine on other dell latitude or lenovo. Also all our other model use the undionly.kpxe file and the 3310 use the ipxe.efi.
Two points here.
Memtest is a bios only application so it will (should) not run under a uefi bios.
Second point is that you can not deploy a bios based image to a uefi based computer and expect it to boot. I know I may have read too much into your statement. But just be aware.
The 3310 is a somewhat older model so it should work ok imaging. Is the bios up to date on that model? We have the Precision 5510s on our campus and they image correctly using unicast or multicasting. If you still have as delivered bios installed I might upgrade that first and see if anything changes.
-
@george1421 yep the bios is up to date, the capture image was uefi and is getting deployed to a uefi bios. I’m still getting the same error with an up to date bios.
-
@alicevintage Just to be clear you can unicast just fine this same image to the same computer?
Its very rare that unicast works and multicasting doesn’t
I don’t see this asked earlier either (strange) what version of FOG are you using? 1.5.9?
-
Yes, i can unicast the same image just fine on the same machine but multicast doesn’t work. I’m using the version 1.5.9 of FOG.
-
@alicevintage Well since this isn’t a common problem we need to switch to shotgun mode (i.e. just pointing in the direction of something hoping we get a hit).
While I really don’t think this is the issue, lets have you upgrade the version of the FOS Linux kernel to 5.6.18 (WebUI->FOG Configuration->Kernel Update. Click on both the 32 bit and 64 bit buttons for 5.6.18. The default kernel for 1.5.9 is 4.19.143. If you have newer hardware (late 2019 or 2020) you will need this updated kernel anyway.
If you image just one 3310 via multicast does it fail? I know its not the goal here, but its not clear if its multcasting, the kernel, or the network driver on the target computer that is at fault. We are pretty sure its not the FOG server since it works correctly to other devices. The fog server doesn’t act differently for bios and uefi targets while multicasting. So the same program code is called for both types of target computers.
Could location be at fault for multicasting failing to these 3310s? I.e. if you move a 3310 to the same (or very near) switch to the FOG server does it fail with just one 3310?
Do you know what network adapter is installed in the 3310? (Windows device manager -> device -> hardware IDs?
-
@alicevintage said in Can't multicast on latitude 3310:
incomplete deflate data
I have given this some more thought. Especially the fact that unicast works and multicast fails. It will be interesting to see if multicasting to a single machine will also fail. The major difference in this equation is that for unicast we read the image date from a file on a mounted NFS share while for multicast
udp-receiver
is used to read the data stream from the sender. In both cases the data (NFS share orudp-receive
is send to a fifo (first in first out) pipe decompressing the data on the fly. The output of that pipe is read bypartclone
to write the data to disk.To make a long story short, the more I think about it saying “incomplete deflate data” (compared to “invalid deflate data” which we see in other situations) the more I think
udp-receiver
is actually dying at this stage and not delivering the rest of the data.So please take a look at
/var/log/fog/multicast.log
to see if you can find a hint on why this happens. Sure this is kind of the wrong side of where things go wrong but it’s easier to start here. To debugudp-receiver
on the deploying host we’ll need to modify the scripts… -
@sebastian-roth said in Can't multicast on latitude 3310:
more I think udp-receiver is actually dying at this stage and not delivering the rest of the data.
What if we are running out of memory on FOS Linux partition. Where we bumped it up from 127MB to 275MB for the larger inits? This 3rd partition isn’t that large though. My C drive partition is 25GB, but I rarely multicast while imaging. I do remember we had to make the FOS Linux drive for one user before we upped it to 275MB but I can’t remember the circumstance.
Something else we need to be mindful of / is this is an untested image from the perspective of multicasting. This is the first uefi image to the first uefi target computer the OP has. The previous ones have all been bios based.
If I remember correctly when the multicast task starts, it actually spins up one udpsend task for each partition. I wonder if that task is terminating on the server not the target computer. But again why only for uefi systems…