New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#1797 - AR670w upgrade fails with 'platform_check_image' #6947
Comments
danielg4: That is to say, it is not clear whether the magic in platform.sh was introduced purely for OpenWrt's convenience or is actually expected by the bootloader. If the latter, then the LZMA dictionary size for this device must be left at the default, so 5505ab5 would brick the device. If the former, then the resolution is to fix it in platform.sh instead. I have neither this device nor its bootloader source code to check. |
tft: I will continue to look for the bootloader source code to address the question noted above (the source from the manufacturer was named 'ar670w_GPL_062508.tar.gz'). In the meantime, and building on older openwrt and lede images, can't we institute a build mechanism wherein LZMA does not limit the dictionary size on this (& similar) devices ? Better safe than sorry, no ? If there is a method to test/experiment without running the risk of bricking the device, I'd be more than happy to help. |
tft: I haven’t been able to find the vendor’s bootloader source code (will continue to look) but I did inspect and hexdump a plethora of .bin images. One thing is very clear 0x6d000080 is VERY prevalent not only in openwrt/lede/dd-wrt images but even in the vendor’s own binary files (though at offset address 60’h akin to the “factory” files); I’ve look at upwards of 12 files and there is definitely a pattern here with all of them containing that specific hex value. As such, I highly recommend instating a mechanism to un-break the current build process (relating to LZMA) at least for this device family – I’m 90% certain another value will brick the device as will a “sysupgrade –F” (someone more adventurous is very welcome to prove me wrong). In passing, this is an extremely “severe” issue and should attain a reasonably high priority to resolve at least for those of us using this device. |
danielg4: Fixed with 0f3ec67 for the 18.06.2 release. |
tft:
Currently running 'LEDE Reboot 17.01.5 r3919' attempted to upgrade to 18.06.1 via the GUI, it failed. SSH'ed and attempted a
sysupgrade -T openwrt-18.06.1-ramips-rt288x-ar670w-squashfs-sysupgrade.bin
which produced,
Image metadata not found
Invalid image type.
Image check 'platform_check_image' failed.
I did a bit of investigating (post some google searching) and it looks like the new .bin header isn't correct. A hexdump of the new .bin (https://pastebin.com/Z2K7kTPn) notes 0x6d000020 (first 4 bytes) while the /lib/upgrade/platform.sh does a check for 0x6d000080 ('670w' entry) and therein is the error.
So the question is why does the new .bin have a different "ramips_board_name" value ? The old(er) LEDE images correctly ended with 0x80.
I didn't feel comfortable doing a 'sysupgrade -F' (ie. Force) as I don't know what forceful measure that would take and what else might be misaligned...
The text was updated successfully, but these errors were encountered: