I think i read somewhere that from either 21/22 to 24 wasnt supported, but i suppose that means by "keeping data"
However not really interested in keeping any data, so even with a forced upgrade can i not jump from 21 to 24?
Yes, this is true for essentially all major version upgrades -- keeping settings is only supported for the n-1 --> n OpenWrt version. In some cases, there are breaking changes that prevent keeping settings in that context (such as the transition to DSA), but these are typically 1-time events.
For many devices, this is fine, actually, assuming that the current firmware can properly deal with the new firmware file and assuming that there are no breaking changes such as DSA or partition changes.
Your device should already be on DSA as of 21.02, and I don't see anything about partition changes, so you can go ahead and try the upgrade to 24.10 -- just make sure that you uncheck the keep settings box (or use -n for CLI based upgrades).
1 Like
If you’re willing to “start from scratch”, then yes. I think I’d probably flash a Factory Image first to be extra safe, and then flash a sysupgrade 24.10.5 to the alternate partition.
Do not do this from OpenWrt... this is only for initial installs.
4 Likes
Thank you!
A follow up question, which of these can be restored manually (and are compatible from 21 to 24) by copying the configs exactly how they are:
/etc/config/network
/etc/config/firewall
/etc/config/dhcp
/etc/config/wireless
or would any of these need to be set from scratch? I just am not a fan of setting all the static ip's manually again, etc.. as well as the "traffic rules"
Do not try to restore any of those files directly as they may be incompatible. I would suggest only using them as human-readable references.
You can often copy segments of the files -- for example, if you have a bunch of DHCP reservations or maybe a WireGuard configuration. Most UCI formatted firewall rules should also be safe to copy over, but I would use extreme caution (i.e. avoid it unless it will cause serious hardship).
ok, yes i mean i would copy over only needed segments, making sure that they look the same in the target config files from the previous config files.. not just copy and paste the entire file contents, things like dhcp, etc.. its the most tedious to do one at a time via luci
This has been acceptable practice on these Wrtpac dual partition devices. It is no different than flashing OpenWrt Factory image from the initial OEM on these.
Factory image is still going to boot up into 24.10.5 fully functional. When it’s time to upgrade, you flash a sysupgrade image to the alternate partition which will now boot into the upgraded firmware. It’s just a RR process.
Crickets???
Maybe the naysayers in this thread might find their presumption that using a Factory image on these Wrtpac devices is only for an initial install of OpenWrt altered?
I have been running most of these device models in production since I became a member here. Just as a reminder, several of these particular series of routers have had kernel sizes increased in recent years.
Nothing in my recommendation will do any harm to these devices, and will also update kernel size updates if needed seamlessly even if the user is not even aware.
Ergo, here is the proof of my recommendation that flashing a Factory image to any of these Wrtpac devices will do no harm.
Before Flashing Factory Image
root@WRT1900ACS-AP:/# uptime && date
14:16:53 up 26 days, 10:53, load average: 0.00, 0.00, 0.00
Fri Jan 16 14:16:53 EST 2026
root@WRT1900ACS-AP:~# ubus call luci.advanced_reboot obtain_device_info
{
"current_partition": 1,
"device_name": "Linksys WRT1900ACS",
"partitions": [
{
"state": "Current",
"os": "OpenWrt 23.05.3 (Linux 5.15.150)",
"number": 1
},
{
"state": "Alternative",
"os": "OpenWrt 23.05.3 (Linux 5.15.150)",
"number": 2
}
],
"rom_board_name": "linksys,wrt1900acs"
}
root@WRT1900ACS-AP:/tmp# wget https://downloads.openwrt.org/releases/24.10.5/targets/mvebu/cortexa9/openwrt-24.10.5-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img
Downloading 'https://downloads.openwrt.org/releases/24.10.5/targets/mvebu/cortexa9/openwrt-24.10.5-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img'
Connecting to 151.101.198.132:443
Writing to 'openwrt-24.10.5-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img'
openwrt-24.10.5-mveb 100% |*******************************| 10752k 0:00:00 ETA
Download completed (11010048 bytes)
root@WRT1900ACS-AP:/tmp# sysupgrade -c -F openwrt-24.10.5-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img
FLASHING 24.10.5 Factory Image
BOOTED to 24.10.4 Factory
After Flashing Factory Image
root@WRT1900ACS-AP:~# ubus call system board
{
"kernel": "6.6.119",
"hostname": "WRT1900ACS-AP",
"system": "ARMv7 Processor rev 1 (v7l)",
"model": "Linksys WRT1900ACS",
"board_name": "linksys,wrt1900acs",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.5",
"revision": "r29087-d9c5716d1d",
"target": "mvebu/cortexa9",
"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
"builddate": "1766005702"
}
}
root@WRT1900ACS-AP:~# ubus call luci.advanced_reboot obtain_device_info
{
"current_partition": 2,
"device_name": "Linksys WRT1900ACS",
"partitions": [
{
"state": "Alternative",
"os": "OpenWrt (Linux 5.15.150)",
"number": 1
},
{
"state": "Current",
"os": "OpenWrt 24.10.5 (Linux 6.6.119)",
"number": 2
}
],
"rom_board_name": "linksys,wrt1900acs"
}
im not sure what @psherman has to say about this? Because i dont know what the difference is.
I personally want to be 100% sure the upgrade works , so he mentioned using the sysupgrade image instead.
He mentioned i must make sure i uncheck the keep settings box, but im not sure if i should also check the force upgrade, or if that appears regardless...
First, for most devices, flashing a factory image is not recommended, so this is only in the case of these WRTxxxx (Wrtpac) devices.
I would not advise flashing a Factory Image if you were simply to upgrade from i.e. 23.05 to 24.10. That being said, in this situation of bypassing multiple versions upgrade in one go, I advise my process.
The Factory Image on these devices ensures the partition being flashed has its environment properly prepared to run the new stable image. In the case of devices that can receive a larger kernel it will also ensure that the Factory Image configures the environment to use this increased Kernel size, and prepare the system to carry this to the alternate partition when you flash subsequent Sysupgrade images.
Yes. If if you are running this from LuCI GUI you must Force the flash.
Either method you use can successfully accomplish your task.
For most targets that have a sysupgrade image that is distinct relative to the factory image, you should only use the sysupgrade image once running OpenWrt.
@RuralRoots points out some interesting things about this particular target with respect to the compatibility of the factory image -- this is target hat I don't have direct experience with, so I'm inclined to trust @RuralRoots 's explanation and advice here.