Skip to content
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

Closed
openwrt-bot opened this issue Aug 19, 2018 · 5 comments
Closed

FS#1797 - AR670w upgrade fails with 'platform_check_image' #6947

openwrt-bot opened this issue Aug 19, 2018 · 5 comments
Labels

Comments

@openwrt-bot
Copy link

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...

@openwrt-bot
Copy link
Author

danielg4:

This is caused by commit 5505ab5 and is probably a bad thing, considering the cc5194c commit message…

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

danielg4:

Fixed with 0f3ec67 for the 18.06.2 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant