Looking at the JSON, many devices of that platform do the same, they exclude uboot-envtools. Weird.
1 Like
Uboot-tools should be either on the list or absent. The way it is now "-uboot-tools" will prevent it from being integrated (doesn't matter if its via website/acu/owut).
Maybe there is a good reason for it.
2 Likes
Well. In short, I mostly take care of the firmware selector frontend, while @aparcar works on the backend (Attended Sysupgrade Server).
The backend has a lot of moving parts, so it breaks here and there. Especially when OpenWrt changes and the errors appear first when people trigger a custom build via ASU.
Please be aware that we all do this in our spare time. So time is limited and communication is slow. 
6 Likes
I'm curious whether openwrt firmware selector can support 18.06.9 or not.
The reason is i'm having bunch of ath10k devices with 64megs of ram, dual ath10k@128 and ath9k@4/32 as well. I need fast roaming kvr so wpad-full and imagebuilder are mandatory everytime.
Most of my friends don't know how to use openwrt so i need to integrate custom startup script on-the-fly, regardless of using termux now to patch.
Error in the package or firmware selector.
Does not pull language packs to the SQM package.
Must be installed manually or explicitly specified in the list during assembly.
The 64 meg devices should still be able to run the latest version. Heck, My Archer C50 V4 does it. Your only outlier is the 4/32 device, whatever that is.
The ath10k driver that comes with openwrt 19+ is -ct or -smallbuffer, which blocks me from accessing full 802.11kvr (as it doesn't work well with wpad full one.
If you try to run ath10k in 64 megs device with 19+, it will crash immediately after turning on wifi or after a device is connected.
HI @Hie, 18.06.9 is not supported, because the firmware-selector needs JSON files generated by the OpenWrt build system. But this generation was implemented in 19.07.4. It could have been backported, but those versions are End of Life.
1 Like
You can trim other packages from your builds, including luci, pppoe, ipv6.
What about using zram? It can have an impact on CPU usage but it's usually minor.
The package was added here: https://github.com/openwrt/openwrt/commit/79bd0172ca5671f7cdf382dc80ec1630da057947#diff-48b23d92ddff325a660d061e2395875d2665dfe48ab737191ad2e42404b3b260R13
But it is also removed from most device configurations of that target. No idea why.
Not sure if this is the best place to log this...
When I build a snapshot (for the Xiaomi AX6S), the sysupgrade.itb and ubi-loader.itb files are shown in the browser, instead of showing the save dialog.
It seems to specify the wrong content-type (and content-disposition is missing too?)
factory.bin: content-type: application/octet-stream
*.itb content-type: text/plain; charset=utf-8
For the past couple days I've been running into an issue while building a custom snapshot image for MR8300 (generic/IPQ40xx). Build is successful, I can see in the log that it pulled the latest snapshot packages of everything as intended and successfully created the image file. However, the download links for the factory/sysupgrade images always point to the same older cached build, not the one that was just created.
I tried owut as well but it behaves similarly. It builds the new one, tells me that it built the new one with the latest snapshot version but ignores it and silently sends and flashes the older cached one.
Now, the "old" version is only a few days old but still, I'm pretty sure that's not the intended behaviour.
2 Likes
Have you added a unique comment (e.g. # followed by a random number) in the Script to run on first boot field, before requesting the custom build? It bypasses the cache. See an example below:
My bad, it appears it's an issue with my device where it silently fails to update and is stuck at the version currently running on it. I believed it was reflashing the wrong build all the time because it always reboots to the same version after upgrade. Plus I mistakenly thought the 12 char in the image name (openwrt-<12char>-xxxx-xxxx-xxxx-xxxx-xxxx.bin) is some kind of fairly unique identifier like a check sum or commit number. Turns out multiple builds and snapshot versions can share that same 12 char.
Long story short, it's not an issue with sysupgrade server, sorry about that.
(and to @aparcar too)
firmware-selector seems to be jammed up again; I suspect it's the ASU backend, because owut gives '299 ahead of you' while f-s sits quietly immediately upon pressing "build".
I'd like to offer some of my time to try to help with these - feel free to PM.
G
9 Likes
I left my PC running and waited for my turn in the builder queue, foolishly hoping my patience would be rewarded with an image. Instead, I can now contribute an error message:
JSON Response and Python Traceback
# JSON Response (packages abbreviated)
{"detail":"init","request":{"distro":"openwrt","version":"23.05.5","version_code":"r24106-10cc5fcd00","target":"x86/64","packages":[…],"profile":"generic","packages_versions":{},"defaults":"","client":"ofs/v4.0.6-46-g759cece5","rootfs_size_mb":null,"diff_packages":true,"repositories":{},"repository_keys":[]},"status":500,"error":"<see below>","enqueued_at":"2024-10-05T15:50:01.774836","request_hash":"b0e87915f1d20832d4ef80c7ccb375c4"}
# Error message
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/rq/worker.py", line 1430, in perform_job
rv = job.perform()
^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1280, in perform
self._result = self._execute()
^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1317, in _execute
result = self.func(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/asu/build.py", line 54, in build
log.debug(f"Podman version: {podman.version()}")
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/podman/client.py", line 204, in version
return self.system.version(**kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/podman/domain/system.py", line 87, in version
response = self.client.get("/version")
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/podman/api/client.py", line 257, in get
return self._request(
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/podman/api/client.py", line 425, in _request
self.request(
File "/usr/local/lib/python3.12/site-packages/requests/sessions.py", line 589, in request
resp = self.send(prep, **send_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/requests/sessions.py", line 703, in send
r = adapter.send(request, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/requests/adapters.py", line 667, in send
resp = conn.urlopen(
^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/urllib3/connectionpool.py", line 789, in urlopen
response = self._make_request(
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/urllib3/connectionpool.py", line 536, in _make_request
response = conn.getresponse()
^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/urllib3/connection.py", line 507, in getresponse
httplib_response = super().getresponse()
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/http/client.py", line 1428, in getresponse
response.begin()
File "/usr/local/lib/python3.12/http/client.py", line 331, in begin
version, status, reason = self._read_status()
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/http/client.py", line 292, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/socket.py", line 720, in readinto
return self._sock.recv_into(b)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/timeouts.py", line 63, in handle_death_penalty
raise self._exception('Task exceeded maximum timeout value ({0} seconds)'.format(self._timeout))
rq.timeouts.JobTimeoutException: Task exceeded maximum timeout value (600 seconds)
ASU and/or the Firmware Selector are usually broken every weekend. It's normal 
1 Like
@aparcar Apologies for extra spam. Is there a (relatively) easy way that others than run their own ASU server so there isn't a single point of failure? I've not seen anyone report success in doing so.
I've got a server running locally, and have done installs on my local devices using it (and also use it heavily for testing owut, plus vice versa, using owut to test changes to the ASU server before submitting PRs).
Follow the journey at https://github.com/openwrt/asu/issues/1002 as that's where I'm going to start documenting what I've done with changes to code, yml, README and so on. Once we get it solid there, I'll send in the PRs that make it (hopefully) work out of the box for you, too.
1 Like