R7800 - Luci sysupgrade OK but command line KO (in 17.01.4)

Hi,

I have already installed (and upgraded) Lede/openwrt many times on different type of routers. I've just bought a Netgear r7800 and installed Lede 17.01.4 and I want to make sure I'll be able to upgrade it easily in the future.

When I try:

sysupgrade lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar

I get:

root@openwrtr7800:/tmp/upgradefirmware# sysupgrade lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar
Saving config files...
Command failed: Request timed out
root@openwrtr7800:/tmp/upgradefirmware# sysupgrade lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar
Saving config files...
Command failed: Not found

As you can notice, on the second run, I get a different error message.

If I use Luci, the upgrade works perfectly. When I have a look at the source code, I see luci is using sysupgrade:

fork_exec("sleep 1; killall dropbear uhttpd; sleep 1; /sbin/sysupgrade %s %q" %{ keep, image_tmp })

I then tried in command line to kill dropbear and uhttpd before doing sysupgrade but I get the same result "request timed out.

Does anybody see any reason why Luci is OK but not command line?

Thanks for your help,
Alex

Not immediately obvious.
I have updated my R7800 some 260+ times, but generally only with LuCI.
Will try sysupgrade.

You might also test sysupgrade without having the settings.

And you do not have any non-config things stored that would somehow disturb the backup process?

Interesting, I got the same problem with my own 17.01 build when trying to "downgrade" to 17.01.4 from (17.01-SNAPSHOT, r3585-421754191d):.

root@LEDE:/tmp/ttt# wget http://downloads.lede-project.org/releases/17.01.4/targets/ipq806x/generic/lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar
...
2017-11-13 22:24:26 (2.86 MB/s) - 'lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar' saved [5048484/5048484]

root@LEDE:/tmp/ttt# sysupgrade  lede-17.01.4-ipq806x-R7800-squashfs-sysupgrade.tar
Saving config files...
Command failed: Request timed out
root@LEDE:/tmp/ttt#

Router gets stuck into a "semi-flashing" state with power LED blinking white & red.
Rebooting it reverted to the existing firmware with all settings intact, I think

I added some debugging commands in the backup function, and actually the backup generating function seems to complete itself. Problem happens later

EDIT:
seems to happen here with platform_pre_upgrade.

I added debug lines:

/sbin/sysupgrade:

...
run_hooks "" $sysupgrade_pre_upgrade
echo "after hooks"
# Some platforms/devices may want different sysupgrade process, e.g. without
# killing processes yet or calling ubus system upgrade method.
# This is needed e.g. on NAND devices where we just want to trigger stage1 at
# this point.
if type 'platform_pre_upgrade' >/dev/null 2>/dev/null; then
        platform_pre_upgrade "$ARGV"
fi
echo "before ubus system upgrade call"
ubus call system upgrade
...

I see the "after hooks" output, but not the "before ubus..." line:

before hooks
after hooks
Command failed: Request timed out

I tested master, and command line sysupgrade works ok from r5322-12f9305c12.
So, this is 17.01 branch-specific.

I guess that the sysupgrade cleanup in May 2017 in master has fixed things there, but that is still somehow broken in 17.01

https://git.lede-project.org/?p=source.git;a=history;f=package/base-files;hb=HEAD

https://git.lede-project.org/?p=source.git;a=history;f=package/base-files;hb=refs/heads/lede-17.01

But no idea, why it works in LuCI but not on console.

Hnyman, thanks for the investigation and the feedback.

I can live with this bug if I know it will get fixed in a future release :). I prefer to stay in "official release" rather than switching to snapshots, it is my future main router and I want to make sure it's stable.

Just for my knowledge, what is the release strategy in Lede ? (it's still unclear to me). In other words, when should the changes made on master be merged on the release branch?

Thanks,
Alexandre

This kind of deep-level sysupgrade strategy changes will likely never get updated to the stable branch.

They will get to the next major release when that will be branched off from the current master. (something like 18.02 or whatever)

Like I said, I have used some 260 different versions of master and 17.01, and the master has been stable some 98% of builds...

But some people claim that 17.01 has currently better wifi performance, as some firmware/ath10k changes may have decreased performance in master. so, 17.01 may be a good option for you.

Ok, I can wait for few versions, it's a non-blocking bug :slight_smile:

Thanks a lot for your feedback, it's really appreciated.

Alex