<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I totally understand.. the fact that the first utility I chose was
    iostat should tell you I understand all of this..  only been doing
    this since 1978..   I will get to the bottom of my issue..  I am
    running, I was just investigation the write speed issue..  I am
    actually sorry I posted this to the list... way too much noise about
    this already.. <br>
    <br>
    Andrew, I hate to break the bad news to you but the "stat" command
    shows the blocking factor of the "block device" the file is
    currently stored on, not the block size of where he originally built
    and stored the file..  yours might be 512, but mine is not... <br>
    <br>
    Thanks for the assist.. guys.. I can handle it from here..   Fred<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/1/15 4:39 PM, Andrew Sylthe wrote:<br>
    </div>
    <blockquote
cite="mid:CAMbt3dsoXdvj+jABhfQZ4RYcHaHxFqm_9ezH+SiiqF655cQ79w@mail.gmail.com"
      type="cite">
      <div dir="ltr">Fred,
        <div><br>
        </div>
        <div>The dd write speed will vary depending on the block size
          you've chosen.  Try experimenting with different block sizes
          (64K 128K 256K 512K 1M 2M 4M 8M) to see if your write speed to
          the SD card increases or decreases.  Personally, I only use
          Class 10 SD cards.  By design they are faster and more
          reliable.</div>
        <div><br>
        </div>
        <div>Also, a stat on the file will tell you that Doug used the
          default 512K block size when writing the image file, so keep
          that in mind.</div>
        <div><br>
        </div>
        <div>Thanks!</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, May 1, 2015 at 7:12 AM, Fred
          Moore <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:fred@fmeco.com" target="_blank">fred@fmeco.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">David:<br>
            <br>
            Ok again downloaded and got the same sha1 as the last 5
            times..  so it<br>
            seems that you are generating the sha1 from another source
            than I am..<br>
            my source is <a moz-do-not-send="true"
              href="http://hamvoip.org/RPi2/RPi2_V1.0_Allstar.zip"
              target="_blank">http://hamvoip.org/RPi2/RPi2_V1.0_Allstar.zip</a>
            which is the<br>
            only link I know of.. so what is the difference here??? 
            point me to the<br>
            correct source please..<br>
            <br>
            As for zip.. don't have a version, as I am not on a windows
            box..<br>
            abandoned that OS totally about 15 years ago..  and don't
            run unzip<br>
            specific code..<br>
            <br>
            I did not ask about the file size as the blocking factor of
            the<br>
            receiving file system will almost always show a different
            file size..<br>
            than you started with,  but checksums will always be
            correct, that is<br>
            the reason I asked for the checksum to start with..<br>
            <br>
            Sitting here thinking (before hitting send) about this I
            just figured<br>
            out the checksum problem.. my mac as well as BSD systems
            unzips the file<br>
            when it is saved to the download directory directory leaving
            the actual<br>
            image file.. That image file is what I generated the sha1
            against..<br>
            That is the SHA1 we should be providing to everyone.. as
            that is what<br>
            counts.. it would be the same across file systems.  Since I
            don't have a<br>
            system that doesn't automatically unzip, I can't generate a
            sha1 on the<br>
            actual zip file..   I think this is my problem in diagnosis
            only.. not<br>
            in actual operation.  The transport compression is not
            material to me..<br>
            nor should it be material to others..<br>
            <br>
            The good news is that the image I dd-ed to the card actually
            appears<br>
            works just fine.. (it boots and runs haven't gone further) 
            I was<br>
            questioning the issues I was seeing..  what lead me there
            was the<br>
            extreme time it was taking with a bs=1m.   As for dd and the
            rest of the<br>
            system.. I have been using dd for to move images and files
            for the last<br>
            15 years.. so trust my abilities and hardware 100%..<br>
            <br>
            If possible can you give me a sha1 of the actual image file,
            that alone<br>
            would verify that the starting image I have is 100%
            correct..<br>
            <br>
            Security Issues:<br>
            Actually I was not asking about significant security
            issues.. I was<br>
            asking about any security vulnerabilities at all.. just look
            at the<br>
            patches that have occurred in just ssl this year..  I think
            I have<br>
            patched my server at least 10 times in the last 6 months..
            (always from<br>
            source) I was concerned about you generating a new image for
            fixes and<br>
            updates. hence the question.. it's unknowns that bother
            me..  Knowing I<br>
            will have to track any fixes I put in place outside what you
            distribute,<br>
            or code I compile onto the system.. that is ok and not an
            issue, just<br>
            wanted to know how I should maintain my stuff on my box..  I
            am paranoid<br>
            about keeping code for critical things up to date.. others
            might think<br>
            that allstarlink is not a critical system, to me any server
            is critical<br>
            as otherwise it wastes my time fixing crap the hackers want
            on my<br>
            system.. thanks for the input.. and thanks for taking the
            time to respond..<br>
            <br>
            Regards.. Fred<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                <br>
                <br>
                <br>
                On 5/1/15 7:22 AM, David McGough wrote:<br>
                > Hi Fred,<br>
                ><br>
                > It appears that still don't have the correct image.
                The stats are:<br>
                ><br>
                > root@testserv/RPi2# shasum RPi2_V1.0_Allstar.zip<br>
                > 5498bea63d11de3edd10294d68256005653e8ff6 
                RPi2_V1.0_Allstar.zip<br>
                ><br>
                > And the file size is: 540,626,394 bytes<br>
                ><br>
                > Once unzipped, the binary flash image will be just
                smaller than 4GB in<br>
                > size.<br>
                ><br>
                > Typically, the zip container will provide a very
                high degree of file<br>
                > integrity for guarding against download failures,
                since it internally<br>
                > includes a checksum....What version of unzip are
                you using?<br>
                ><br>
                > And, to answer your question about significant
                security issues, should one<br>
                > occur, we'll release a patched downloadable image,
                and depending on<br>
                > complexity, perhaps a tarball of replacement
                binares as well.<br>
                ><br>
                > Sorry you're having problems,<br>
                ><br>
                > 73, David KB4FXC<br>
                ><br>
                ><br>
                ><br>
                > On Fri, 1 May 2015, Fred Moore wrote:<br>
                ><br>
                >> Hate to reply to myself.. but I should have
                included the shasum of the<br>
                >> image I was using (downloaded)<br>
                >><br>
                >> d1b4d6367d6b2cd7bcaf6ee613d6243da3e1ddd1<br>
                >><br>
                >> Regards.. Fred<br>
                >><br>
                >> On 5/1/15 3:38 AM, Fred Moore wrote:<br>
                >>> Just curious how vulnerabilities are
                planned for... has a system (other<br>
                >>> than) ABS/Packman been thought out or
                incorporated into this custom Arch<br>
                >>> distribution..  if so is app-rpt going to
                be just a source package in<br>
                >>> the future, how is this going to be
                handled.. I am wondering about<br>
                >>> updates..  patches or ???<br>
                >>><br>
                >>> For some reason when I dd the image to a
                16G class 4 card it took almost<br>
                >>> 2 hours.. I was monitoring the process with
                isotat, it appeared that<br>
                >>> some block sequences were transmitted
                several times each second..<br>
                >>> anyone else seeing this.. I ran this with
                two different files with the<br>
                >>> same result.. ???  Both file's checksum
                agreed.<br>
                >>><br>
                >>> BTW I tested with Rasbarian image and it
                finished in about 15 minutes<br>
                >>> and didn't seem to be having any problem
                when monitored with iostat.  I<br>
                >>> did veryify the sha of all files I
                downloaded with each other...<br>
                >>><br>
                >>> Doug if I may be so bold, would you mind
                publishing the sha checksum's<br>
                >>> on the website, so we don't have to
                download several times and compare<br>
                >>> to each other, and are able to verify a
                100% correct download..   you<br>
                >>> might also think about a code signature..
                so we know code that is not<br>
                >>> from you, but somehow will get out in the
                wild..<br>
                >>><br>
                >>> Thanks for all the hard work... regards..
                Fred<br>
                >>><br>
                >>><br>
                >>><br>
                >>><br>
                >>>
                _______________________________________________<br>
                >>><br>
                >>> arm-allstar mailing list<br>
                >>> <a moz-do-not-send="true"
                  href="mailto:arm-allstar@hamvoip.org">arm-allstar@hamvoip.org</a><br>
                >>> <a moz-do-not-send="true"
                  href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar"
                  target="_blank">http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</a><br>
                >>><br>
                >>> Visit the BBB web page - <a
                  moz-do-not-send="true"
                  href="http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/"
                  target="_blank">http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/</a><br>
                >><br>
                ><br>
                <br>
              </div>
            </div>
            <div class="HOEnZb">
              <div class="h5">--<br>
                Fred Moore<br>
                email: <a moz-do-not-send="true"
                  href="mailto:fred@fmeco.com">fred@fmeco.com</a><br>
                       <a moz-do-not-send="true"
                  href="mailto:fred@safes.com">fred@safes.com</a><br>
                phone:  <a moz-do-not-send="true"
                  href="tel:321-217-8699" value="+13212178699">321-217-8699</a><br>
                <br>
                <br>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            <br>
            arm-allstar mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:arm-allstar@hamvoip.org">arm-allstar@hamvoip.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar"
              target="_blank">http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</a><br>
            <br>
            Visit the BBB web page - <a moz-do-not-send="true"
              href="http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/"
              target="_blank">http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/</a><br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div class="gmail_signature">
          <div dir="ltr">Andrew Sylthe<br>
            KC9ONA<br>
          </div>
        </div>
      </div>
      <br>
      -- <br>
      This message has been scanned for viruses and
      <br>
      dangerous content by
      <a moz-do-not-send="true" href="http://www.mailscanner.info/"><b>MailScanner</b></a>,
      and is
      <br>
      believed to be clean.
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Fred Moore
email: <a class="moz-txt-link-abbreviated" href="mailto:fred@fmeco.com">fred@fmeco.com</a>
       <a class="moz-txt-link-abbreviated" href="mailto:fred@safes.com">fred@safes.com</a>
phone:  321-217-8699
</pre>
  </body>
</html>