Forum Replies Created

Viewing 8 posts - 11 through 18 (of 18 total)
  • Author
    Posts
  • in reply to: File integrity checksums for downloads #1201

    FYI, This worked, straight away.
    ////

    Again…
    When you download you will get this file:
    openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz, 288827732
    [md5: a6ef8ae74ba98da30e4135b004a091f8 openrepeater-raspi2-1.0.0-beta1-07_07_15a.img.gz]

    When you gunzip it, you will get:
    openrepeater-raspi2-1.0.0-beta1-07_07_15.img, 294905339
    [md5: ea0aa74ad828573c3a46652743dd7322 openrepeater-raspi2-1.0.0-beta1-07_07_15.img]

    This is **STILL A GZIP ARCHIVE**
    at this point, add “.gz” back to the filename, then redo your gunzip process.

    After the second gunzip, you will get:
    openrepeater-raspi2-1.0.0-beta1-07_07_15.img 3904897024
    [md5: 7c26700377369e0fc35504de6a9e4c65 openrepeater-raspi2-1.0.0-beta1-07_07_15.img]

    Im now looking at SetThis-repeater tty1, just as I hoped to be a couple days ago <g> 🙂

    Kind regards,
    Joe

    in reply to: File integrity checksums for downloads #1200

    Oh, my! I think I figured something out:

    jre@hex:~$ ls -als
    282060 -rw-r–r– 1 jre jre 288827732 Aug 6 14:25 openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz

    jre@hex:~$ file *
    openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz: gzip compressed data, from Unix

    jre@hex:~$ gunzip openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz

    jre@hex:~$ file openrepeater-raspi2-1.0.0-beta1-07_07_15.img
    openrepeater-raspi2-1.0.0-beta1-07_07_15.img: gzip compressed data, was “openrepeater-raspi2-1.0.0-beta1-07_07_15.img”, from Unix, last modified: Thu Jul 9 11:22:09 2015

    It says “.img” after extraction, but STILL SAYS it is gzip compressed data! I think someone gzipped it then renamed it to an img, then gzip’d it again.

    re@hex:~$ gunzip openrepeater-raspi2-1.0.0-beta1-07_07_15.img
    gzip: openrepeater-raspi2-1.0.0-beta1-07_07_15.img: unknown suffix — ignored

    Well, we’ll rename it then.. *sigh*
    re@hex:~$ mv openrepeater-raspi2-1.0.0-beta1-07_07_15.img openrepeater-raspi2-1.0.0-beta1-07_07_15.gz
    jre@hex:~$ gunzip openrepeater-raspi2-1.0.0-beta1-07_07_15.gz

    jre@hex:~$ ls -alsh
    3.7G -rw-r–r– 1 jre jre 3.7G Aug 6 16:27 openrepeater-raspi2-1.0.0-beta1-07_07_15

    Hey, look, gigabytes!

    jre@hex:~$ file *
    openrepeater-raspi2-1.0.0-beta1-07_07_15: x86 boot sector; partition 1: ID=0xe, starthead 0, startsector 2048, 247808 sectors; partition 2: ID=0x83, starthead 3, startsector 249856, 6041600 sectors, code offset 0xb8

    //

    TL:DR version:
    When you gunzip the .img.gz file, you get an ‘.img’ file. This is STILL A GZIP’d File, you must gunzip it again, which may require renaming.

    Gunzip it again. The result is an image file. you want to rename that as an .img then burn THAT to an SD.

    .. which I am doing now. I’ll post results!

    //
    Thanks! Glad I was tenacious about this. ticked that I didn’t think of this earlier. It explains why this had mixed favorable results – I am guessing depending on the “auto extraction methods” programs have out there, that this wasn’t caught and was being missed by a process along the way.

    -joe

    PS; actual on-disk size and md5:
    jre@hex:~$ mv openrepeater-raspi2-1.0.0-beta1-07_07_15 openrepeater-raspi2-1.0.0-beta1-07_07_15.img

    jre@hex:~$ ls -als openrepeater-raspi2-1.0.0-beta1-07_07_15.img
    3813380 -rw-r–r– 1 jre jre 3904897024 Aug 6 16:27 openrepeater-raspi2-1.0.0-beta1-07_07_15.img

    jre@hex:~$ md5sum openrepeater-raspi2-1.0.0-beta1-07_07_15.img
    7c26700377369e0fc35504de6a9e4c65 openrepeater-raspi2-1.0.0-beta1-07_07_15.img

    in reply to: File integrity checksums for downloads #1199

    I get:

    post-download, repeatably, I get:

    -rw-r–r– 1 … … 288827732 Aug 6 14:28 openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz

    [md5: a6ef8ae74ba98da30e4135b004a091f8 openrepeater-raspi2-1.0.0-beta1-07_07_15a.img.gz]

    gunzip:
    -rw-r–r– 1 … … 294905339 Aug 6 14:28 openrepeater-raspi2-1.0.0-beta1-07_07_15.img

    [md5: ea0aa74ad828573c3a46652743dd7322 openrepeater-raspi2-1.0.0-beta1-07_07_15.img]

    {system: $ uname -a
    Linux hex 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux}

    in reply to: File integrity checksums for downloads #1198

    Weird. I pasted the URL into links just now and saw a 1% of 990MB (I think) and it began climbing.

    I stopped my pcap and restarted, and now I get a 288.8MB file.

    still testing.

    in reply to: File integrity checksums for downloads #1196

    Hi Nils, I experienced this too, early with my tests.

    To save you the trouble from someone who has walked the path, there’s a redirect (reverse proxy? something..) in the download mechanism. Thus, curl/wget won’t work .. but if you paste the URL into something like links+ / lynx downloading is possible… 🙂

    I meant to wireshark the http request and descipher the base URI and try wget/curl again myself with the export URI, but after geographic separation tests failed, I chalked it up to image issues and stopped trying to “redownload the wheel.”
    (is that a term? can it please be one? 🙂
    -joe

    in reply to: File integrity checksums for downloads #1193

    I should have edited that better.
    TL;DR version:
    I’m testing with several microSD cards on two Rpi2 units.
    (the third test unit was the older unit you refer to, which I didn’t expect to work..)

    Sorry about any ambiguous wording. I do better on twitter when I am forced not to ramble 😉

    in reply to: File integrity checksums for downloads #1192

    Hi,

    The primary test device I am working with is a Raspberry Pi 2.

    (my third device is a Raspberry Pi v1 B+ which I don’t expect to work, but since it wasn’t booting in either of the Pi 2 units, I figured I’d see if it would even try to bootstrap, but it does not. The disk read light simply comes on solid and stops).

    (I have a fourth RPi v1.2 but didn’t bother butting the microSD into a full size SD adapter to try it..)

    I downloaded the gz image from my OpenBSD box and my ubuntu box. Used gunzip native to both.

    All downloaded files were the same byte size and same checksum on both download and unzip.

    All methods for “baking” the image to a microSD failed to produce bootable media.

    I went back to using an 8gig microSD to repeat the tests, twice with ApplePi Baker and once with the traditional “dd” command.

    I will have access to an EeeBOX-based debian machine this evening and am hoping to try several methods on it with its built-in SD card reader (with the 8gig and 16gig card in a suitable adapter) and will repeat some tests..

    But honestly, I consider myself pretty adept at these sorts of things and am thinking I’m not really making any n00b mistakes so far.

    (I actually went a little beyond the realm of sanity, thinking that some Akamai host in my area was caching an incomplete download and serving it to our local area ISPs, so I used team viewer to remote control a host in Sunnyvale and repeat the download, but the downloaded file sized matched as did the MD5, so it didn’t appear to be a partial/corrupt/bad-cache download issue)

    Maybe you guys could re-bake the image? I’ve tested a copy of n00bs, rasping, and RISC from the raspberrypi.org site (just to make sure I’m not a complete failure at writing bootable SD media… success) and I honestly feel like the image isn’t usable for some reason.

    Thanks!
    Joe

    in reply to: File integrity checksums for downloads #1188

    Hi All,
    I hate to keep this thread alive, as it’s at such a basic level.

    But, I now have nine (9) different downloaded copies of the beta gz/image.

    All are around 275M compressed (281M uncompressed).

    I’ve downloaded on Safari/Mac, Firefox/Mac, Firefox/PC, IE11/PC, and as a last-ditch effort from chrome on my android phone.

    All appear exactly the same.

    I’ve extracted with the auto-extraction that safari does, command line ‘gunzip’ on mac, and with 7zip on windows.

    All of the resulting .img files are the same.

    I’ve attempted writing the SD card with ApplePi Baker on Mac, and with “dd” on the command line (sudo dd bs=1m if=openrepeater-raspi2-1.0.0-beta1-07_07_15.img of=/dev/disk2).

    The results are always successful and error-free, but produce an SD card that is not bootable on any of my 3 RPi units.

    In contrast, I re-downloaded an official image (2015-05-05-raspbian-wheezy.img) which is similarly created just fine, results error-free in an SD card, and boots on all three units just fine, without issue.

    I’m convinced the file being served is somehow broken.

    as a last-ditch effort I dropped to my BSD box and am downloading with links, will extract there, and scp the image to a non-headless box I can more easily write an SD image with.

    Anyway, Just posting my results so far. Haven’t gotten to the point where I can work with the beta, still tripping on getting a usable image.

    Is there perhaps an alternate download location? Torrent?

Viewing 8 posts - 11 through 18 (of 18 total)