I’ve enabled support access for the working “via” device (05b68cf91a7e40a38ba1677647a1e8e7) and the target device (c79b6d78b2a341890af4bffa6b7a244b). Both are online now, let me know if you have any issues accessing.
Checking it out.
The target device does not seem to answer to pings. Thus if it’s online, the boot does not get as far as setting up networking. So you have rebooted it after provisioning, without the flashing media? If yes, and it only gets this far, that’s some information. Would be strange (and informational in another way) if it could run well enough to flash, but not well enough to boot afterwards.
Now it showed up online, and connected to it. Just checking.
Yes the target device was flashed from USB and shut down automatically as expected. I then rebooted it without the USB stick.
On boot from onboard MMC there’s actually an error message that flashes right before the Resin logo appears, I was able to capture it:
Yeah, that message is not important for this case.
The issue seems to be, that healthdog does not seem to be able to start (the watchdog that runs the health checks for the balena daemon), thus no balena/docker running on the device:
Jan 18 23:05:45 c79b6d7 systemd[1]: Starting Balena Application Container Engine...
Jan 18 23:05:45 c79b6d7 healthdog[722]: /usr/bin/healthdog: error while loading shared libraries: libstd.so: cannot open shared object file: No such file or directory
The libstd.so library is available in the system, but then I guess the wrong architecture for this device? It’s already some useful information.
I’ve just rebooted the device (as part of the testing).
Looks like it does not reboot properly by itself (which is not totally unexpected, given that there seems to be a mismatch in architecture expected by the software and provided by the system). This is already something to go on, and will talk to our devices team about it.
Can you tell us the exact Compute Stick model numbers that you are using (I think you mentioned multiple different ones, some Atom, some not)
The Atom stick we are using is STK1A32SC. We also have some Core m3 sticks which are STK2M364CC.
The Core m3 sticks work correctly with the NUC v2.9.6 image using wifi and ethernet-only, but we could only get the Atom sticks working on Upboard v2.2.0 with wifi.
Also, we just tried imaging an STK1A32SC (Atom) with NUC v2.9.6 again to get it to the stuck state. It’s currently online with UUID ef57ca1ff596cfc8497da19082ad9e58 if you want to try taking a look at that one too (we enabled support access). When flashed with NUC images, the STK1A32SC sticks never automatically reboot, so this one hasn’t been rebooted yet - let me know if you want me to reboot it.
I see, so far it’s something like this summary?
- Core M3 Compute stick
- Works with NUC image
- Works with NUC image
- Atom Compute stick (x5-Z8330)
- UpBoard 2.2.0 image works
- UpBoard 2.9.6 image does not work (healthdog does start up, which blocks everything else)
- NUC 2.9.6 image runs flasher, but the post-provision shutdown does not happen automatically
- UpBoard 2.2.0 image works
Checking it with the devices team. Thanks a lot for the opportunity to debug today! Will keep you posted if there’s some development or further questions.
Yup that looks right, except I would caveat that the Atom stick only works with Upboard 2.2.0 if wifi is used. If flashed with ethernet-only, it never shows up in the dashboard.
This is mainly an inconvenience to us because we’d have to coordinate with our fulfiller to setup a wifi network in order to image our devices, if we use the Upboard 2.2.0 image.
Thanks for your help today! Looking forward to any updates.
Hi guys,
You can check the UP board v2.9.7+rev1 image, which should flash and work OK on your devices.
At this moment this image can be downloaded from Resin staging at https://dashboard.resinstaging.io.
In the future this image will also reach production and can be downloaded from the usual dashboard.
Regards!
Thanks, we’re also in contact with Gergely in support chat about this, but we tried the 2.9.7 Upboard image on our compute stick and it still failed to proceed past showing “Post Provisioning” in the dashboard. The device shut down automatically after first flash, but is now stopped on first boot. The UUID is bc3bec8932aea7d323e9521ab2209742 if you are able to take a look.