Thanks for the info, it helped.
I have 3 nodes in total. One was an older version of ubuntu with an earlier SVN, and this was affecting the bandwidth monitor. I removed it and the 2 up-to-date nodes come up on the monitor. Thanks Wayne.
Best posts made by Mark Shelton
-
RE: R4664 missing bandwidth graphposted in Bug Reports
-
1.3.0-RC-6 Image replication calculation errorposted in Bug Reports
Hi Tom/Wayne,
Just installed RC-6. The image replication calculation is still slightly out for local file sizes. Local file sizes are all showing up as 8 bytes smaller than the remote file sizes, so will loop on all files now. See attached log screenshot.
Regards, Mark

Latest posts made by Mark Shelton
-
Imaging error from Raspberry Piposted in FOG Problems
I’ve managed with the groups assistance to successfully install FOG on a Raspberry Pi 4, which is great. It is set up as a storage node, and I have replicated images from the master node which is a PC-based version of Ubuntu 18.04.4 LTS, to the Raspberry Pi, which is Ubuntu 18.04.3 LTS.
A PC selected to have its image downloaded from the Raspberry Pi PXE boots and begins the process, until partclone is run up. The attached error appears
“read image_hdr device_size error”
and the image will not download. This error appears for each partition that is to be imaged. If I upload an image from a PC it will download successfully, but not if it has been replicated from a PC based imageserver to the Pi used as an imageserver.
Any ideas please? -
RE: Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
@Sebastian-Roth that worked. Thanks very much.
-
RE: Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
@Sebastian-Roth I made the changes and re-ran the install. Same result unfortunately.
I have attached the error log and install log[1_1582602880272_fog_error_1.5.7.log](Uploading 100%) [0_1582602880271_foginstall.log](Uploading 100%)
-
RE: Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
@Sebastian-Roth Output as requested…
processor : 0
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3processor : 1
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3processor : 2
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3Hardware : BCM2835
Revision : c03111
Serial : 10000000a46e436e
Model : Raspberry Pi 4 Model B Rev 1.1Regards, Mark
-
RE: Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
@Sebastian-Roth…and will upload the result from the grep also…
-
RE: Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
@Sebastian-Roth thank you for such a quick answer! It’s 8:44pm where I am in Australia so I’ll make the change tomorrow and see how we go.
-
Configuring UDPCast fails on Raspberry Pi 4posted in FOG Problems
I’m building a FOG Imageserver on a Raspberry P i4.
Install fails at “Configuring UDPCast”
Upon investigation of the error log file, it appears that GNU cannot guess the the build type.
Whats the best way to approach this…the error log reports that the config.guess file is from 07/02/2006.Error log file attached.fog_error_1.5.7.log
-
RE: 1.3.0-RC-6 Image replication calculation errorposted in Bug Reports
@Tom-Elliott I think this latest patch fixed the issue. The smaller file sizes match and the local size of the largest file is now accurate, so I anticipate when fully replicated the large files will also match. I’ll let you know. Thanks Tom.
-
RE: 1.3.0-RC-6 Image replication calculation errorposted in Bug Reports
@Wayne-Workman I believe Tom’s latest patch has fixed the issue. I wont know for certain until the largest file has replicated which will take a couple of days, but the others match now and the largest file local size is accurate, so I’m quietly confident.