[Jonathan, N4VX]

@devs
Could someone with the “master copy” of the .img files post the md5/sha256 sums of the files so anybody downloading an zipped image could verify the integrity of what they were downloading?

Thanks
Jonathan
KF4NVX

[Aaron, N3MBH]

Jonathan,
Thanks for the input. We plan to offer checksums on future downloads. For now we have gotten the RPI2 image remade at a third the size so that should help with the file not completing in some circumstances. Thanks for the patience as we build our infrastructure and refine our work flow.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Joseph, N8CN]

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?

[Aaron, N3MBH]

Greeting and welcome to the forum. Thanks for you patience. The actually IMG file has that is being hosted has been download by one of the developers and verified working. We are working to change the download structure in the future to hopefully be more reliable to the couple of folks that have had issues.

First I need to verify what Raspberry Pi Model you are trying to run on. Above you state that the SD card is not bootable on any of the 3 RPIs that you have. Please note that as of right now this image is only supported on the new Raspberry Pi 2…which looks identical to the model B+ but it has a quad-core process and 1GB of ram.

This is because the installation is running straight Debian compiled for the quad-core processor and not running Raspbian. Therefore this IMG is not compatible with earlier single-core versions of the Raspberry Pi such as the Model B, B+, A, or A+.

Based on the information you provided, it sounds like you are running an older RPI and not the RPI2. Your download sizes seem to match, you have no issues uncompressing the file, and no errors writing to the SD card. Sounds like you also ruled out the SD card by putting a copy of Raspbian on it.

So if you are running on an older RPI, the prebuilt IMG is current incompatible with those boards. It is possible to built your own install on the older boards. We have a build script; however, we do not offer support on that yet and we have not written a tutorial on how to do so. I started the project on the older PI, but results were buggy. That older board was fried and has not been replace. If you are running on a Newer RPI2, let me know and I can send you a direct link until we refine out download infrastructure.

Thanks for your interest in the project, and I hope you are able to get something up and running.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Joseph, N8CN]

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

[Joseph, N8CN]

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 😉

[Anonymous]

I experience the same problem – downloaded file, name “openrepeater-raspi2-1.0.0-beta1-07_07_15.img.gz”, with a size of 275 MB (288 827 732 bytes). And it won’t boot!

And when I try WGET on my Linux server I get a 403: Forbidden:

# wget https://openrepeater.com/download/921
–2015-08-06 19:55:38– https://openrepeater.com/download/921
Resolving openrepeater.com (openrepeater.com)… 173.254.102.230
Connecting to openrepeater.com (openrepeater.com)|173.254.102.230|:80… connected.
HTTP request sent, awaiting response… 403 Forbidden
2015-08-06 19:55:43 ERROR 403: Forbidden.

So I agree with OP – there is something sick with the server providing the file.

[Joseph, N8CN]

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

[Anonymous]

I tried it and get the same size as before. But the question is – how large shall the file be?

Any checksum to use to verify the integrity?

/Nils

[Joseph, N8CN]

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.

[Author]

Posts