I am running LuCI LEDE 17.0.2 on an Archer C7 v2 and am wanting to move to the current version. What is the appropriate method so I do not end up with a bricked device and can import my current settings/configuration?
With every upgrade, do not keep settings. This will result in a default configuration after each upgrade. This is necessary… keep in mind that you must be connected by Ethernet and the address of the router will be 192.168.1.1
- Upgrade to 18.06 from 17.01
- Then upgrade to 19.07 - this will involve a change from the old ar71xx target to ath79, which will have a scary message. Okay to proceed, just make sure you downloaded the correct image and that the checksum matches with the website.
- now jump to 22.03
- finally 23.05
You cannot import your old settings - they are not compatible. Make a backup and use that as a reference (human readable, not to restore to the system)
3 Likes
Just out of curiosity, but why does one need to update to every intermediate (obsolete) version?
Can't you just flash 23.05 if you're not keeping settings anyway?
If your device supports a TFTP or boot partition emergency flash or similar function, it is totally safe, to use that with the corresponding factory image and make versions jumps as large as you want.
But updating via sysupgrade only gets tested for +1 update jumps. Problem is that flashing means, flashing OpenWRT firmware version x with OpenWRT flash code that was releases 12 months earlier with version x-1 (the age diff being even higher, if you skip beats). No one has tested, what happens, if you flash firmware x with the flash code of lets say version x-5.
So just to be on the safe side, prefer +1 steps for sysupgrade, even if inconvenient.
On top of that, preferably don't just sysupgrade one file after the other in a quick chain of actions (like skipping dialog scenes when playing Witcher 3), but also check the release notes for every single update. This can minimize the risk of bricking certain devices.
As a small number of devices sometimes needs special treatment for certain update steps, like the previous ar to ath platform switch (which was only happening and tested on that particular +1 jump as described. Even other platforms may require onetime setting certain boot variables or flashing factory images one certain time or doing manual exotic command executions for certain version jumps.
So to be really precise, it is not just chaining several +1 sysupgrades, but also keeping an eye on each release note comments for that particular device.
2 Likes
Some devices may require a change to the flash layout or a simple change in the u-boot environment.
This change will probably be documented in the (a+1) Release Notes when upgrading from a to a+1.
But hey might be missing in the (a+2) Release Notes.
So to make sure not to miss a thing take at least a look at every in between Release Notes.
1 Like
As was stated, it is the safest progression. I did recommend skipping one (21.02) since it wasn't really necessary.
The upgrade to 19.07 involves that major ath79 transition, and I think that 17.01 doesn't really understand the firmware image, hence the recommended 18.06 intermediate step -- this one is probably the most critical. From there, the path to 23.05 is less risky, but a jump from 19.07 is not technically supported, so it was most prudent to at least do one more step between.
My guidance was based on this ^^^ (and my experience/knowledge of the platform; I don't want anyone to end up with a brick).
And this would absolutely not have been possible, which is why I recommended resetting to defaults at each step (i.e. not keeping settings). The upgrade to ath79 made this mandatory, but so did the other upgrades because there have been many syntax changes that are critical. Typically, if you upgrade (same architecture/target) to the very next major release, any syntax changes will be 'fixed' in the upgrade process itself... but not across a jump of many major versions.
1 Like
Hello. 1st post.
Thank you for this detailed explanation. I just moved from 19.07 to 23.05 with no issues because of it. On my Archer A7 v5. The process used is the one outlined, upgrade to 22.03 verify it, then upgrade to 23.05. Done. Even saved my settings by simply leaving the checkmark in the box.
This community is so Awesome - just like the software - that I just had to finally create an account and leave this feedback.
Carry on team OpenWrt, you do Fantastic work!
I know this is an old post and I am coming back as I have not yet upgraded anything. I bought a second archer c7 v2 for a backup in case things go awry.
I am going forward with the upgrade.
What image am I wanting to flash.? I see multiple images for ar71xx Generic:
archer-c7-v2-squashfs-factory-us.bin
archer-c7-v2-squashfs-factory.bin
archer-c7-v2-squashfs-sysupgrade.bin
What is currently on the device you're about to flash?
You don't want to flash anything ar71xx unless you're dealing with an existing OpenWrt installation that is pre-19.07.
I'm still on 17.02 going to 18.06.
I assume you mean 17.01?
If that's the case, use the sysupgrade image for 19.07 ar71xx. Then flash the ath79 sysupgrade (19.07) -- this one may give you a scary looking info/warning prompt, but it's safe to force the upgrade if asked.
And then you can upgrade to the latest. You should be able to jump directly from 19.07 > 23.05, but you absolutely must allow the device to reset to defaults (uncheck the 'keep settings...' box or use the -n argument if using the CLI) for that upgrade (this is actually true for all of the upgrades).
Yah, it's 17.01.2. So, yes, 17.01
So the backup devices were running 23.05.2. I went ahead and used the sysupgrade option under System to try and bring one of them to 23.05.5. It sat on the "upgrading, do not unplug device" screen for several hours. I finally hit the refresh button in the browser. I wasn't able to connect to the device. I tried a reboot and still am not able to connect.
- What exact filename was the upgrade file you were using?
- what is the IP address you were using on the browser to reach the device?
- and please send a picture of the information sticker on the bottom/back of your device.
So this is a weird one. As I am using an archer c7, I have several ports to use. I forgot I had configured some of the LAN ports for anti-lock out. So I was able to log into the device with a 192.168.1.0/24 address. The device did indeed upgrade to 23.05.5. When I connect the device to my switch it is supposed to get an IP from my pfsense box, which it does. I can see the DHCP logs in the pfsense confirming it is getting the appropriate IP. But I am not able to connect to it either by Web Interface nor Putty. I am getting a connection refused. I also cannot ping it. When I connect via the LAN port, I can see that it is listening on port 80 and 22.
Without knowing the details of how you were using the device and how it was configured, it is not possible to explain what happened. But, if you were using the device as a bridged AP connected via the wan port, for example, and you turned off the firewall, this could easily be explained by the firewall becoming re-enabled during the upgrade process.
Would you like me to review the config??
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
I was thinking firewall but didnt have enough time earlier to check that. Sure enough, it was enabled. Disabling it put me back into the device. I didnt realize it would be enabled upon upgrading. Something to keep an eye on for the next time.
Thanks for the help
Yes, exactly. But, this points to a set of potentially suboptimal configuration details that may be worth looking at to prevent surprises from cropping up.
Meanwhile...
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.