Add Existing (wiped) Device to fleet

I wiped a Balena device and it removed it from the Fleet, but I still see it on my local network.
It’s showing the Balena logo so I assume Balena OS is running.
Can I use the CLI to somehow re-link the Device to my Fleet (of 1)
I don’t have a micro SD at the moment to do the process again.

I think you can use balena scan

And then balena join

Hello, as @shawaj mentioned, balena join can be used to restore a device. However, this only works if you have local (or gateway) access to the device. Also, this would not work on production devices unless you have added an ssh key beforehand, because local ssh is otherwise blocked on production devices. If that is not the case, then this would only work for a development device. Note also that while the info of a device re-registered in this way will remain the same, the id will change (although we encourage using UUIDs instead of ids for referencing devices).

If you decide to try this, we recommend trying on a test device first to confirm that the results and workflow are as expected.

Aside from the above, there is no way to restore deleted devices.

Thanks @myarmolinsky and @shawaj - I think I will have to reboot it from SD.

Hello @myarmolinsky , what do you mean by:

“Also, this would not work on production devices unless you have added an ssh key beforehand, because local ssh is otherwise blocked on production devices unless you have added an ssh key beforehand”,

I had a similar situation where I deleted some devices using the balena API as is shown in the documentation (Resources - Balena Documentation), to be more specific the request was DELETE [https:](https://api.balena-cloud.com/v6/device?$filter=is_online (I did it unintentionally :cry: ). I tried to recover the devices following the steps proposed by @shawaj using ssh keys stored previous to the DELETE event with a local device but the command balena join <localip> --fleet <org/custom_fleet> didn’t work and prompted:

--------------------------------------------------------------------------------
[Warn] Node.js version "14.20.1" does not satisfy requirement ">=12.8.0 <13.0.0"
[Warn] This may cause unexpected behavior.
--------------------------------------------------------------------------------
g_org_name@192.168.50.94: Permission denied (publickey).
SSH: Remote command "os-config --version" exited with non-zero status code "255"

Are the SSH keys correctly configured in balenaCloud? See:
https://www.balena.io/docs/learn/manage/ssh-access/#add-an-ssh-key-to-balenacloud
Are you accidentally using `sudo`?\

We have local ssh access to the service container (and the appliction works) but we can enter through ssh to the HostOs and the device does not appear in any fleet.

So my question is, Is there a method to add this device again to Balena fleet without reflashing it?, even if its identifiers (uuid, device_id, etc) change.

Hello @vech , and welcome to the community!

It looks like the output you sent is for os-config --version, not balena join, did you send the wrong output? I also see that you are using an outdated version of the balenaCLI and a node version that does not satisfy it, could you please try again with a newer version of the CLI (which supports node >=16 <18 now btw!)?

I tried updating balena-cli to its latest version 16.6.0 and nodejs to v18.16.1. And yes The command balena join 192.168.50.94 --fleet g_org_name/custom_fleet prompted the same output, this time without warnings:

g_org_name@192.168.50.94: Permission denied (publickey).
SSH: Remote command "os-config --version" exited with non-zero status code "255"

Are the SSH keys correctly configured in balenaCloud? See:
https://www.balena.io/docs/learn/manage/ssh-access/#add-an-ssh-key-to-balenacloud
Are you accidentally using `sudo`?

It seems like balena join executes the command os-config at some point.

In the previous post I have to correct that we can’t access to hostOS, we only have ssh access to the service container.

Thanks for your help

Hey, I performed a wipe on the device, which successfully removed it from the Fleet. However, I noticed that the device is still visible on my local network, displaying the Balena logo, which indicates that Balena OS is still running. Now, I’m wondering if there’s a way to re-link the device to my Fleet using the Balena CLI without having a micro SD card on hand. As of now, I’m unable to repeat the setup process due to the lack of a micro SD card. Is there a CLI command or alternative method I can use to re-establish the connection between the device and my Fleet? Regards

Hi there @vech ,
Thanks for trying the newer CLI version. Based on the new information that you have provided - that you cannot gain SSH access to the host OS of the device from the machine you are running balena join from - I’ll have to say that there isn’t a way to get it to re join your fleet. The balena join command relies on SSH’ing into the devices Host OS over the local network, and running os-config commands as you have pointed out. Without this SSH access, which is blocked by the device being in production mode, this isn’t possible. The exception would have been if you had specifically configured SSH keys in the devices config.json as detailed here: Configuration - Balena Documentation , and had the corresponding keys on your machine with the CLI. As you can’t access the host OS over SSH, I’m assuming that this isn’t the case. So unfortunately, the only way to recover this device will be to re-flash.

@radykamer Hello,

The answer is “it depends”! Is your device in development mode, or production mode. Can you SSH into the devices host OS from a machine on the same network as the device? If you are in development mode, and you can ssh into the device, you may be able to make it re join your fleet with the balena join command: balena CLI Documentation - Balena Documentation

However this won’t work if your machine with the CLI cannot access the Host OS of the device via SSH

Thanks for your answer @rcooke-warwick, At the end the devices were reflashed. As you mentioned due to the devices were in production mode it was impossible to access to HostOS.