Newly flashed device stuck at CURRENT RELEASE: Factory build

@myarmolinsky Only that nothing else works…

I see. I can’t say with any certainty whether we have expended everything we can try to get the device working, but it’s worth a shot seeing if the SD card is the issue.

Okay, new SD card didn’t help either.

Flashed an old img file I had from another project, and it boot right away and startet downloading the right build.

I then moved it to the correct fleet, and it didn’t update…

I then created an new fleet, an created a new img file, falshed it on the SD-card and it worked.
So somethings wrong with the one fleet…

Odd, I’m not aware of anything on the fleet-level itself that should cause this behavior. I’ll raise this internally to see if anyone is familiar with such an issue. Thank you for consistently testing and coming back with more info :slight_smile:

Meanwhile, I’ve just re-read this thread and realized that earlier you mentioned that this is the only device in this fleet (so there’s no proof that the release is not the issue since there’s no other device successfully pulling and running it). So I’m thinking now that the issue may actually be with the release itself. Is there any information you could share about your release by any chance?

To confirm whether the release is the issue, you can try pushing another release to the fleet (one that you know works on others devices) and seeing if the device pulls it. Then, if the current release is indeed the problem, pinning to it should result in the device being stuck on the downloaded release instead of downloading the pinned release (same behavior as it has right now being stuck on Factory build instead of pulling the release)

That was one of the first things i tried. Not sure if I mentioned that erlier…

Also, the error was

Error response from daemon: No such container: balena_supervisor

So it doesn’t even try to get the image. And also nothing in the log window on the right in the dashboard.

The ones that works, it immediately show the “downloading image” messages.

I have not deleted the non working fleet yet if you need to check something?

Error response from daemon: No such container: balena_supervisor

I do recall that that was the issue earlier (well specifically it said resin_supervisor which was the first odd sign since you should have had the balena_supervisor container). However, can you confirm whether you still see that same error now after the attempts to reflash and provision with a different SD card?

I have not deleted the non working fleet yet if you need to check something?

I appreciate that you have not deleted it yet, and if it’s alright with you it would be good to keep the fleet while we debug. As mentioned though I don’t see how a fleet itself can cause such an issue: signs point to either the release or something else (maybe the image being flashed onto the device?)

I see from the original screenshot that you are using a Raspberry Pi 3 (using 64bit OS) and balenaOS 2.114.18. Could you please confirm that the device type of the device is indeed correct?

I have tried re-deply a new release with no improvments…

Forgive me for asking what I’m sure feels like redundant questions but I want to make sure. In your original message your wrote the above ^, when you say you tried to redeploy, did you push the same release again? Or did you push a different release? Just want to make sure we can eliminate the release as the issue