How do I fix sha256sum not matching a downloaded ext4 image?

First off, the firmware selector is such a great tool! My gratitude to the builders.

I'm trying to run latest OpenWrt on a SBC called Beaglebone Black.
I found the firmware selector has a snapshot build

I downloaded, gunzipped, then ran:

sha256sum openwrt-omap-generic-ti_am335x-bone-black-ext4-sdcard.img 
81c1ac553103cc0f9e123ec21168968b6c45e67c42bab8b247f3afe6e533f99a  openwrt-omap-generic-ti_am335x-bone-black-ext4-sdcard.img

The firmware selector says it should be d20df1b70c4b1994a523983d35aba7f55f6e3d3851071e5f26ff20bbe97d666e.

Has anyone run into this problem with snapshot builds for older devices? Any tips on how to diagnose why the sha256sum is off here?

Download it again

1 Like

Thanks darksky! I tried the same steps and still compute 81c1ac553103cc0f9e123ec21168968b6c45e67c42bab8b247f3afe6e533f99a for my downloaded .img.

That helped me realize my mistake. I was computing the sha256sum of the img not of the archive.
The firmware selector sha256sum is for the gunziped image!
That indeed aligns:

sha256sum openwrt-omap-generic-ti_am335x-bone-black-ext4-sdcard.img.gz 
d20df1b70c4b1994a523983d35aba7f55f6e3d3851071e5f26ff20bbe97d666e  openwrt-omap-generic-ti_am335x-bone-black-ext4-sdcard.img.gz
2 Likes

I understand you mistake was checking the uncompressed file. Although rare, sometimes the downloaded file will not match and re-downloading fixes it. This is why sig files are published with archives and any good package manager will include a sig check before installing it. Anyway, glad you're up and running.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.