490

The 502 and 400 errors were due to the migration from webhooks to local data that aparcar installed on the ASU server yesterday, they should be gone now. https://github.com/openwrt/asu/commit/aa7a79023d1bf9139324af68c4509b44ce0aceb8

The intent of all this work was to eliminate the "unknown target/profile" type of errors that were due to the webhooks failing to notify the ASU server when a new build or target was produced.

There may be a few teething issues with the new code, but it's been pretty solid due to the large amount of testing that forum members did against the staging server over the weekend. Thanks to all who contributed!

2 Likes
491

Those errors should be gone now, try again...

EDIT: Oops, I see you reported success a bit later.

492

That was probably due to a package update, which got thwarted by ASU server cache (it returned the old image with the old package rather than building a new one). This should be fixed in owut version 2025.01.29, just pushed the PR to update it an hour ago...

Long Version
When submitting a build request, owut was using a package list that only contained the package names. ASU server creates a hash signature of the build using the package list (and a bunch of other stuff in the request), builds the image, caches it and sends it to you. If some time later you submit another request for the exact same package list (sans versions), you get the cached version as the signature is identical, even if the packages were updated to a new version.

The change in owut is to use the packages_versions in the build request, so now the ASU server computes that signature using the package names and their version numbers, so the signature changes each time a new package version is produced.

Note that as of right now, owut is the only ASU client that is using packages_versions (and only in 2025.01.29 and later), so beware that if you do a build using FS or LuCI app, you might get back something unexpected (i.e., an older package than you thought).

2 Likes
493

Does anyone use the -q/--quiet option to turn down the verbosity on owut? If you don't know what I'm talking about do owut check, then do it again owut check -q... Which do you prefer?

(For those who do know, did you set the option verbosity in the /etc/config/attendedsysupgrade to something other than the default of 2?)

494

I would prefer -q as the default.

1 Like
495

option verbosity 0 or the -q option seems like a more natural default. I think with most utils, if you want a more verbose output you do -vvv..., not the other way around. Of course, there still should be some kind of quiet option, to remove all/reduce most output.

1 Like
496

Thanks, aparcar chimed in on this, too, so I'm going to change the default verbosity to 0...

1 Like
497

So, quick question @efahl - yesterday I tried to use the latest version of owut to upgrade my SNAPSHOT (running a week-old version of SNAPSHOT).

owut check said that an upgrade would fail because of a missing library (libuci######## if I remember correctly). But, I generated a new image directly from the Firmware Selector — adding a few packages to the list to match my install — and it built just fine, so what's the difference and why wasn't owut able to do it?

I had anticipated using owut as a convenience to do quick updates between SNAPSHOT versions while preserving all configs and my chosen add-on packages; is this not what it's for?

Thanks!

498

If you search this thread you'll find several explanations about this; basically it's down to the ABI version used in the package name and the fact that APK can't deal with that properly.

Yet.

If you exclude that package from the owut derived build by using --remove <package name>, the correct one will get pulled in and you'll get a build.

2 Likes
499

What @greem said. Snapshots are fragile right now due to the apk transition. I try to track the current state of the apk issues in the OP of this thread, as apk shortcomings are the direct cause of the failures you're seeing.

The one big difference is that owut knows what's on your device and Firmware Selector can't. owut looks at all of your installed packages (even the dependencies that you don't tell Firmware Selector about) and it does a bunch of up-front analysis to determine if an upgrade is necessary or not, and tries to determine if an upgrade will fail or not (due, say, to transient package build failures).

2 Likes
500

After the last owut update (version 2025.01.29), I always receive the following error when trying to update to the newest snapshot version:

ERROR: Update checks reveal package downgrades, re-run with '--force' to proceed

There are now 16 newer packages installed on my device (including: owut itself, procd, luci-ssl) compared to what owut detects/recognises as the latest versions of these packages. See below:

Package version changes:
  luci-app-firewall             25.031.80892~e845441                       25.028.20397~f882f2e
  luci-app-package-manager      25.031.80892~e845441                       25.028.20397~f882f2e
  luci-base                     25.031.80892~e845441                       25.028.20397~f882f2e
  luci-light                    25.031.80892~e845441                       25.028.20397~f882f2e
  luci-mod-admin-full           25.031.80892~e845441                       25.028.20397~f882f2e
  luci-mod-network              25.031.80892~e845441                       25.028.20397~f882f2e
  luci-mod-status               25.031.80892~e845441                       25.028.20397~f882f2e
  luci-mod-system               25.031.80892~e845441                       25.028.20397~f882f2e
  luci-proto-ipv6               25.031.80892~e845441                       25.028.20397~f882f2e
  luci-proto-ppp                25.031.80892~e845441                       25.028.20397~f882f2e
  luci-ssl                      25.031.80892~e845441                       25.028.20397~f882f2e
  luci-theme-bootstrap          25.031.80892~e845441                       25.028.20397~f882f2e
  owut                          2025.01.29~bced54ad-r1                     2025.01.25~2bf45d50-r1
  procd                         2025.01.30~7fcb5a27-r1                     2024.12.22~42d39376-r1
  procd-seccomp                 2025.01.30~7fcb5a27-r1                     2024.12.22~42d39376-r1
  procd-ujail                   2025.01.30~7fcb5a27-r1                     2024.12.22~42d39376-r1
1 Like
501

I'm seeing this on 24.10-rc7 as well:

Package version changes:
  owut                           2025.01.29~bced54ad-r1                     2025.01.25~2bf45d50-r1
1 packages were downgraded
1 packages are out-of-date
1 Like
502

On rc7 also and owut is not seeing this update, but it shows up in Software > Updates.

1 Like
503

Hi!
Indeed, owut has some issue in rc7 :frowning:


Build succeeded in   0s total =   0s in queue +   0s to build:
  version_number = 24.10.0-rc7
  version_code   = r28417-daef29c75d (requested r28417-daef29c75d)
  kernel_version = 6.6.73
  rootfs_size_mb = default
  init-script    = no-init-script

Image source: https://sysupgrade.openwrt.org/store/9aa726a6ee0bfd1524cfa114efffb9fe2b84251661bcd090077b4ebf1e69c928/openwrt-24.10.0-rc7-dffa3f9ae69b-ipq40xx-generic-glinet_gl-b1300-squashfs-sysupgrade.bin
Image saved : /tmp/firmware.bin
Manifest    : /tmp/firmware-manifest.json
ERROR: Firmware package version mismatch: 'owut', expected 2025.01.25~2bf45d50-r1, but got 2025.01.29~bced54ad-r1
root@GL-B1300:~# owut list

KR

2 Likes
504

So maybe I hit the error you were trying to fix in v2025.01.29, but here's what I saw upgrading a semi-recent 24.10-SNAPSHOT:

root@heathrow:~# owut upgrade -r owut -a owut
owut - OpenWrt Upgrade Tool 2025.01.06~e623a900-r1 (/usr/bin/owut)
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         ipq806x/generic
Profile        meraki_mr52
Package-arch   arm_cortex-a15_neon-vfpv4
Root-FS-type   squashfs
Sys-type       sysupgrade
Version-from   24.10-SNAPSHOT r28383-642b5b6199 (kernel 6.6.73)
Version-to     24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
Build-FS-type  squashfs
Build-at       2025-01-29T21:37:05Z (~94 hours ago)
Image-prefix   openwrt-24.10-snapshot-r28421-1a75172721-ipq806x-generic-meraki_mr52
Image-URL      https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/ipq806x/generic
Image-file     openwrt-24.10-snapshot-r28421-1a75172721-ipq806x-generic-meraki_mr52-squashfs-sysupgrade.bin
Installed      218 packages
Top-level       62 packages
Default         52 packages
User-installed  35 packages (top-level only)

Package version changes:
  dnsmasq                                       2.90-r3                                    2.90-r4
  luci                                          25.023.69389~2e7e104                       25.027.83426~170375e
  luci-app-attendedsysupgrade                   25.023.69389~2e7e104                       25.027.83426~170375e
  luci-app-firewall                             25.023.69389~2e7e104                       25.027.83426~170375e
  luci-app-package-manager                      25.023.69389~2e7e104                       25.027.83426~170375e
  luci-app-statistics                           25.023.69389~2e7e104                       25.027.83426~170375e
  luci-base                                     25.023.69389~2e7e104                       25.027.83426~170375e
  luci-light                                    25.023.69389~2e7e104                       25.027.83426~170375e
  luci-mod-admin-full                           25.023.69389~2e7e104                       25.027.83426~170375e
  luci-mod-dashboard                            25.023.69389~2e7e104                       25.027.83426~170375e
  luci-mod-network                              25.023.69389~2e7e104                       25.027.83426~170375e
  luci-mod-status                               25.023.69389~2e7e104                       25.027.83426~170375e
  luci-mod-system                               25.023.69389~2e7e104                       25.027.83426~170375e
  luci-proto-ipv6                               25.023.69389~2e7e104                       25.027.83426~170375e
  luci-proto-ppp                                25.023.69389~2e7e104                       25.027.83426~170375e
  luci-ssl                                      25.023.69389~2e7e104                       25.027.83426~170375e
  luci-theme-bootstrap                          25.023.69389~2e7e104                       25.027.83426~170375e
  owut                                          not-installed                              2025.01.25~2bf45d50-r1
18 packages are out-of-date

Default package analysis:
  Default                                       Provided-by
  -kmod-ata-ahci                                not installed
  -kmod-ata-ahci-platform                       not installed
  -kmod-phy-qcom-ipq806x-usb                    not installed
  -kmod-usb-dwc3-qcom                           not installed
  -kmod-usb-ledtrig-usbport                     not installed
  -kmod-usb-ohci                                not installed
  -kmod-usb2                                    not installed
  -kmod-usb3                                    not installed
  -uboot-envtools                               not installed
  kmod-ata-ahci                                 not installed
  kmod-ata-ahci-platform                        not installed
  kmod-phy-qcom-ipq806x-usb                     not installed
  kmod-usb-dwc3-qcom                            not installed
  kmod-usb-ledtrig-usbport                      not installed
  kmod-usb-ohci                                 not installed
  kmod-usb2                                     not installed
  kmod-usb3                                     not installed
  nftables                                      nftables-json
  uboot-envtools                                not installed

There are currently package build failures for 24.10-SNAPSHOT arm_cortex-a15_neon-vfpv4:
  Feed: packages
    strongswan                                  Fri Jan 31 11:35:41 2025 - not installed
  Feed: telephony
    freetdm                                     Fri Jan 31 12:45:27 2025 - not installed
Failures don't affect this device, details at
  https://downloads.openwrt.org/releases/faillogs-24.10/arm_cortex-a15_neon-vfpv4/

Request:
  Version 24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
Request hash:
  15fad56c32d4cc1cfccf7b6018fa48b8b43052b1183dc62a9794d3e8abae7d4c
--
Status:   queued - 0 ahead of you
Progress:   0s total =   0s in queue +   0s in build
--
Status:   container_setup
Progress:   7s total =   0s in queue +   7s in build
--
Status:   validate_manifest
Progress:  33s total =   0s in queue +  33s in build
--
Status:   building_image
Progress:  49s total =   0s in queue +  49s in build
--
Status:   done
Progress:  52s total =   0s in queue +  52s in build

Build succeeded in  52s total =   0s in queue +  52s to build:
  version_number = 24.10-SNAPSHOT
  version_code   = r28421-1a75172721 (requested r28421-1a75172721)
  kernel_version = 6.6.73
  rootfs_size_mb = default
  init-script    = no-init-script

Image source: https://sysupgrade.openwrt.org/store/15fad56c32d4cc1cfccf7b6018fa48b8b43052b1183dc62a9794d3e8abae7d4c/openwrt-24.10-snapshot-r28421-1a75172721-84902cd1c575-ipq806x-generic-meraki_mr52-squashfs-sysupgrade.bin
Image saved : /tmp/firmware.bin
Manifest    : /tmp/firmware-manifest.json
ERROR: Firmware package version mismatch: 'owut', expected 2025.01.25~2bf45d50-r1, but got 2025.01.29~bced54ad-r1

I saw this error initially with just owut upgrade, then re-ran the upgrade with -r owut -a owut, and that produced the same error (see above), then finally just used owut upgrade -r owut, and manually installed owut afterwards.

So now I have the latest owut but am still seeing these effects:

root@heathrow:~# owut check
owut - OpenWrt Upgrade Tool 2025.01.29~bced54ad-r1 (/usr/bin/owut)
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         ipq806x/generic
Profile        meraki_mr52
Package-arch   arm_cortex-a15_neon-vfpv4
Root-FS-type   squashfs
Sys-type       sysupgrade
Version-from   24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
Version-to     24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
Build-FS-type  squashfs
Build-at       2025-01-29T21:37:05Z (~95 hours ago)
Image-prefix   openwrt-24.10-snapshot-r28421-1a75172721-ipq806x-generic-meraki_mr52
Image-URL      https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/ipq806x/generic
Image-file     openwrt-24.10-snapshot-r28421-1a75172721-ipq806x-generic-meraki_mr52-squashfs-sysupgrade.bin
Installed      218 packages
Top-level       62 packages
Default         34 packages
User-installed  35 packages (top-level only)

Package version changes:
  owut                                          2025.01.29~bced54ad-r1                     2025.01.25~2bf45d50-r1
1 packages were downgraded
1 packages are out-of-date

NOTE: this doesn't appear to be specific to this platform, had the same issue upgrading my x86_64 primary router and my ipq806x APs. Haven't tried on my other lab systems.

Another bug? Expected?

505

If you make the default verbosity quiet, please log some of the warnings in that mode, however:

root@heathrow:~# owut check -q
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         ipq806x/generic
Profile        meraki_mr52
Package-arch   arm_cortex-a15_neon-vfpv4
Version-from   24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
Version-to     24.10-SNAPSHOT r28421-1a75172721 (kernel 6.6.73)
1 packages were downgraded
1 packages are out-of-date
It is safe to proceed with an upgrade

It would be great to know which packages are out-of-date or downgraded in that verbosity setting, since otherwise I suspect people will just read the last line and potentially end up in a strange/busted situation.

(I'll also add that personally I really like the display of the ASU steps as they run, but I agree that I might be the outlier and -q would be a generally more useful default).

506

One more thing I noticed with my x86_64 update @efahl (and sorry for the spam in this topic just now... been away all week so upgrading all my OpenWRT systems to get closer to rc7):

Default package analysis:
  Default                                       Provided-by
  kmod-drm-i915                                 not installed
  kmod-dwmac-intel                              not installed
  nftables                                      nftables-json

I don't really need the i915 driver (the router is running as a VM in Proxmox), but should there be a way for new-default packages to be added to the builds owut upgrade requests? I can see lots of x86_64 users being annoyed that they don't get the benefit of that module being added to the defaults because it doesn't appear to be added to builds where the package list is already specified?

507

@aparcar

Something is broken on the ASU server, it's returning an outdated package list. If you look at https://downloads.openwrt.org/releases/packages-24.10/x86_64/packages/Packages you see the 1.29 version, but if you grab the same info via ASU, it's old...

$ curl -s https://sysupgrade.openwrt.org/json/v1/releases/24.10-SNAPSHOT/packages/x86_64-index.json | jsonfilter -e '$.owut'
2025.01.25~2bf45d50-r1
2 Likes
508

Thanks for finding this, it's a bug in check, if you attempt to download/upgrade, it says:

$ owut download -q
...
Version-from   24.10-SNAPSHOT r28242-1eff737906 (kernel 6.6.67)
Version-to     24.10-SNAPSHOT r28424-c1d5de0c59 (kernel 6.6.73)
1 packages were downgraded
99 packages are out-of-date
ERROR: Update checks reveal package downgrades, re-run with '--force' to proceed

I'll fix it up so that check also mentions something ...can't upgrade without --force...

1 Like
509

Yow, that's a hard one. We could add it to ASU server's list of package_changes, which looks at the rev number and says "stick it in, if what we're building is newer", but... What if the user has explicitly removed the package? In that case, we don't want to just blindly add it back each time they upgrade.

1 Like