auc: Invalid argument (22)

[mntn-xyz]

Maintainer: @dangowrt Environment: octeon/generic, Ubiquiti EdgeRouter Lite, 22.03.2

Description:

When run, auc will report the current environment, pause, and then fail with Invalid argument (22). I have tried all reasonable combinations of -b and -B switches, omitting said switches, and so on.

It looks like others are reporting the same issue on the asu repo for different architectures. See https://github.com/openwrt/asu/issues/380 and https://github.com/openwrt/asu/issues/382.

This is with the public OpenWRT sysupgrade server. Attended upgrade works fine through Luci, but I normally leave the web interface disabled.

[brada4]

Try auc -n # -f That will post package list to cloud server and return proposed sysupgrade image link. Then we know if it fails at this step

Then run command without -n - generated image is cached and returned instantly, might be full /tmp etc.

The linked file is normal sysupgrade image with extra installed packages that could be used for upgrade keeping configuration.

[mntn-xyz]

Still getting the same result:

auc/0.3.1-1
Server:    https://sysupgrade.openwrt.org
Running:   22.0.3 r20028-43d71ad93e on octeon/generic (erlite)
Invalid argument (22)

[brada4]

Quick sweeo for EINVAL aka Errno 22: https://github.com/openwrt/packages/blob/openwrt-22.03/utils/auc/src/auc.c Something with board name or package list syntax?

Seems erlite is edgerouter-lite in web forms' understanding? What do you have in /etc/board.json in model::id ? https://firmware-selector.openwrt.org/?version=22.03.3&target=octeon%2Fgeneric&id=ubnt_edgerouter-lite

EDIT: Clicking around - well it was renamed.... https://firmware-selector.openwrt.org/?version=19.07.10&target=octeon%2Fgeneric&id=erlite Could be generational updates with config restore kept old name?

[brada4]

Should be: sed -iBAK s/erlite/edgerouter-lite/1 /etc/board.json

[mntn-xyz]

Could be, will check. I think my initial install was well after 19.07 though.

[brada4]

That wait before err22 is essentially opkg list-installed, then it validates things before posting to the web.

[mntn-xyz]

The board.json file had erlite as the board ID and UBNT_E100 (CN5020p1.1-500-SCP) as the board name. I tried both edgerouter-lite and ubnt_edgerouter-lite for the board ID followed by a reboot, with the same result each time. However auc output still showed erlite. Could it be picking up the "erlite" string from somewhere else?

Running opkg list-installed works normally. 193.9M free in /tmp and no custom packages installed except auc, luci-app-attendedsysupgrade, and attendedsysupgrade-common.

Also I should add that my initial install was in 2022.

Master branch still uses "erlite" for the board name, so if the server is looking for another name then maybe that's the issue: https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/image/Makefile#L81

[brada4]

Lets ping @dangowrt , the finding is that one of local checks in auc client code fails with EINVAL on particular router (? -s). My finding is platform name changed on sysupgrade server. while yours is that it is inconsistent across platform image as installed (?or via restored config?). EDIT: probably web and C versions perform slightly different checks. e.g. web version strictly upgrades to next release while C version triggers on single package update.

[mntn-xyz]

Edit: didn't see your reply before I posted this but yes that sounds like a reasonable area to look. As shown below both auc and luci clients are requesting erlite but only auc is failing. Even though the board name has changed on the sysupgrade server, erlite is still used elsewhere in the source tree.

Just for good measure I ran uic show attendedsysupgrade and everything looks correct.

Digging a little further, auc appears to get the board name via ubus request, which takes the name from either /tmp/sysinfo/board_name or /proc/device-tree/compatible: https://git.openwrt.org/?p=project/procd.git;a=blob;f=system.c;hb=HEAD#l210

/tmp/sysinfo/board_name is set to erlite for this board in preinit: https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/base-files/lib/preinit/01_sysinfo#L9

[brada4]

It could be any of EINVAL-s around code. This had publicly visible duality. You can simulate ubus calls, i did not dig further in other side of strcmp. Really author could be better at quickly digging up inconsistency.

• ubus call system board

[mntn-xyz]

Thanks, ran this and confirmed that ubus call system board returns erlite per the preinit script.

[mntn-xyz]

Is it just me wildly misunderstanding this, or is board_json_file just a string built from concatenated info loaded from other data? See https://github.com/openwrt/packages/blob/openwrt-22.03/utils/auc/src/auc.c#L1290

This would explain why changing the board.json file did nothing -- the data is not actually loaded from board.json, but is rather constructed from data loaded from ubus etc. And ubus would specify erlite.

[brada4]

It may not be "erlite" that mismatches, there are few other checks with same error code 22. It is not something spontaneous, it is from code in that .c file

[mntn-xyz]

Yes I think I was headed in the wrong direction on this, as attempting to request an image build manually via the API using "erlite" as the profile is successful and builds the correct image. It won't be easy for me to do any kind of serious debugging on this device since it is in production. I will see if I can find any likely culprits with a more careful read of the source.

[dangowrt]

I guess we will have to rename the image profile name here https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/image/Makefile#L78

Here is the story line so far: openwrt/openwrt@d07a263ae6c openwrt/openwrt@1e3bfbafd37 openwrt/openwrt@2a07270180e

I fail to understand at this point why the board name is not being unified, ie. why do we need different strings to identify the same device?

@aparcar I guess there was a reason why you only added SUPPORTED_DEVICES alias instead of renaming...?

[brada4]

Taking out that check from CLI would let "cloud" take care?

[mntn-xyz]

Just an update to confirm that this is still a problem, so this doesn't get marked as stale.

I updated to the latest release manually via luci then connected via serial console. Running auc post-upgrade still reports "Invalid argument (22)". (No upgrades are available, but it should report that rather than producing an error, which indicates a failure to complete the upgrade check.)

[edrikk]

Having the same problem with raspberry pi model b+.

auc/0.3.2-1
Server:    https://sysupgrade.openwrt.org
Running:   SNAPSHOT r24002-e3559fb445 on bcm27xx/bcm2708 (raspberrypi,model-b-plus)
Invalid argument (22)

ubus call system board
{
        "kernel": "6.1.54",
        "hostname": "XXXXXXXXXXXXXX",
        "system": "ARMv6-compatible processor rev 7 (v6l)",
        "model": "Raspberry Pi Model B Plus Rev 1.2",
        "board_name": "raspberrypi,model-b-plus",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r24002-e3559fb445",
                "target": "bcm27xx/bcm2708",
                "description": "OpenWrt SNAPSHOT r24002-e3559fb445"
        }
}

[satmandu]

Also seeing the same issue with a Raspberry Pi Compute Module 4:

auc -n # -f
auc/0.3.2-1
Server:    https://sysupgrade.openwrt.org
Running:   SNAPSHOT r24900-aa06f68c52 on bcm27xx/bcm2711 (raspberrypi,4-compute-module)
Invalid argument (22)

ubus call system board
{
        "kernel": "6.1.74",
        "hostname": "office",
        "system": "ARMv8 Processor rev 3",
        "model": "Raspberry Pi Compute Module 4 Rev 1.0",
        "board_name": "raspberrypi,4-compute-module",
        "rootfs_type": "ext4",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r24900-aa06f68c52",
                "target": "bcm27xx/bcm2711",
                "description": "OpenWrt SNAPSHOT r24900-aa06f68c52"
        }
}

[satmandu]

(Attended sysuprade through luci works just fine.)