We are using OpenBalena to deploy to Raspberry Pi W-Zeros. There is a very odd behavior that we can not explain.
My colleague in Australia and me in Florida have the exact same setup:
Ubuntu 20.4
and same versions for
Node.js
Balena CLI
Docker
Yet, when I deploy to openBalena a following prebuild on that, will get stuck on the Pi at bootup. When he deploys to openBalena, a following prebuild (on his side or my side!!!) will work fine.
All deploys will report succeeded regardless of whether they work on the Pi or not.
We use the same cloned GitHub repository and use the exact same Balena CLI commands as copied and pasted from our README.
Any hints on why his deploy will work? We are trying since weeks and can’t figure it out.
Hey, it sounds like a hardware or network related issue. When you boot your Pi can you communicate with it via SSH ? If you add your SSH keys to the dashboard then you will be able to SSH to the device locally via balena ssh 192.168.1.23 or ssh -p 22222 root@<device_ip_address>.
If this doesn’t work what is the output from sudo balena scan ?
I just realized I asked you to add SSH keys to a device that is not communicating with the API. In that case can you provision the device with 1 change…use a development OS variant so you can SSH to the device without using keys.
do I understand correctly that you are referring to the "exec: \"./start.sh\": permission denied" error?
That seems like a missing executable permission on the start.sh file, are you referring to it in your Dockerfile? If so, can you check whether you have the permissions set correctly on your system prior to deploy? The deploy will copy the permissions from your local system, the subsequent prebuild will just use them as they are, that would explain why you can prebuild after your colleague deploys.
No, I’m not referring to any error thrown… that’s part of the problem.
Same PC’s (one in Australia one in Florida and one in the cloud). Only the deploy from the Australian one produces a working image. All PC’s can preload successfully IF the Australian one deployed. No other PC can deploy to produce a successful (later) preload.
Hey @imolitor, I think what Michal was asking is that you said:
Actually we are seeing this error message on the devices that don’t work at all.
In that thread, there is a reference to an error "exec: \"./start.sh\": permission denied". If you are seeing that error at run time (not when preloading or deploying) then what might be happening is a permissions issue being copied from the local file system.
That’s why Michal said:
That seems like a missing executable permission on the start.sh file, are you referring to it in your Dockerfile? If so, can you check whether you have the permissions set correctly on your system prior to deploy? The deploy will copy the permissions from your local system, the subsequent prebuild will just use them as they are, that would explain why you can prebuild after your colleague deploys.
The file systems might have a subtle difference of permissions.
If you are NOT getting "exec: \"./start.sh\": permission denied", then maybe could you clarify what you means when you said “Actually we are seeing this error message on the devices that don’t work at all.” ?
Although, I never got the permission denied error, the start.sh was not permissioned to be executed. I changed that, and now a deploy results in a working preload.
Damn Thank for being persistent and pointing that out again, guys!
Thank for being persistent and pointing that out again, guys!