Hi this Firmware Selector is so cool! It really bridges a gap for those of use who don't have the wherewithal to get a dev environment set up locally for occasional use.
Couple simple questions about "Customize installed packages". I couldn't find any documentation about it if I missed it than please point me there. I tried to look through the mega post.
Do I need to find all the dependencies for the wanted packages, or will that get solved for me?
Is there anything to know about upgrading or backups?
I generally find upgrading openwrt a daunting task and don't quite understand it so unfortunately my router is probably the most out of date device I own.. not ideal! I have also just seen this innovation: Attended Sysupgrade If it works as described it would be a major benefit to my confidence. Are these 2 tools compatible with each other? Can I use both? I hope so! But I'd rather do whatever smooths the upgrade process.
If I make a backup from one of these custom images, then I later need to restore from backup, do I need to start with identical custom image or is a same version generic just as good?
If you back up the packages, does it know about the custom ones added to the firmware, or will those be considered "default" and therefore committed from the package list?
What about using the normal LUCI /cgi-bin/luci/admin/system/package-manager
Are the parameters saved anywhere in the image file? So if later I want to make a similar image for a different device, I can copy/paste them? Or should I keep notes.
Is there any reason to prefer manually installing a package after install compared to including in the firmware? I always want nano installed (basic here). OK to use the custom firmware, or some reason not to?
Is it possible (or even a good idea) to put in configs that will be required such as ssh key authorization? Maybe that would introduce too much confusion to the foundational OS.
Basically these 2 new tools look so amazing and I'm nervous they are too good to be true!
In addition to those questions, not trying to hijack the thread or anything, but is it also possible to enforce the use of a downloaded firmware as in my case it seems that OpenWrt chooses to use the firmware on the card instead of the one in /lib/firmware
No, the ASU server uses the standard package manager (opkg for 24.10 and earlier, apk in main snapshots) to do the installation of packages prior to building the image, so it performs all the dependency resolution as if you had installed them on-device.
Of course, the more you know the more comfortable you'll be doing the upgrades.
The ASU system (server and clients) do not by default do any backups for you, that's a separate task. (Investigate sysupgrade's --create-backup option for more.)
Here's a quick overview of how the ASU system is all wired up:
The standard OpenWrt build system produces imagebuilders (which you can use manually in a Linux box), that are used indirectly by the ASU server to do custom "builds" (where a "build" doesn't actually compile anything, it simply creates a new image and turns it into a .bin, .img.gz, .itb or whatever is correct for a given platform).
The ASU server (https://sysupgrade.openwrt.org) provides an API to the various clients. The API allows these clients to request version-, target- and platform-specific information about what is currently available. More importantly for our discussion here, the API allows the clients to request creation of an image for a specific version, target/subtarget with a user-supplied collection of packages included.
The ASU clients are the LuCI Attended Sysupgrade app, the online Firmware Selector (https://firmware-selector.openwrt.org/), and two command line clients auc (for 23.05 and earlier) and owut (for 24.10, main snapshot and later).
Each client has various features and strengths, it's up to you to choose which one is most suitable for your needs:
Firmware Selector is web based, so no client interaction is possible/required until you have the image it creates and you're ready to install. This leaves you responsible for knowing version, target, platform, package lists and so on. (Support thread The OpenWrt Firmware Selector)
LuCI Attended Sysupgrade app is on-device, so knows all about your hardware and installed packages, making it very easy to just press "go" and sit back. Very simple interface and usually works just fine, with simple and limited options for screwing things up, but also limited in options if you want to be a Power User™. Until recently, LuCI ASU was not particularly good at doing major version upgrades (say 23.05 -> 24.10), but it's still a bit limited there (and you need a very recent version of it to do the upgrade safely, best to use Firmware Selector for these major upgrades).
auc obsoleted by owut, so I'll skip it here (or read about it on the link you already provided below).
owut is also on-device, so knows all about your hardware and installation, so like LuCI ASU, does auto-selection of image contents without any need for user input. Adds a bunch of options above what LuCI ASU does, so may be your cup of tea if you are one of those power users or wish to utilize some of the more esoteric features that the ASU server offers. (https://openwrt.org/docs/guide-user/installation/sysupgrade.owut, support thread Owut: OpenWrt Upgrade Tool)
All of the above ASU clients rely on the sysupgrade system to store the current configuration, install the new image and restore the configuration. The FS requires that you manually get the desired firmware image on your device, the others do all that for you. (https://openwrt.org/docs/guide-user/installation/sysupgrade.cli)
All of the tools are compatible and do the same job, albeit a bit differently.
That depends on the versions involved. A backup will always work when the from- and to-version are the same, but crossing major version boundaries may or may not work (for example, if your device changed from the swconfig to DSA over that version bump).
If the new install to which you're applying the backup is missing certain packages, that might cause issues, but usually the restore process just installs unused files in /etc/ or /etc/config/ and doesn't say anything about it.
If those custom packages came from the OpenWrt feeds, then it should "just work". Issues will arise if you have external feeds from which you've installed 3rd party packages, the ASU server doesn't know anything about those and will fail to build an image. (This will happen if you try to use ASU on an "almost OpenWrt" device, where the vendor has installed their own cloned OpenWrt but also added their own proprietary packages.)
That's sort of orthogonal to ASU, and being independent of it, should not cause any issues (see comment about custom feeds, just above, though). Just install whatever you like and ASU will pick it up when you do the next upgrade.
Parameters as in config settings? That should all be in the sysupgrade config backup, so no need (other than usual backup caveats) to keep that info elsewhere.
For device swap, you almost always need to start from scratch. Using Firmware Selector to create an image with all your desired packages, then cherry picking settings from the old router's config backup to configure the new device is the most appropriate way here. (This is especially the case for wireless settings, ssh keys and other very-device-specific data.)
On the contrary, it's almost always better to create an image with the "extra" packages built into it, rather than install them after a base image is flashed. When you use ASU to build a squashfs image containing all desired packages, these packages are in the compressed, immutable flash partition, where they take up much less "disk" space than when they are post-installed into the read/write, uncompressed flash file system.
If you are near the limit already, and find you can't install some package, it is sometimes the case that you can build and install a custom image using ASU containing those packages because of this compression effect.
Both FS and owut allow you to specify "first boot scripts" to do one-time device configuration, via the uci-defaults mechanism, but see the warning here before you do.
But, note that once you've got the device configured, all of this data stays on-device during an ASU upgrade and it is not sent up to the server (it's saved in a magic partition on the router during sysupgrade).
