Yes, basically what you should do, going from a non-official build to official:
Install luci-app-attendedsysupgrade, nano, and enable Advanced mode on the Attended Sysupgrade settings page on the web interface.
Manually edit /etc/config/network and rename the interfaces as per @kirdes' comment
This is important, DO NOT restart the network or apply the configuration - just save the changes (best to do the edit with nano)
Use the Attended Sysupgrade page on the web interface to upgrade to the official build. Make sure that luci is selected for installation into the image (i.e. it's on the list when you search for an update - this is why we enabled Advanced mode in step 1). ASU should pick luci up (as well as any other packages you've installed), but I've seen it fail to do so, so just double check the list, and add luci (and anything else you might need, e.g. I added luci-app-pbr for some advanced routing)
Install the upgrade once ASU finished generating it for you.
Wait for the router to reboot
???
Profit Enjoy!
Basically, by not reloading the network service, you're storing the configuration for the next reload of the service - which will happen after the upgrade. You have to make sure you don't accidentally reboot before upgrading, as that would kill pretty much all networking (except for WiFi).
I'm a bit surprised that in my case, while upgrading to the official build I did not edit /etc/config/network and still managed to get the official build up and running
Are you sure everything is working and the network config didn't change? Also are you absolutely sure your first build wasn't after @robimarko renamed the interfaces?
Yes, works really nicely. Note that I built the image myself and could connect to the LAN ports after flashing.
I logged into LUCI and observed that the LAN ports had changed to lan1-lan4, 10g-1 and 10g-2
I took the risk and attempted to restore my existing backup file since I wanted to save the time required to configure, but I ended up in some issues and concluded that the new ports enumeration could have caused the issue. I had to reset the router, logged in and reconfigure afresh to get my setup up and running again.
That's interesting, since there's no migration script present to automagically rename the interfaces. My guess is, your build of the image was after robimarko's changes to the interface naming.
Yes, I initially built and flashed from Robimarko's repo, then noticed that the device has become officially supported after @Kirdes replied to my questions about the correct branch to build from.
I proceeded to build and flashed from OpenWrt master afterwards.
The lan network works just fine, however the other subnets (guest and iot for now, I plan on adding a few more for VPN based routing) simply don't work - not even DHCP requests seem to happen properly, as my APs receive no response. The following is all the DHCP-related requests on my wireless APs:
Sun Jan 29 18:05:24 2023 daemon.notice netifd: iot (4743): udhcpc: started, v1.36.0
Sun Jan 29 18:05:24 2023 daemon.notice netifd: iot (4743): udhcpc: broadcasting discover
Sun Jan 29 18:05:27 2023 daemon.notice netifd: iot (4743): udhcpc: broadcasting discover
Sun Jan 29 18:05:30 2023 daemon.notice netifd: iot (4743): udhcpc: broadcasting discover
The 301w doesn't even show the DHCP requests being received, however.
EDIT: Looks like luci-app-opkg was also removed from the default packaging, but manually installing it will return the Software page (just needed a restart).
The above config is also DSA compliant, on the Belkin RT3200 it was working just fine. Even the first configured VLAN works fine. It's only the other networks defined (the tagged ones) that stopped functioning.
Just to give a little feedback following the upgrade (if it can help some).
I created a backup prior to the upgrade process (I ticked the option box to save current package list in /etc/backup/installed_packages.txt.
I then followed the steps discribed by @fonix232 but faces some issue with the ASU that couldn't not generate a proper config.
From there I decided to download and install the official development snapshot. I had trouble reaching the router via ethernet and wifi alternatively. I eventually connected, yet I couldn't reach the webgui because, as I learned later on, these snapshots don't include Luci (I understand the double check warning you gave me :))
I could still ssh into the router, opkg install luci, to start, diff current package list and backup list to install my previous packages (trimmed the list a bit) and everything seems to be running good.
Hope it helps if someone faces the same "wait, where's web gui ? Did I messed up all ?" interrogation at some point
@robimarko somehow my 301w build got the Dynalink-DL-WRX36 version of /lib/firmware/ath11k/IPQ8074/hw2.0/board-2.bin included in it and ath11k won't start properly.
Hello everybody,
First of all thanks for all the efforts you're collectively putting in this project.
I previously used OpenWRT on other devices and the first install normally goes through the web interface to replace the vendor firmware with the appropriate OpenWRT build.
I was wondering if it will be the case with the QHora-301W because I keep on seeing install guides leveraging serial but I also see in the Downloads section a Factory build which is recommended for the "web interface" install.
So my question is: is it safe to download the Factory build and install it from the QNAP web interface?
Sorry for the very basic question and thanks in advance for your help
The openwrt factory image is generated by default. That doesn't mean you can use that on each and every device.
The QNAP stock firmware is doing a lot of checks during the upgrade (including decryption of the encrypted stock firmware image), those checks doesn't work for the openwrt factory image and the firmware upgrade will fail consequently.