• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Mark Shelton
    3. Posts
    • Profile
    • Following 0
    • Followers 0
    • Topics 11
    • Posts 49
    • Best 2
    • Controversial 0
    • Groups 0

    Posts made by Mark Shelton

    • Imaging error from Raspberry Pi

      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 imageerror.jpg

      “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?

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @Sebastian-Roth that worked. Thanks very much.

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @Sebastian-Roth fog_error_1.5.7.log foginstall.log

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @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%)

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @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 : 3

      processor : 1
      BogoMIPS : 108.00
      Features : fp asimd evtstrm crc32 cpuid
      CPU implementer : 0x41
      CPU architecture: 8
      CPU variant : 0x0
      CPU part : 0xd08
      CPU revision : 3

      processor : 2
      BogoMIPS : 108.00
      Features : fp asimd evtstrm crc32 cpuid
      CPU implementer : 0x41
      CPU architecture: 8
      CPU variant : 0x0
      CPU part : 0xd08
      CPU revision : 3

      processor : 3
      BogoMIPS : 108.00
      Features : fp asimd evtstrm crc32 cpuid
      CPU implementer : 0x41
      CPU architecture: 8
      CPU variant : 0x0
      CPU part : 0xd08
      CPU revision : 3

      Hardware : BCM2835
      Revision : c03111
      Serial : 10000000a46e436e
      Model : Raspberry Pi 4 Model B Rev 1.1

      Regards, Mark

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @Sebastian-Roth…and will upload the result from the grep also…

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: Configuring UDPCast fails on Raspberry Pi 4

      @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.

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • Configuring UDPCast fails on Raspberry Pi 4

      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

      posted in FOG Problems
      Mark SheltonM
      Mark Shelton
    • RE: 1.3.0-RC-6 Image replication calculation error

      @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.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: 1.3.0-RC-6 Image replication calculation error

      @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.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: 1.3.0-RC-6 Image replication calculation error

      @Tom-Elliott Have tried the patch. The numbers add up now, but it is still saying “Files do not match” and writing over them repeatedly. I tried to upload an image of the log but don’t have privileges to upload on this thread.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: 1.3.0-RC-6 Image replication calculation error

      @Wayne-Workman Sorry I should have put it directly in here. Unfortunately a fix didn’t make it into RC-7. Roll on RC-8!

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • 1.3.0-RC-6 Image replication calculation error

      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
      0_1470276293033_replicationlog.jpg

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Wayne-Workman Thanks, yes I may move to 64 bit. However it’s good that my issue has highlighted the inconsistency in the code which sounds like it only shows up in 32 bit OS’s. I’m guessing there mustn’t be too many others with my setup out there, otherwise this would have been reported a while ago. Glad its a relatively easy fix, I’ve rebuilt these boxes a few times recently and didn’t wish to have to do it again. Regards, Mark

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Tom-Elliott I’m so pleased you found the issue so quickly! I’ve had to turn off replication for the last number of releases and upload them when at the sites. Didn’t want to post about it until I had done some investigation and had evidence of the exact issue.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Tom-Elliott Thanks Tom. I’ll wait a few days for RC-6. Regards, Mark

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Wayne-Workman It worked in the past. I have always used 32 bit filesystems, and the remote server is also 32 bit.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Tom-Elliott Yes all are FOG 1.3.0 RC4 SVN 5941. All have Ubuntu 14.04 installed. Interesting that the local file size is always incorrect for the large files. This has been happening for a while, I’ve only just realised why.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Wayne-Workman I will try that, but this issue has been happening for a few releases. I’ve not noticed anyone else reporting the problem so not sure if it has been addressed.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • RE: Image replication loop - incorrect file size calculation

      @Tom-Elliott Yes 32 bit. However it reads the remote image size accurately which is also 32 bit.

      posted in Bug Reports
      Mark SheltonM
      Mark Shelton
    • 1 / 1