Closed klutchell closed 3 days ago
Testbot RaspberryPi0 2W 64 OS.zip Balena RaspberryPi Logs (4).zip
Attached host OS logs and job run logs for RPi Zero 2 W failing to get SV v2/local/target-state
Order of events from here:
v2/local/target-state
so we can patch it in the next step ❌ Testbot Raspberry Pi OS.zip Balena RaspberryPi logs (5).zip
Attached host OS logs and job logs for Raspberry Pi Zero. https://github.com/balena-os/balena-raspberrypi/actions/runs/10739294088/job/29786753019?pr=1158
Order of events from here.
Balena RaspberryPi logs (6).zip Testbot RaspberryPi4 OS.zip
Attached host OS logs and job logs for Raspberry Pi 4. https://github.com/balena-os/balena-raspberrypi/actions/runs/10739294112/job/29786299406?pr=1158
Order of events from here.
Waiting for supervisor to be reachable before local push ✅ Pushing container to DUT... ✅ Starting builds... ✅ Setting device state... ✅ Get containerId endpoint ❌
During our OS and HUP test suites, the DUT is in unmanaged and in development mode. However, making local requests to the Supervisor via the supervisor API often fails with ECONNRESET.
This happens much more often on underpowered devices like Raspberry Pi Zero, Raspberry Pi Zero 2 W, and similar. We almost never encounter the issue on emulated devices, or those with faster processors.
Known endpoints to encounter this issue:
_Originally posted by @klutchell in https://github.com/balena-os/meta-balena/pull/3420#discussion_r1742505915_
Zulip topic discussing this issue is here.
In the above thread we found that the presence of
apiEndpoint
in config.json causes the Supervisor to treat the device as managed, and will enter a crash loop. On faster devices this crash loop is difficult to notice without inspecting the logs, but on slower devices we often see the connection terminated when making local requests.If the SV treats the device as managed and we hit a local endpoint, we should get unauthorized. However, when enabling local mode the unauthorized changes to ECONNRESET.