No. That has nothing to do with the bug I am intermittently seeing.
That fix only declares compatibility, making the usage of force unnecessary with a ar71xx--> ath79 sysupgrade.
My observation is about sysupgrade starting ok, but getting stopped before that actual flashing happens. I thought that the commit above that I referenced, was the fix, but that was likely only half of the fix.
I tried to update with the above fix but it did not work for me either. I am currently on ath79-master-r11447. My WNDR3700v2 is rebooting immediately without flashing at all although I have applied the fix above.
I think that there is something similar missing, like what b20b997c68 fixed: a missing script. Likely b20b997c68 fixed the bug just partially, and there is another currently needed script that may get lost.
But finding that will require attaching a serial cable for system console monitoring during the sysupgrade.
The interesting thing is that I have only seen the problem on ar71xx/ath79 WNDR3700 series, but not on ipq806x/R7800.
If you manually edit lib/upgrade/stage2 , you may succeed on some sysupgrade try.
I did edit this file, but my router just reboots before flashing.
how do you upgrade via ssh?
By downloading the firmware to /tmp and then using the sysupgrade script (which also LuCI used to actually do the sysupgrade).
For me it seems to be intermittent. First the flash fails, but the next attempt works.
I see this since more than half a year, that the first flash usually does not "hold"/succeed. The second one after the reboot coming from the unsuccessful flash so far always worked okay. Never bothered to dig deeper into this (would be great if the router could store an update log somewhere where it can be fund and read on next boot).
I noticed that maybe 1-2 months ago occasionally with WNDR3700, but so rarely that I did not look into it. Now it seems to be more frequent with the recent sysupgrade changes.
I perfectly managed to update today editing the file /lib/upgrade/stage2 replacing
"install_file /etc/resolv.conf /lib/.sh /lib/functions/.sh /lib/upgrade/.sh /lib/upgrade/do_stage2 $RAMFS_COPY_DATA"* with "install_file /etc/resolv.conf /lib/.sh /lib/functions/.sh /lib/upgrade/.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh $RAMFS_COPY_DATA"*
and using the builds WNDR3700v2-master-r11558-3cee6f3f24-20191120-1926-sqfs-sysupgrade.bin (ath79-master) and WNDR3700-master-r11546-a74095c68c-20191119-1953-sqfs-sysupgrade.bin (ar71xx-master)
Thank you!
Hi hnyman,
I've tried to use your build scripts to do my own builds. But it seems that they are outdated. I managed to update the source files doing some fixes to paths in your scripts, but I've failed compiling them:
...make the firmware...
...create version info file...
hnscripts/timestampVersion.sh: line 8: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 9: files/etc/Compile_info.txt: No such file or directory
fatal: not a git repository (or any of the parent directories): .git
hnscripts/timestampVersion.sh: line 10: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 11: cd: feeds/luci: No such file or directory
hnscripts/timestampVersion.sh: line 11: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 12: cd: feeds/packages: No such file or directory
hnscripts/timestampVersion.sh: line 12: files/etc/Compile_info.txt: No such file or directory
hnscripts/timestampVersion.sh: line 13: cd: feeds/routing: No such file or directory
hnscripts/timestampVersion.sh: line 13: files/etc/Compile_info.txt: No such file or directory
cat: files/etc/Compile_info.txt: No such file or directory
fatal: not a git repository (or any of the parent directories): .git
...make world...
I've called the updateNmake.sh from the parent folder as suggested in the readme. But it seems that the paths do not fit anymore. files/etc has moved to master/package/base-files/files/etc ? But from searching .../files/etc there seem to be some more options...
It would be great, if you could update the build scripts. Many thanks in advance!
BR. - nieroster
The current build scripts are included with each build I publish.
And nothing has moved to basefiles...
Sorry to bother you. There were a few misunderstandings. First I forgot the patch files, 2nd I used the general build scripts you have in your dropbox, not the ones for the specific build (ar71xx-master). I saw there is a hnscripts folder within master too. After changing to master and calling the build script from there everything worked like a charm!
Thank you again for your great work!
ar71xx-master-r11827-f8424b1b26-20191228
The recent ubus version upgrade two days ago caused a bug for system log, which bug has now been fixed. However, the change also caused some services not to start, e.g. collectd (= LuCI statistics) and nlbwmon. ldir figured out that those fail where the procd init file has a "nice" parameter definition:
I have implemented that workaround in my own build.
Hopefully the underlying bug (in ubus or procd) gets fixed, but until then the workaround is to have the nice definition before the command definition in the procd init file of a service. (Note that the bug may affect also other packages/services that define "nice", but those two are the main affected ones in my build.)
EDIT:
ath79-master-r11829-e3e939d8e6-20191228
The bug (that was in blobmsg handling in libubox) has been fixed.
One thing I've noticed with your latest ath79 builds: After the first hard reboot the WiFi LEDs seem to be messed up on my WNDR3700v2/WNDR3800. When deactivating the 5G network the green LED is off and vice versa. Can this be a settings issue?
It is an intermittent symptom. I noticed that already when I authored the wifi support for WNDR3700 in ath79 in August 2018:
https://github.com/openwrt/openwrt/pull/1284
Known issues:
...
phy0 and phy1 may get assigned mixed, so that phy0 may be the 5GHz radio instead of the normal 2.4GHz, and vice versa for phy1. Does not happen always, but may happen.
In build ar71xx-master-r11968-3446702cdb-20200113/WNDR3800 Internet acces does not work because of name resolution not working anymore. Do you have the same problem?
My current WNDR3700 build is in my secondary router, so I haven't really tested full connectivity with DNS.
But I would guess that your troubles are related to recent changes in dnsmasq resolv file location and e.g. a restored config (after the transisition script had already run):
4 days ago Daniel Golle dnsmasq: add uci-defaults script for config migration
6 days ago |Daniel Golle| dnsmasq: switch to /tmp/resolv.conf.d/resolv.conf.auto
6 days ago |Daniel Golle| netifd: move /tmp/resolv.conf.auto to /tmp/resolv.conf.d/
6 days ago |Daniel Golle| base-files: move /tmp/resolv.conf.auto to /tmp/resolv...
That same change may cause me trouble when jumping back to 19.07 from master, but I have not had time to look into possible mitigations (like creating the same dir also in 19.07)
In fact I did keep the settings which worked fine so far. I'll have a look.
owrt1907-r10874-455ba76bf9-20200116
A week ago a change was made in master that changed the default position of resolv.conf.auto file (for DNS).
There is a transition script in master and most users will never see any problem when sysupgrading. (But if you restore an older config to the current master, you might hit trouble.)
The same goes for downgrading from master to 19.07, as the new default is a new directory instead of a plain file. So I added a reverse transition script to my 19.07 build, so that I am still able to seamlessy jump back to 19.07 with my builds.
I don't know what the exact process is when you kepp settings. Are they overridden and restored or do they stay in place?
I could not get dnsmasq running if I keep my settings during update, not even if I create the folder you mentioned. What I was wondering is: why can't dnsmasq create the temp files it uses including it's parent folder? Doesn't have to do this anyway when you restart the router?
If I reset the router to default settings it seems to work, but I am not ready to re-enter the complete configuration again through the webinterface. I even tried to restore the dhcp config file from a default settings backup, but this did not work either.
The transition script does not seem to work in my case. I am currently using the ar71xx-master build.