Yeah I first tried using LuCI, and then immediately tried using sysupgrade.
I have two of these devices. I just tried on the other one (running the same 18.06.01 image), with the same result.
Does sysupgrade -v --test /tmp/desired_upgrade_image provide more insight?
root@OpenWrt:/tmp# sysupgrade -v --test /tmp/openwrt-18.06.2-ar71xx-generic-ens202ext-squashfs-sysupgrade.bin
Image metadata not found
This is all it says. Not sure if the metadata warning is an issue, or safely ignorable?
Have you verified the integrity of the image against the sha256 hash that is published in the download page?
Yup for sure!
Not sure if connected somehow, but there is another post for the same problem.
This sounds like another occurence of 'silent' error in sysupgrade (which I consider a dangerous bug), preventing successful upgrade. One likely reason is insufficient RAM for sysupgrade.To verify, just kill the most memory hungry processes before sysupgrade, and disable swap, dismount mass storage devices, if present.
If it works, pls confirm the bug, I reported already here:
https://bugs.openwrt.org/index.php?do=details&task_id=2024&string=sysupgrade&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
For what it is worth, I use swap as well, so next time I will try swapoff ; sysupgrade ... (assuming I remember)
root@OpenWrt:/tmp# free
total used free shared buffers cached
Mem: 60320 25360 34960 4272 1748 10988
-/+ buffers/cache: 12624 47696
Swap: 0 0 0
I don't have any swap enabled on the router. I've also got ~35MB of free RAM. Anything in particular you'd like me to try?
On the R8000 I killed haproxy and unbound, giving:
total used free shared buffers cached
Mem: 254232 57000 197232 8372 1976 20908
-/+ buffers/cache: 34116 220116
Swap: 0 0 0
Tried "sysupgrade -v .." again.
Still no joy - router comes back as 18.06.1
On next try, just gracefully stop all active services before sysupgrade, "/etc/init.d/service stop"
And verify, it exited.
Kill all your user processes, if any.
In summary, to have the system as quiet as possible.
And verify, that the new image really works, when flashed directly.
Stopped services, and killed user processes.
After reboot, still showing 18.06.1
Not sure what I need to do to achieve that - could you let me know what I should do, please?
Image metadata not found
Found CHK image with device board_id U12H315T00_NETGEAR
Found a valid TRX version 1
Saving config files...
...
Commencing upgrade. Closing all shell sessions.
PID USER VSZ STAT COMMAND
1 root 1380 S /sbin/procd
2 root 0 SW [kthreadd]
4 root 0 IW< [kworker/0:0H]
6 root 0 IW< [mm_percpu_wq]
7 root 0 SW [ksoftirqd/0]
8 root 0 IW [rcu_sched]
9 root 0 IW [rcu_bh]
10 root 0 SW [migration/0]
11 root 0 SW [cpuhp/0]
12 root 0 SW [cpuhp/1]
13 root 0 SW [migration/1]
14 root 0 SW [ksoftirqd/1]
15 root 0 IW [kworker/1:0]
16 root 0 IW< [kworker/1:0H]
117 root 0 SW [oom_reaper]
118 root 0 IW< [writeback]
119 root 0 IW< [crypto]
121 root 0 IW< [kblockd]
123 root 0 IW< [watchdogd]
150 root 0 SW [kswapd0]
214 root 0 IW< [pencrypt]
216 root 0 IW< [pdecrypt]
338 root 0 SW [spi0]
429 root 0 IW [kworker/1:1]
478 root 0 IW< [ipv6_addrconf]
490 root 0 SW [ubi_bgt0d]
495 root 0 IW< [kworker/0:1H]
496 root 0 IW< [kworker/1:1H]
499 root 0 IW [kworker/0:2]
500 root 0 IW [kworker/0:3]
516 root 0 SW [irq/40-gpio-key]
517 root 0 SW [irq/41-gpio-key]
518 root 0 SW [irq/42-gpio-key]
519 root 0 SW [irq/43-gpio-key]
654 root 0 SW [ubifs_bgt0_1]
857 root 1028 S /sbin/ubusd
858 root 720 S /sbin/askfirst /usr/libexec/login.sh
952 root 0 IW< [cfg80211]
967 root 0 SW [irq/44-brcmf_pc]
968 root 0 IW< [msgbuf_txflow]
1057 root 0 SW [irq/45-brcmf_pc]
1058 root 0 IW< [msgbuf_txflow]
1077 root 0 SW [irq/45-brcmf_pc]
1078 root 0 IW< [msgbuf_txflow]
1618 root 1564 S /sbin/netifd
3838 root 924 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
4032 root 860 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
4042 root 1100 S -ash
6594 root 0 IW [kworker/u4:2]
6595 root 0 IW [kworker/u4:3]
6612 root 924 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
6613 root 1100 S -ash
6982 root 1288 S /usr/sbin/odhcpd
7023 root 0 IW [kworker/0:0]
7341 root 0 IW [kworker/1:2]
7400 root 0 IW [kworker/1:3]
7401 root 1644 S /usr/sbin/hostapd -s -P /var/run/wifi-phy2.pid -B /v
7423 root 0 IW [kworker/1:4]
7426 root 0 IW [kworker/u4:0]
7718 root 1664 S /usr/sbin/hostapd -s -P /var/run/wifi-phy1.pid -B /v
7865 root 1072 S /usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan
8032 root 1664 S /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /v
8202 root 852 S odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 pppoe
8300 root 924 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
8301 root 1100 R ps
I.e.
mtd -r write /tmp/lede-ar71xx-generic-wzr-hp-ag300h-squashfs-sysupgrade.bin firmware
However, all custom configs will be lost. You might consider to do a backup of config before:
https://openwrt.org/docs/guide-user/troubleshooting/backingup
Thanks.
On the R8000:
mtd -r write /tmp/openwrt-18.06.2-bcm53xx-netgear-r8000-squashfs.chk firmware
Image check failed.
A reason, at least. Feel free to confirm the bug report, I filed, with your comments.
Bad idea of sysupgrade to 'forget' such erros, reported from lower level routines.
In such case, no boot should happen, and report of detected error in system log.
17.01.x changed sysupgrade to work in a detached mode, which is safer (reverting into an initramfs like mode, with sysupgrade taking over the init job), but comes at the expense that debug messages aren't visible over ssh anymore (leaving just serial as an option to observe its actions) and that the device must reboot afterwards.
1 Like
Thank you. I'm not seeing a bug report yet - maybe it takes time to filter through - or (more likely) I'm looking in the wrong place.
We know, thanks to slh reply, that sysupgrade is unable to supply the mtd error to the user over ssh or on-device log.
But I wonder what is next step - would it be to wait for an updated openwrt-18.06.2-bcm53xx-netgear-r8000-squashfs.chk which does not fail the Image check?
Bug report: I mentioned a link up here. Pls, add your observations. Your problem seems to be another manisfestation of the 'silent' errors during sysupgrade, reported nowhere. Which is really dangerous when doing (unattended) remote sysupgrade. The new behaviour, mentioned by slh, seems to be rather buggy and needs serious overhaul.
Ah yes - I see the link earlier in the thread now. Apologies for misunderstanding you.
The bug report refers to sysupgrade silent failure with swap enabled. The issue I'm seeing is not related to swap, as far as I know, in that I haven't ever had swap enabled. Not sure that adding to that bug report would assist in that case?
According to slp, sysupgrade 'functions as designed' in that there can be silent failures. Not ideal, for sure, but I don't know what else can be done, unless there's a change request made.
I don't know what is preventing the upgrade on this R8000.
Since reading more on the forums, I realize I've been doing something very much frowned upon - applying the modules from opkg list-upgradable. I'm wondering if this might have any bearing on the failure to sysupgrade. Thinking maybe a firstboot/reboot to clean up and try again?
I'll keep an eye on this post and others that are describing failures to update, for any suggestions or breakthroughs. I'll try upgrading again if/whenever anyone wants me to try assist in debugging what's going on.
That would be a good idea. Take a backup and do the firstboot.