@aric-mira That’s a funny state to be, have to check if it’s something that’s in flux in Staging, that muddies the picture. But this sort of suggests a hint, that the supervisor might not have started properly on this device (the supervisor that checks in with the resinOS version, IP address, etc and starts to download the application image if available).
Indeed there’s only production image, will check with the maintainer about that, why was it released such.
Sorry for throwing out ideas for further tests, here’s an idea:
- download the 2.9.6+rev1 image from staging
- on production, go to Add device, and select “advanced” at the bottom, then check “Download configuration file only”
- burn the staging image on a USB stick as before, but on the
flash-boot partition, replace the
config.json with the file that you downloaded in the previous step (make sure that it overwrites
config.json, not just copy onto that partition)
- provision a device with this flashing media.
Do these steps make sense? This enables you to try a staging image on production, and should be clearer to see what works and what not (staging is unstable by nature).
If the device ends up in a similar state, then phase 2. If you can provision a device that is known to work (e.g. Raspberry Pi, or something), that is on the same network as the testing device, for debugging we can try to connect through the working one to the “might or might not be working” one (discovering it via the hostname). This might do the trick to be able to look into what’s going on the device.
Along these lines we should learn something and move the process forward…