Too much "stuff" for your current rootfs partition size? Try reading through this section of the wiki page:
I've been watching package builds and we got new versions of libubus and libmbedtls a couple days ago. With all fixes in place, both upgraded transparently on my test machine, so fingers crossed it's all done...
1 Like
Could I build an initramfs-kernel.bin using owut?
I don't think so, the image builders only appear to create the factory and sysupgrade images for the targets I've tested. And none of the ASU clients pay attention to anything but the sysupgrade images, so you'd have to hack something up to get to it, even if the server were to create it.
Here's ASU server build output for Archer C7, which has an initramfs on downloads, but the server artifacts only include the other two:
$ ll
total 7848
drwxr-xr-x 2 efahlgren efahlgren 4096 2025-07-09 20:44 ./
drwxrwxr-x 3 efahlgren efahlgren 4096 2025-07-09 20:43 ../
-rw-r--r-- 1 efahlgren efahlgren 5991 2025-07-09 20:44 openwrt-24.10-snapshot-r28756-32b0c89947-3e3c480d5240-ath79-generic-tplink_archer-c7-v4.bom.cdx.json
-rw-r--r-- 1 efahlgren efahlgren 1532 2025-07-09 20:44 openwrt-24.10-snapshot-r28756-32b0c89947-3e3c480d5240-ath79-generic-tplink_archer-c7-v4.manifest
-rw-r--r-- 1 efahlgren efahlgren 4001798 2025-07-09 20:44 openwrt-24.10-snapshot-r28756-32b0c89947-3e3c480d5240-ath79-generic-tplink_archer-c7-v4-squashfs-factory.bin
-rw-r--r-- 1 efahlgren efahlgren 3998529 2025-07-09 20:44 openwrt-24.10-snapshot-r28756-32b0c89947-3e3c480d5240-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin
-rw-r--r-- 1 efahlgren efahlgren 1688 2025-07-09 20:44 profiles.json
-rw-r--r-- 1 efahlgren efahlgren 763 2025-07-09 20:44 sha256sums
Hello, with 24.10.0-rc2, r28161-ea17e958b9 that came pre-installed on the OpenWrt One router, opkg says 'owut' is an unknown package. Is there a reasonably straightforward way to deploy owut in that install?
Provided you have internet connection on the router:
opkg update && opkg install owut
Or in Luci > System > Software. Click on "Update lists..." and then find owut and install it.
Cheers!
Hi @el_charlie, that's what I tried. The update is successful:
root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/targets/mediatek/filogic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/targets/mediatek/filogic/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/base/Packages.sig
Signature check passed.
but then
root@OpenWrt:~# opkg install owut
Unknown package 'owut'.
Collected errors:
* opkg_install_cmd: Cannot install package owut.
root@OpenWrt:~# cat /etc/banner
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 24.10.0-rc2, r28161-ea17e958b9
-----------------------------------------------------
The /etc/opkg/distfeeds.conf file is incomplete. That happened to some of those early One devices, which were sold with weird hand-built images.
Run this command to add the missing ones (duplicates don't matter), then try the update and install again...
cat >> /etc/opkg/distfeeds.conf <<FEEDS
src/gz openwrt_core https://downloads.openwrt.org/releases/24.10.0-rc2/targets/mediatek/filogic/packages
src/gz openwrt_base https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/base
src/gz openwrt_luci https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/luci
src/gz openwrt_packages https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/packages
src/gz openwrt_routing https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/routing
src/gz openwrt_telephony https://downloads.openwrt.org/releases/24.10.0-rc2/packages/aarch64_cortex-a53/telephony
FEEDS
Thank you, @efahl! That fixed it. The original distfeeds file had only the first two lines from your list.
1 Like
Thanks @efahl,
Sadly my testing clashed with a TP-Link EAP615Wall bug. It looked like owut did what it should have, even if the result was a borked access point.
I'll now have to wait for an update to come down the pipe to test properly.
@efahl. Upgrading my TP-Link EAP235-Wall using owut still breaks ssl. I can't https:// to luci or update my packages with apk.
Looking at the 155 packages that were installed, libustream-* is missing.
When I use the image builder to create my target packages (standard + nano, umdns & owut) . Which was the base that owut upgraded from and the repaired version that I installed after, I get 156. The difference is libustream-mbedtls20201210.
In case it is helpful, owut blob on a similar build (Xiaomi Mi4a Gigabit Edition) produces:
{
"client": "owut/2025.07.11~0d00192d-r1",
"target": "ramips/mt7621",
"profile": "xiaomi_mi-router-4a-gigabit",
"version": "SNAPSHOT",
"version_code": "r30381-b626262226",
"filesystem": "squashfs",
"diff_packages": true,
"packages_versions": {
"apk-mbedtls": "3.0.0_pre20250606-r2",
"base-files": "1665~b626262226",
"ca-bundle": "20241223-r1",
"dnsmasq": "2.91-r2",
"dropbear": "2025.88-r1",
"firewall4": "2025.03.17~b6e51575-r1",
"fstools": "2025.07.05~e8cd820c-r1",
"kernel": "6.12.37~ddd8217746951650479ad573bc9d06ec-r1",
"kmod-crypto-hw-eip93": "6.12.37-r1",
"kmod-gpio-button-hotplug": "6.12.37-r5",
"kmod-leds-gpio": "6.12.37-r1",
"kmod-mt7603": "6.12.37.2025.07.07~32ca2b6d-r1",
"kmod-mt76x2": "6.12.37.2025.07.07~32ca2b6d-r1",
"kmod-nft-offload": "6.12.37-r1",
"libc": "1.2.5-r4",
"logd": "2024.04.26~85f10530-r1",
"luci": "25.195.69847~49b7578",
"mtd": "26",
"nano": "8.5-r1",
"netifd": "2025.05.23~7901e66c-r1",
"odhcp6c": "2025.02.06~8aa8b706-r1",
"odhcpd-ipv6only": "2024.05.08~a2988231-r1",
"owut": "2025.07.11~0d00192d-r1",
"ppp": "2.5.2-r1",
"ppp-mod-pppoe": "2.5.2-r1",
"procd-ujail": "2025.06.19~cde025d5-r1",
"uci": "2025.01.20~16ff0bad-r1",
"uclient-fetch": "2024.10.22~88ae8f20-r1",
"umdns": "2025.05.29~2b28094d-r1",
"urandom-seed": "3",
"urngd": "2023.11.01~44365eb1-r1",
"wpad-basic-mbedtls": "2025.06.27~ea08700a-r1"
}
Hmm, do we need to explicitly include one of luci-ssl (mbedtls version) or luci-ssl-openssl? I see the latter on a couple of my devices that are top-level packages, meaning that I must have added them explicitly (but memory fails me).
Ok, digging around in https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/profiles.json libustream-mbedtls is listed in the default packages (and for a couple of other targets that I looked at). I'm not sure why, as it has no dependencies, so maybe an oversight in the defaults specification.
$ apk info --rdepends libustream-mbed*
$ apk info --rdepends libustream-open*
libustream-openssl20201210-2024.07.28~99bd3d2b-r1 is required by:
luci-ssl-openssl-25.192.00988~4715c6a
I think for SNAPSHOTs you need to explicitly add one of the ssl packages for luci, owut ... --add luci-ssl-openssl, and then it should work (maybe?).
luci also has no dependencies, yet it doesn’t get dropped in an owut (or attendedsysupgrade) upgrade.
Is this errant behaviour specific to ramips/mt7621 devices? It is still a barrier for me in using these upgrade approaches.
If luci is currently installed, it's a top-level package and will be included in the build request. So, did you try removing it (owut upgrade --remove luci) and it stuck around anyhow?
Point is that luci is there & stays there.
Why doesn't libustream-* remain included through the upgrade? It is there, but gets dropped. Unlike luci which is a default part of Snapshot these days & nano which I choose to install.
Of course, if it gets removed then it shouldn't remain. Again, guessing this is a naming issue.
Until you remove it, then it's gone. owut doesn't make the decision here, you do. If it's currently installed, owut will retain it; if it's not installed, owut will leave it out.
Because it's not a top-level package, it's only there if some other package requires it as dependency. If that other package is no longer there, then the packages it depends on are not retained.
No, luci is not a default package in snapshot builds. You must explicitly add it. Look at the profiles.json for your target, you'll see all the defaults listed in the default_packages and device_packages sections (example for x86 https://downloads.openwrt.org/snapshots/targets/x86/64/profiles.json).
1 Like
just fresh built Openwrt 24.10.2 with PoE support for the mx65
OpenWrt 24.10.2, r28739-d9340319c6
installed owut
If I run owut I get the following error:
owut
Runtime error: Unable to dlopen file '/usr/lib/ucode/uloop.so': Error relocating /usr/lib/ucode/uloop.so: uc_vm_exception_object: symbol not found
In /usr/bin/owut, line 10, byte 34:
`let PROG = `${NAME}/${VERSION}`;`
Near here -----------------------^
There's a packaging error in ucode, where a fresh install contains the old ucode from the original 24.10.2 image creation, but the newer ucode-mod-uloop has had its ABI changed...
Just upgrade the ucode and libucode packages to 2025.07.* and it should start working again. I strongly recommend that you do an immediate owut upgrade after the ucode upgrade to make sure that all of the ucode-mod-* are updated to a consistent set.
$ owut check
Runtime error: Unable to dlopen file '/usr/lib/ucode/uloop.so': Error relocating /usr/lib/ucode/uloop.so: ucv_resource_new_ex: symbol not found
In /usr/bin/owut, line 10, byte 33:
`let PROG = `${NAME}/${VERSION}`;`
Near here ----------------------^
$ opkg upgrade ucode libucode
Upgrading ucode on root from 2025.05.11~d5b3a9dc-r1 to 2025.07.18~3f64c808-r1...
Downloading https://downloads.openwrt.org/releases/24.10.2/packages/x86_64/base/ucode_2025.07.18~3f64c808-r1_x86_64.ipk
Upgrading libucode20230711 on root from 2024.07.22~b610860d-r3 to 2025.07.18~3f64c808-r1...
Downloading https://downloads.openwrt.org/releases/24.10.2/packages/x86_64/base/libucode20230711_2025.07.18~3f64c808-r1_x86_64.ipk
Configuring libucode20230711.
Configuring ucode.
$ owut check
owut - OpenWrt Upgrade Tool 2025.07.11~0d00192d-r1 (/usr/bin/owut)
ASU-Server https://sysupgrade.openwrt.org
Upstream https://downloads.openwrt.org
...
I’m on Brume2, all of a sudden I’m getting this error when running owut check. Any ideas why? Thanks
1 Like
Run with --verbose and you'll get a list of the packages changed and missing:
$ owut check -v
...
Package version changes:
base-files 1661~155eea44e7 1661~faf168ffc9
luci 25.206.68186~6da5e65 25.222.74622~4d26a4d
...
What you're seeing is usually caused by a failed package build; the package or a build tool was updated and there's now an error trying to compile the package. You probably just need to wait for someone to notice the breakage and fix it...