Hey,
We have been working with the Intel Upboard image flashing Intel Compute sticks. We have had no issues when using the ethernet and wifi network connection setting for our image, however when we use ethernet only we aren’t able to reliably image our devices.
We use a usb to ethernet adapter to give it the ethernet connection. During the flashing steps, are all usb devices unmounted? What are the potential causes for the flashing process to lock up?
Thanks for the help!
Hello,
I’m not sure I fully understand the issue here. May I ask for more details please?
You are trying to flash an Upboard, correct? So you want to provision an Upboard device to your resin dashboard. Are you following the steps described here? https://docs.resin.io/up-board/nodejs/getting-started/#add-your-first-device
What do you mean by flashing process lock up?
Thanks for the response Ilias!
We are currently using the Upboard image to flash an Intel Compute Stick STK1A32SC. Since the device has no built in ethernet peripheral, we are using an off the shelf USB to ethernet adapter to provide internet to the device while flash it.
Once the device is flashed initially and rebooted, we noticed that it gets stuck on the boot splash screen indefinitely.
Hi @efisher92, regarding your original question, no USB devices should be umounted in the flashing process, nor would the flashing require internet connection to finish fine. What does it mean that “reliably image” your devices?
What is the boot flash screen you are stuck on? Is it the resin logo on the screen? Or something else? Because by default that splash stays there, unless your application uses the graphics output. Does the device show up in the dashboard? If it shows up in the dashboard and is online, have you deployed any application on it yet?
In general would recommend the Intel NUC image, probably (with the upcoming release, should be in the next few days), as that aims to be a “generic x86” image (some improvements are incoming too).
As a sidenote , you can chance the splash screen on the flashing image (replace the flash-boot/slash/resin.png with your own too.
@imrehg Sorry for the lack of clarity. I believe I mixed up the flashing part and the first boot. The flash successfully occurs. On the first boot it seems to be stuck on the resin logo screen. I don’t see the device appear in the dashboard.
We have deployed a graphical application and when using our WiFi SSID everything works fine, but we would like to get this working via ethernet only if possible.
So, just to summarize, everything works fine when your device is connected via WiFI. It appears online on the dashboard and your application runs fine, correct?
On the other hand, if you connect your device via ethernet, it does not even become online in dashboard, correct?
Have you tried the NUC image as Greg suggested above?
@efisher92, that is very strange, that over Wifi it works, but not over ethernet. Two things:
Hopefully one of these will give us some new information 
Hey @imrehg,
As per your suggestion we are trying the NUC v2.9.6+rev1 dev image with ethernet only. It shows up in the dashboard as online, but seems to get stuck at Starting Show Plymouth Booth Screen.... In the dashboard it doesn’t show that it is downloading the latest commit in the project. It just seems stuck on Factory build.
We are going to test imaging with WiFi and ethernet to see if it gets past this point.
Thanks!
I’m also seeing the following error FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
@imrehg after testing both wifi/ethernet, and ethernet only, both NUC images seem to get stuck at the Starting Plymouth Boot Screen. Both have the device show up in the dashboard, but there is no indication that they are downloading the docker image we have pushed up to the project.
@imrehg I tried flashing a Compute Stick with the NUC image v2.9.6+rev1, and got the same results as @efisher92 (device stuck, but visible in dashboard).
I also tried flashing with the NUC image v2.2. With ethernet only, it gets stuck showing the Resin screen and doesn’t show up in the dashboard. With wifi, it shows up in the dashboard but gets stuck showing status “Flashing resin.io on internal media” at around 40%. This is different from v2.9.6, where the dashboard just shows “Online”.
I tried with a dev image, and the log is stopped on “Starting Resin NTP configuration service…” when it is stuck on “Flashing resin.io…”
@imrehg - @efisher92 and I were able to test with a Core M3-based Compute Stick and got the NUC image v2.9.6 to work. However we were hoping to use the Atom-based Compute Stick which is what our fleet is using currently (all previous imaging attempts were with an Atom stick).
Is the NUC image expected to work with Atom devices? If not is there a recommended image for Atom?
We have only gotten the upboard based projects to work with the Intel Atom processors.
@imrehg, we noticed the v2.9.6 UpBoard image is up on staging. We were able to go through the flashing process with both ethernet and wifi on the Atom based intel compute stick, but it is not pulling the docker image down from the project.
Out of curiosity, is there an ETA for the release of v2.9.6 version of the UpBoard?
@efisher92 I think the release is likely next week, but will have to confirm. Is your device still on Staging, so we could check what might be going on with that?
The 2.9.6 NUC image should be “generic X86”, so I think it is expected to work with Atom as well, but maybe I’m missing something (can @agherzan or @floion elaborate?)
Some thing that you can test, is that you can flash the .dev version of the image for testing, and then as long as the device connects to the network, you can SSH into the device: ssh -p 22222 root@<IP>, and then could check if there’s anything in the logs, why it is stopping “Starting Show Plymouth Booth Screen…” (or what does it mean). If the network does not come up, that’s trickier of course…
@imrehg Our device on staging is https://dashboard.resinstaging.io/devices/3611826a63cd1857766cef1584dfc507/summary. It’s currently online, but not progressing past “Post Provisioning”. It’s also not showing the IP address. We were going to flash a dev image, but we only had the option to select Production on staging.
@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: 
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)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…
Yup that makes perfect sense, I will give it a shot now and update with the results. Thanks!
@imrehg I was able to copy the config.json from my prod application to the staging 2.9.6 USB stick, and flash the device. It showed up in my prod dashboard, but is also stuck in the same “Post Provisioning” state.
I’m provisioning another device onto the same network now. What’s the best way to discover the stalled device via hostname? Is it still connectable even though it’s a production image?
The devices’ default hostname is the first 7 digits of the UUID, so they should answer to the <7-digits uuid>.local (you need Avahi/Bonjour to be able to discover that from another device, just in case).
The device is connectable as it is normally connectable through support and for the web terminal, just this time through another device. Could you please can enable support access both for the “via” device and the target one, (from the dropdown menu on the device summary page) when they are set up?