Owut: OpenWrt Upgrade Tool

Community Builds, Projects & Packages
102 
owut download
Target         mediatek/filogic
Profile        mercusys_mr90x-v1
Root-FS-type   squashfs
Sys-type       sysupgrade
Package-arch   aarch64_cortex-a53
Version-from   SNAPSHOT r27229-ebe7c5f1a3 (kernel 6.6.47)
Version-to     SNAPSHOT r27229-ebe7c5f1a3 (kernel 6.6.47)
Package version changes:
  libustream-mbedtls           2024.04.19~524a76e5-r1                     2024.07.28~99bd3d2b-r1
1 packages are out-of-date
ERROR: Firmware package version mismatch: 'libustream-mbedtls', expected 2024.07.28~99bd3d2b-r1, but got 2024.04.19~524a76e5-r1

is the above error server side?

103

No, that one is owut doing post-download checks between the metadata from the downloads area (i.e., the "expected" version) and what is in the build manifest returned by the ASU server (the "got" version).

This is an odd one, I haven't seen that that specific case before, I've only ever seen the "got" version being newer than the "expected"... (Which happens when the build servers get ahead of the ASU server.)

In any case, if you don't care about the version of that package and deem the build safe to install, you can do owut download --keep. This will retain the /tmp/firmware* files, and if you want to install it just do the usual owut install after that...

104

But I'm already on that release.

105

@efahl how do I point owut at a different asu server?

106

The server is stored in /etc/config/attendedsysupgrade in the server.url field:

$ cat /etc/config/attendedsysupgrade
config server 'server'
        option url 'https://sysupgrade.openwrt.org'
...

$ uci get attendedsysupgrade.server.url
https://sysupgrade.openwrt.org

$ uci set attendedsysupgrade.server.url='http://my.upgrade.server'

If you get owut working with another server, be sure to let me know. I've tried others, but never got it to work as they always have some different files or file layout than the "official" upgrade server...

107

currently sysupgrade.openwrt seems to be not responding to auc, owut or firmware-selector

1 Like
108

I've got a big partition setup on an x86-64 router (with a custom dual-firmware partition layout) and while the ability to specify a larger root size is nice to have (and imo 1GB is plenty), I think I'd actually prefer to download the rootfs.tar.gz file, and extract it to a fresh locally formatted filesystem that's already the correct size.

Is there any chance that owut could allow downloading the rootfs.tar.gz file instead of the combined image? (Do the image builders even build a rootfs.tar.gz with the customized package selection?)

It would be nice to have an easy way to grab the matching kernel.bin too, although since that doesn't get customized it's easy enough to grab from downloads.openwrt.org if I know which version to get.

109

It appears so:

$ owut download
...
Downloaded https://sysupgrade.openwrt.org/api/v1/build to /tmp/owut-build-response.json
...

$ jsonfilter -i /tmp/owut-build-response.json -e '$.images' | ./json_pp
[
    {
        "filesystem": "ext4",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-ext4-combined-efi.img.gz",
        "sha256": "f798a13c82a036c30662040c9b9e3bb9e3df50874f98377723625188d17419f4",
        "sha256_unsigned": "a1bcc7f640b5e25dedf6ebb0bf8c33f2c96a9566724e32a1470a9c089350c9a9",
        "type": "combined-efi"
    },
    {
        "filesystem": "ext4",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-ext4-combined.img.gz",
        "sha256": "9859ab823a337927115bb57d4620e3c72facf91ba946f2cab57e48feab6da659",
        "sha256_unsigned": "b9f1561c44f8e2506df2467391e260ae6aaf57d9d25a48d591330afdd4d728f7",
        "type": "combined"
    },
    {
        "filesystem": "squashfs",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-squashfs-combined-efi.img.gz",
        "sha256": "aca85ef5ded11fcc838205d1e22431a1d9635d89d506264be67f52db0c6737c7",
        "sha256_unsigned": "b8a4333c15758ab875abb6c2ace8dc3780f49fcc47d882e1a72def5e752789c5",
        "type": "combined-efi"
    },
    {
        "filesystem": "ext4",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-ext4-rootfs.img.gz",
        "sha256": "cdba4a746d7f79558e04305f9c191dbb7040a409cce1ccb0ee148fdb2edb8a3d",
        "sha256_unsigned": "cdba4a746d7f79558e04305f9c191dbb7040a409cce1ccb0ee148fdb2edb8a3d",
        "type": "rootfs"
    },
    {
        "filesystem": "squashfs",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-squashfs-combined.img.gz",
        "sha256": "993aaca6b012e8bdce67a0b7dea7fe38edb4fabab8d46725bd7e32bd1647c31b",
        "sha256_unsigned": "9485ee7df470ddc10267e0861c8f7813b3323fd7a1ccf147f4093a7dbe084881",
        "type": "combined"
    },
    {
        "filesystem": "squashfs",
        "name": "openwrt-a15e9603eaf0-x86-64-generic-squashfs-rootfs.img.gz",
        "sha256": "11c7be7aff3b75e60d3d714d3ed5e292838d089b07ae469f255ef018c1bd5160",
        "sha256_unsigned": "11c7be7aff3b75e60d3d714d3ed5e292838d089b07ae469f255ef018c1bd5160",
        "type": "rootfs"
    }
]

I hacked up the collect_device_info function, about line 1042, to set sutype to 'rootfs' and it "worked" (scare quotes seem appropriate here). Here's where I did the hack:

1042 sutype = 'rootfs';
1043         device = {
1044                 arch:     null,              // "x86_64" or "mipsel_24kc"   or "aarch64_cortex-a53", contained in platform_json
1045                 target:   target,            // "x86/64" or "ath79/generic" or "mediatek/mt7622", from system board
1046                 platform: platform,          // "generic" (for x86) or "tplink,archer-c7-v4" or "linksys,e8450-ubi"
1047                 fstype:   sysb.rootfs_type,  // "ext4" or "squashfs", what is actually present now
1048                 sutype:   sutype,            // Sysupgrade type, combined, combined-efi or sysupgrade or sdcard
1049         };

And here's what it looked like when it "worked". The sysupgrade check failed (of course), but I did get the file back and it has a good checksum.

$ owut download -k -v
...
Image source: https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-ext4-rootfs.img.gz
Downloaded https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-ext4-rootfs.img.gz to /tmp/firmware.bin (26242209B at 66.737 Mbps)
Image saved : /tmp/firmware.bin
Manifest    : /tmp/firmware-manifest.json
Verifying   : /tmp/firmware.bin (26242209 bytes) against /tmp/firmware.sha256sums
  Saved sha256 matches
ERROR: sysupgrade validation failed:
stderr =
Fri Sep 13 13:42:43 PDT 2024 upgrade: Image metadata not present
Fri Sep 13 13:42:43 PDT 2024 upgrade: Invalid image type
Image check failed.

The kernel.bin is also there. Using the two hashes from that final Downloaded... line:

$ wget https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-kernel.bin
--2024-09-13 13:54:52--  https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-kernel.bin
Resolving sysupgrade.openwrt.org... 2a03:b0c0:3:d0::1574:1, 206.81.21.114
Connecting to sysupgrade.openwrt.org|2a03:b0c0:3:d0::1574:1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7140352 (6.8M) [application/octet-stream]
Saving to: 'openwrt-a15e9603eaf0-x86-64-generic-kernel.bin'

openwrt-a15e9603eaf0-x86-64-generic-kernel.bin    100%[=============================================================================================================>]   6.81M  4.54MB/s    in 1.5s

2024-09-13 13:54:55 (4.54 MB/s) - 'openwrt-a15e9603eaf0-x86-64-generic-kernel.bin' saved [7140352/7140352]

The kernel.bin file name is not mentioned anywhere in the response, so not sure how to find it in a generic way other than just guessing...

1 Like
110

This is the "-ext4-rootfs.img.gz", so still an ext4 file system image. I was hoping for the "rootfs.tar.gz", i.e. a tar file rather than a filesystem image.

111

Oops, I got distracted and missed that part, it does look like that's there, too.

$ wget https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-rootfs.tar.gz
Downloading 'https://sysupgrade.openwrt.org/store/1bbd23f55013a1717908334078804d96/openwrt-a15e9603eaf0-x86-64-generic-rootfs.tar.gz'
Connecting to 2a03:b0c0:3:d0::1574:1:443
Writing to 'openwrt-a15e9603eaf0-x86-64-generic-rootfs.tar.gz'
openwrt-a15e9603eaf0 100% |*******************************| 25532k  0:00:00 ETA
Download completed (26145059 bytes)

# Check one of my "extra" packages, see if it's there.
$ tar tvzf openwrt-a15e9603eaf0-x86-64-generic-rootfs.tar.gz | grep ethtool
-rw-r--r-- 0/0       497 2024-09-11 23:59:36 ./usr/lib/opkg/info/ethtool.control
-rw-r--r-- 0/0        18 2024-09-11 23:59:36 ./usr/lib/opkg/info/ethtool.list
-rwxr-xr-x 0/0       117 2024-09-11 23:59:36 ./usr/lib/opkg/info/ethtool.prerm
-rwxr-xr-x 0/0     98635 2024-09-11 23:59:36 ./usr/sbin/ethtool

Before I do anything on owut, can you test the kernel.bin and rootfs.tar out and come up with an "alternate sysupgrade-ish" script?

mount this
umount that
dd/cp kernel.bin /boot/vmlinuz
tar xvf rootfs.tar.gz blah blah
reboot

or whatever.

Keep in mind

  1. The names of these files will come from parsing other file names and guessing a generic form.
  2. We don't have checksums for the files, so impossible to validate.

Which suggests maybe there should really be PR against the imagebuilder/buildbot makefiles to add those files to the images section of the profiles.json (see https://downloads.openwrt.org/snapshots/targets/x86/64/profiles.json), or maybe add a new section.

112

upgraded three wsm20 at the weekend using owut, all configured as dumb APs, only had to owut download on one of them, owut install used the same image for all three.

any idea how long the asu server holds the image for before getting rid of?

113

I think Paul said the cache has a 7-day expiration. Not sure if the timer is reset if you download the same image again...

1 Like