OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Tim Freedom - 19.08.2018
Last edited by Jo-Philipp Wich - 30.01.2019

FS#1797 - AR670w upgrade fails with 'platform_check_image'

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 0×80.

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

Closed by  Jo-Philipp Wich
30.01.2019 12:42
Reason for closing:  Fixed
Additional comments about closing:  

Fixed with https://g it.openwrt.org/?p=openwrt/openwrt.git;a= commitdiff;h=0f3ec67a838856a4114406a6de5 789fdb36600bd

Daniel Gimpelevich commented on 19.08.2018 20:32

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

Daniel Gimpelevich commented on 19.08.2018 21:39

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

Tim Freedom commented on 19.08.2018 23:17

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.

Tim Freedom commented on 20.08.2018 19:59

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.

Daniel Gimpelevich commented on 30.08.2018 09:34

Fixed with 0f3ec67 for the 18.06.2 release.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing