Device ubnt-erx not supported by this image Supported devices: ubnt,edgerouter-x ubnt-erx ubiquiti,edgerouterx - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
Any clues to point this lost soul in the right direction.
Also not sure if there is a documentation error on the hardware page and how to report that.
There are different issues here, so let's tackle them one by one.
First, in OpenWrt 19.07, the device identifier for your device was ubnt-erx. However, in OpenWrt 21.02 this has changed to the more complete ubnt,edgerouter-x form. This is no big deal.
Second, OpenWrt 21.02 introduced the new DSA switch driver for the ramips/mt7621 devices (which your UBNT-ERX is). You may want to check these links before upgrading: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial and https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa. This means that the switch that drives the 5 physical Ethernet ports will be handled differently, and there is no automatic way to migrate it (hence the sysupgrade error message you are getting Config cannot be migrated from swconfig to DSA).
Before doing anything else, do a backup of your router's settings (via: LuCi => System => Backup).
Now you basically have two (well, maybe three) options:
flashing the OpenWrt 21.02 image without keeping the previous settings with sysupgrade -n -F (-n to not keep settings, -F to skip the DSA error message), and configuring the router from again scratch
flashing the OpenWrt 21.02 image without keeping the settings with sysupgrade -n -F, and import the previous backup except for the network configuration, which should be configured manually again
(flashing the OpenWrt 21.02 image keeping the previous settings with sysupgrade -F, which may end up with your device having a weird network configuration which you'll have to fix manually)
The first and second options will require some more work, but they're the safe path to follow. If you try the third, you should be at least familiar with the OpenWrt recovery mode so that in the likely event that something goes wrong you can rescue your device.
Thanks for a very clear answer @rogerpueyo - I just needed the clarity and confirmation that I could click past the big red box saying "THIS IS THE WRONG FIRMWARE". I also see that the download links have also been fixed on the hardware page for these devices now.
So all good, now running 21.02. I went with not keeping the existing settings as I could very simply replay the couple of tweaks I have made to my config after reboot.
Just an FYI in case anyone else is running an ER-X.
I followed option #1 yesterday (complete reset and config from scratch) and for the most part it was completely painless. Most of my existing configs were plug and play (I have a pretty straightforward and simple setup though). The only hiccup I ran into was that I had to power cycle my cable modem (Comcast), followed by the router, to get the WAN port come back online. I think that's more on the modem side than the router.
Been 24 hours and rock solid stable so far. Thanks to the OpenWRT team for all they've done through the years!
Yeh, I had the same with needing to reboot my ISP's cable modem (Virgin Media) before it would give me a new DHCP offer after booting into 21.02. Although I wasn't paying attention at the detail, I suspect that the MAC address of the WAN interface might change as part of the upgrade which would probably cause it?
As soon as I add Bridge VLAN filtering the Edgerouter becomes unresponsive, have to wait for the changes to revert before I can even ping it - I have tried every imaginable combination of tagged/untagged with/without Primary VLAN ID
For now, the only sane thing to do is to revert back to 19.07.8 and hope the good people at openwrt get their act together regarding this new fangled DSA - because broken VLANs is a dealbreaker for me.
I doubt I'll be upgrading my main router any time soon as this was just a great big PITA
Really? Is that documented like .... anywhere? What if I have multiple VLAN - which is the point of VLANs
Seriously, if that's all I had to do then I'll kick myself - can live without the router having IPv6 (it's not the main router anyway - in fact, it's not even routing at all)
I see this quite differently. For us (freifunk dresden) we use openwrt and a lot of access points are run by people that do not have the skills to "upgrade" the firmware via terminal. They rely on "auto-update" functions or at least a GUI.
Now all routers that still use openwrt 19 can not be updated, because the firmware is not accepted.
This is a big problem, because we can not build-in some code or patches in the software that is already flashed and used in those routers. And we can not reach all the people because freifunk and probably other projects do not collect personal information. The project is open and everyone can join it without our notice.
There should be a migration process from openwrt 19 to openwrt 21. The sysupgrade tool of old firmware (openwrt19) must be able to accept new nameings/device identifier without the need to force-update, which is always dangerous.
Currently I have no good Idea to update all those routers in the field without reaching the people or just by using our GUI (of the old firmware). Also those people do not want to factory-reset their devices and lose the configuration for their setup.
Hope anyone has a good Idea where unskilled people can upgrade to new firmware based on openwrt 21. Or perhaps a migration for ramips devices should be provided.
Then this might be an issue for you in the future, since as far as I understand it, more routers will be migrated to the DSA driver.
You may need to modify the LuCi interface of your images to add an option that allows flashing a firmware file even if it is not accepted, and also add a script that takes care of migrating old ethX.Y nomenclature to the new DSA during the first boot.
this might work only if a firmware already has such a "forced" switch in GUI. But this is not what the normal user should try. Therefore all devices that I know has to have a way to upgrade. this is what our firmware has. but if the new software is not accepted because of changes of image header/identifier, there is no way to update old devices.
Updates should always be possible without any manual handling on some terminals.
A forced flag should never be a "normal" user option. Most user will use it and brick their devices. I also never have seen such a switch on any device on the marked with orignal firmware. There is a reason for it.
I also assume that openwrt is not just used as a basis for only wifi router projects. It might also be used for other projects where devices are somewhere installed where no developer has access to.
image identifier can't be changed at all for devices that are already in field. only for new devices this is possible. I know that for developer it is much cleaner to have everywhere the same scheme for images identifier. but this will break any support and any other projects based on openwrt.
in case of DSA, openwrt must not prevent upgrading, as this is a software issue during upgrading. the new software must parse the old configuration and generate the new expected from it. there is no way round it.
For our project in dresden, I could revert the openwrt patch which prevents upgrading. We do our own migration from old to new, because we have a project specific configuration, from which I can generate the new dsa-configs.
For this I already had direct contact to the patch-developer who will re-think the process and the impact of it
