Supervisor wont start: No deviceId

Product support balenaOS
1

Hello!

Running into an issue provisioning a new device. Everything was flashed to the device the same as previous except this time the supervisor is not able to start. The error being the supervisor failing to load the config json due to deviceId being an empty string

The system was only booted a single time after flashing it. I have not attempted to reboot it yet in order to work out what went wrong.

May main questions with all of this is:

  • How did it get into this state?
  • What is the expected process of assigning that deviceId in config.json
  • What is the recommended process for fixing such an issue?

Things of note:

  • Img used to flash device was downloaded through the dashboard for the application in question
  • The device shows up in the dashboard as online (VPN only)
  • The Supervisor is unable to start due to an error (Logs below)
    Jul 24 07:25:58 f257f4c 9f8b72ad2a3a[1222]: [info]    Supervisor v11.4.10 starting up...
    Jul 24 07:25:58 f257f4c 9f8b72ad2a3a[1222]: [debug]   Starting event tracker
    Jul 24 07:25:58 f257f4c 9f8b72ad2a3a[1222]: [debug]   Starting logging infrastructure
    Jul 24 07:25:58 f257f4c 9f8b72ad2a3a[1222]: [debug]   Starting api binder
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]: [event]   Event: Supervisor start {}
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]: (node:1) UnhandledPromiseRejectionWarning: ConfigurationValidationError: There was an error validating configuration input for key: deviceId, with value: 
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]:     at Config.checkValueDecode (/usr/src/app/dist/app.js:2:2804102)
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]:     at /usr/src/app/dist/app.js:2:2800137
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]: (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a ca>
    Jul 24 07:25:59 f257f4c 9f8b72ad2a3a[1222]: (node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate>
  • The config file in /mnt/boot/config.json is missing a deviceId value (empty string)
{
  "apiEndpoint": "https://api.balena-cloud.com",
  "appUpdatePollInterval": "600000",
  "applicationId": "1707820",
  "deltaEndpoint": "https://delta.balena-cloud.com",
  "deviceApiKey": "xxxxx",
  "deviceApiKeys": {
    "api.balena-cloud.com": "xxxxx"
  },
  "deviceId": "",  <------ Unedited value
  "deviceType": "genericx86-64-ext",
  "listenPort": "48484",
  "mixpanelToken": "xxxxxxx",
  "registered_at": "1595609590",
  "registryEndpoint": "registry2.balena-cloud.com",
  "userId": "xxxxxx",
  "uuid": "xxxxxxx", <---- Exists and matches dashboard
  "vpnEndpoint": "vpn.balena-cloud.com",
  "vpnPort": "443"
}
  • first line of the journctl output was:
Jul 24 16:55:28 localhost bash[1112]: [INFO] balena-unique-key : Device already has uuid assigned.

I hope someone can help!
Cheers,
Tom

6

Hey there,
I am very sorry to hear this. The deviceId is generated by the supervisor. It should always be generated automatically during the provisioning, looking at the code, it seems to me that the only possible situation in which it can remain empty is during a connection loss.
Unfortunately I can’t find another way currently to reproduce this problem.
To solve it you can try to remove the deviceId entry from the config.json. Editing it from the dashboard terminal with vi /mnt/boot/config.json the change should be detected and the provisioning should start again by recreating the deviceId from scratch.
Let us know if it works and if you can return to a normal state.
Please also let us know if this will happen again.

8

Removing the deviceId from the config and restart worked in fixing the issue.

I’m wondering if it’s possible to handle such a case automatically in future? I’m obviously not aware of the code in question but I would imagine checking for an empty string when your expecting numbers would be a possible to to prevent this occurring in future.

I’ll be sure to keep an eye on if this happens again.
Thanks for the help!

10

Hello, I’m happy to hear that that fixed the issue. I’m opening a github issue for this - hopefully we can avoid such possibilities in a future release. Thank you.