As wonderful as Attended Sysupgrade is, apparently it is not good for major version upgrades (for example 22.03 to 23.05...)
I assume that it's as straightforward as downloading the new version and flashing it from the LuCI web interface. But every router has configuration and additional packages that aren't default.
What's the best practice for preserving/re-installing them? In particular:
Many thanks.
Yeah, the cross-release upgrades is my holy grail. I've been encouraging people to use auc to do this,
auc has some features that make it handle packages better across release boundaries than LuCI Attended Sysupgrade. (For example, it uses the "changes" table in the build profile to swap in mbedtls for wolfssl during a 22 -> 23 upgrade.)I've succeeded on three different targets (x86, RT3200 and Archer C7), albeit with a bit of fiddling required on the RT3200.
What platform are you using? Here's what I did on the RT3200, where the mt kmods were refactored and that didn't get added to the profile, so it required a manual addition.
auc -y -b 23.05 -B 23.05.2
... reboots automatically but wifi 5 is dead ...
opkg update
opkg install kmod-mt7915-firmware
reboot
The configs are sufficiently matching between 22.03 and 23.05 that I only had issues on the RT3200 in its wireless config, and others reported that they did the same auc update but didn't experience this problem.
If you want to go the manual route, here's a script that @spence started and I hacked up a bunch. He was asking the same question, "how do I find just those packages that I installed?", which sent us down a deepish rabbit hole infested with opkgs and ASUs and jsons.
$ wget https://raw.githubusercontent.com/efahl/tools/main/src/pkg-scan.sh
$ chmod +x pkg-scan.sh
$ ./pkg-scan.sh --check --version-to 23.05.2 -l
The last line of output from above is the full package list that you can use with https://firmware-selector.openwrt.org/ to create a new image containing all of your self-installed packages. If you leave out the --check, then it will just spit out specifically those self-installed packages, without any of the defaults (this output can be appended to the list you see when you initially pop up the firmware builder).
I'm interested in this topic as well, though my concern is a "configure it and forget it" scenario so I can configure OpenWrt devices for non-techies and they can have updated OWrt for perpetuity with all the security updates.
From that perspective, I think it would be far simpler to parse the default package selection of the new version and append packages that the user additionally installed. Of course this approach will not work in case of more advanced/complicated setups that involves replacing core packages such as different wpads.
These are some of the ideas I threw into the void in a previous topic; flag user-defined packages, fail if there are conflicts; if package not ported/available in new version, fail. The check/fail function would be far more applicable to more complicated setups, since ASU as it currently is is pretty dumb with no context awareness. It just tries to brute-force with whatever package argument that you provide, and only fail if there's no equivalent.
Oh, you're not alone, that's exactly my sentiment and motivation for my diving into this issue. I've been circling around updating my sister's RT3200 22.03 -> 23.05, as it has some foolish hackery that I did on it and she lives 1000 miles away from me. Sure, she's extremely competent (she did devops on Globalstar at Qualcomm during the '90s), but I don't want to put her through the ringer with a simple "Oops!" during an upgrade. I really hesitate to put OpenWrt on other less-techie family members routers for these very issues.
auc already does a good job with the package switching, as mentioned above, as long as that data gets put into the release profile. Likewise, it handles your manual replacements just fine, I have dnsmasq-full on most of my devices, and that's completely transparent.
The big hurdle is changes to config files across stable releases. For example, the swconfig to DSA configs, well, let's say "an issue."
That's a major problem, but I'd say that's out of scope of the auc tool. AFAIU, it's basically a dumb tool, only parses packages on your device and sends them to the Firmware Selector API. The actual update and handling is done by the sysupgrade utility. So for those kind of issues, auc is the wrong angle to tackle it from.