@el_charlie If you have a minute, could you take a look at https://github.com/efahl/owut/issues/81#issuecomment-4887301474, which is related to this...
1 Like
That's a nice QoL feature, but I fell it could be a bit unnecessary.
I mean, if you manage to add packages to be removed from the build request, it means that you took the time to install them. I don't see a case that you would add packages to that list that you didn't install beforehand.
In my particular case, I installed the theme Argon, I save the apk's to a folder that's backed up and make a check everythime the router boots and if not installed, install it. When I ran owut the first time with Argon installed, of course it threw an error. That's when I new I had to add Argon and Argon Config to the remove list. If by any chance I decide to not use Argon anymore, the next time I'll run owut, the missing Argon and Argon Config errors would tell me to remove those from the owut config.
But using the /optional suffix could be nice in case I forget to remove the packages from the list. I see no other use case.
EDIT: to comply with that OP's issue, why not add a global owut flag, like --ignore-not-installed or something like that? That way if you have packages to be removed, but they're not actually installed, won't throw and error and continue the build process.
I actually think @efahl's /optional suggestion is genuinely useful beyond my specific case too — it's a nice, explicit way to mark packages as "remove if present" without touching the strict error behavior for typos, which could help other users with similar setups (locally-maintained or optional packages, multi-device configs, etc.).
On the global flag idea: it would solve the "forgot to update the list" scenario, but it would also silently swallow real typos on --remove from the CLI — which was Eric's original concern, and part of why the per-package tag was chosen over a blanket flag. My own case is a bit different too: same config file deployed across multiple devices, where a locally-maintained package (qfirehose) is only installed on some of them — not really an "I forgot" situation, more a legitimately variable state by design.
Eric already has a patch for the /optional suffix, and I tested it successfully on my LTE5398-M904 — see the issue linked above.
PS: for context, in case it's not clear, qfirehose is a package I use to update LTE modem firmware/modules on the router.
1 Like
Then the optional suffix should be fine. It's a good compromise.
Cheers!
1 Like
Thanks for the discussion.
Some backstory here: I've been playing with a "minimal, layer-2" configuration for APs and switches for about a year, and it involves removing standard defaults, sometime replacing them with other packages. While doing this, I've run into occasional quirks in the build system, that reinstall things that I don't want.
This optional removal thing looks like it might clean up my experimentation a bit, allowing me to work around the quirks, so I'm inclined to like it.
The idea of another option, like --ignore-not-installed, did cross my mind, but that's more code and more points of contact than the simple "look for a suffix" thing that I prototyped.
Just for completeness, here's a short example of how I set up an AP.
owut download \
--remove "luci luci-light luci-ssl dnsmasq odhcpd-ipv6only"
--add "luci-layer2 px5g-mbedtls"
4 Likes
No rush on my end, happy to wait patiently for this to land in a proper PR/merge whenever you have the time. 
I tried the owut --rootfs-size option - set to 512MB for an x64 host and whilst the image was built successfully, my config was wiped during upgrade. Noticed that this appears to be a common side-effect on x64 - any updates? 100MB is looking quite small these days with many small ARM devices shipping with at least 256MB.
And does fixing the rootfs size in uci set attendedsysupgrade.owut.rootfs_size remove the chance of config loss occurring for future upgrades?
Yeah, business as usual, nothing has changed yet.
https://openwrt.org/docs/guide-user/installation/sysupgrade.owut#expanding_root_file_system
There are some PRs in the works to increase the size and related issues (but still nothing on why the configs are wiped).
https://github.com/openwrt/openwrt/pull/19388
https://github.com/openwrt/openwrt/pull/23806
Yes, that's the observation in all cases so far, the wipe down only occurs when the image size changes.
1 Like
On my Gemtek w1700k running SNAPSHOT, I am getting these error messages:
From root@w1700k:~# owut upgrade -r rtl8261n-lp-firmware -a rtl826x-firmware :
Error: Impossible package selection: rtl826x-firmware not in manifest
RuntimeError: Impossible package selection: rtl826x-firmware not in manifest
From owut check :
rtl8261n-lp-firmware 20240729 missing to-version
1 packages missing in target version, cannot upgrade
91 packages are out-of-date
Default package analysis:
Default Provided-by
nftables nftables-json
rtl826x-firmware not installed
wpad-basic-mbedtls user ignored
It looks like the rtl8261n-lp-firmware package was dropped and the rtl826x-firmware package was recently added: https://github.com/openwrt/openwrt/commit/4abe97b2bc2eaac4c523124f11139fee2cb7dd23
I do see rtl826x-firmware in the package indexes and listed as a default package for that device, but I think the imagebuilder or maybe the profiles.json for airoha/an7581 is out-of-date, so it's using the old defaults.
I was able to get an image built using the lp (low power) version of the firmware, like this:
$ owut download -r rtl826x-firmware --add rtl826x-lp-firmware
...
Package version changes:
rtl826x-lp-firmware not-installed 20240729
...
Default package analysis:
Default Provided-by
rtl826x-firmware not installed
Aha, while mulling this over, I decided this was something to do with package, and sure enough:
$ apk query ... 'rtl826x*firmware'
# 2 items
- package: rtl826x-lp-firmware-20240729
version: 20240729
provides: # 2 items
- rtl826x-firmware=20240729
- rtl826x-lp-firmware-any
- package: rtl826x-firmware-20221115
version: 20221115
provides: # 1 items
- rtl826x-firmware-any
When the imagebuilder says apk add ... rtl826x-firmware, it sees that the lp version is a provider for that and that it has a newer version, so it installs the new one instead of the named one (this is just normal apk behavior with what it considers a virtual package). As soon as the non-lp package is rebuilt and its version matches the lp one, that will be selected.
OpenWrt has a handful of these pseudo-virtual (maybe semi-virtual is a better description?) packages that cause issues like this, and I don't know of a good way to fix this situation without a bunch of packaging changes.
EDIT
Thank you.
I think I will create an image with either image builder or the firmware-selector to include rtl826x-firmware rather than rtl826x-lp-firmware as the former is included by default.
I seem to recall something similar happening a while back, but do not remember the details.
For future reference, how do I track down the cause of a particular change like this?
That won't help due to the root cause of the issue:
buildbot@dbc5e2811c23:~$ make image PROFILE=gemtek_w1700k-ubi PACKAGES=rtl826x-firmware
...
(115/121) Installing rtl826x-lp-firmware (20240729)
...
See details in the github issue I posted above.
(Also, anything you see like this in LuCI ASU or owut will also be present in Firmware Selector, they are all just front ends to the same ASU server, which in turn is just a fancy front end to the imagebuilders.)
1 Like
It's different for every bug, you just need to follow the clues back to the root cause. In this particular case, I first ran some builds using imagebuilder and noted the symptoms. I then looked at the apk query output for the packages in question, found the date/versions that didn't seem right, then chased back to changes in the Makefile for those packages.
2 Likes
Thank you.
I am obviously not understanding the issue correctly.
I will try to make sense of this.
Here's the short* once-over:
- Per the package definitions and
apkthere are two packages that providertl826x-firmware:rtl826x-firmwareandrtl826x-lp-firmware - When you say
apk add rtl826x-firmware,apklooks up all providers and finds both of these packages. - In order to decide which provider to install,
apklooks at the versions. apksees thatrtl826x-lp-firmwarehas a higher/newer version, so it is selected as the preferred provider.
$ apk add rtl826x-firmware
(1/1) Installing rtl826x-lp-firmware (20240729)
OK: 70.8 MiB in 285 packages
This is just how apk works, newer == better, so if one of any set of providers has a higher version, nothing else matters, that's the one that gets installed.
Unless... you qualify the package version when you add it with a pinned version, which constrains the version (and then apk applies some other checks, but in this case they don't matter, e.g., there's no "priority" or anything like that to change its mind).
$ apk add rtl826x-firmware=20221115
(1/1) Installing rtl826x-firmware (20221115)
OK: 70.8 MiB in 285 packages
And since you can't stuff that =20221115 into imagebuilder (see the mayhem it causes, below), apk will consequently always install the -lp- version until we get the version numbers fixed.
$ make image \
PROFILE=gemtek_w1700k-ubi \
PACKAGES="rtl826x-firmware=20221115"
...
Packages: rtl826x-firmware=20221115 airoha-en7581-mt7996-npu-firmware ...
...
Installing packages...
ERROR: unable to select packages:
libgcc1-14.4.0-r5:
breaks: world[libgcc1=20221115]
satisfies: libc-1.2.6-r5[libgcc1]
airoha-en7581-mt7996-npu-firmware-20260622-r1:
breaks: world[airoha-en7581-mt7996-npu-firmware=20221115]
airoha-en7581-npu-firmware-20260622-r1:
breaks: world[airoha-en7581-npu-firmware=20221115]
uclient-fetch-2026.06.07~daad21fa-r1:
breaks: world[uclient-fetch=20221115]
... and so on for 100 more lines ...
* - For someone's definition "short" I suppose.
3 Likes
I'm trying to update a Cudy M3000 V1 from 24.10.7 to stable 25.12. The owut check -v -V 25.12 command shows some packages are to be downgraded but the update can be forced as so:
procd 2026.03.14~c59f2d80-r1 2026.03.13~58eb263d-r1 (downgrade)
procd-seccomp 2026.03.14~c59f2d80-r1 2026.03.13~58eb263d-r1 (downgrade)
procd-ujail 2026.03.14~c59f2d80-r1 2026.03.13~58eb263d-r1 (downgrade)
WARNING: Checks reveal package downgrades, upgrade still possible with '--force'
Does it look safe for me to force the update?
Yes, the procd* changes got backported to 25.12 the day before they went to 24.10, hence the "reverse" versions. It is safe to --force these.
Thanks, I've successfully upgraded to 25.12.5 now using --force.
1 Like