Better workflow for uploading firmware and debugging issues

So I discovered these two projects:

They allow a remote firmware update via HTTP and SSH, respectively. I have only tried the HTTP version and it worked very nicely. It’s good to not have to juggle SD cards.

Also @mobileoverlord mentioned this:

tell it which interface to watch and it’ll bring up the net kernel with the app name and ip address of the node
then you can just use remsh from your machine iex --name host@0.0.0.0 --cookie my_cookie --remsh my_app@192.168.1.100
you’ll want to make sure that the node is not started with the net_kernel already running
which means, in your vm.args file, you need to omit specifying name or sname

you should set the cookie in the vm.args file

yeah, name and sname cannot be specified
otherwise net_kernel cannot be stoped and started
so, the init_net_kernel is really a workaround for dynamic IPs
if the vm is started in distribution mode, which happens automatically if the vm was told to start with a name (short or long) you cannot stop distribution from within the vm
which is the only way to really change the full node name including the ip after the @

1 Like

While nerves_firmware_http does work and is easy to set up, we recommend that newcomers give nerves_firmware_ssh a try instead. We’re hoping to phase toward that over time, as it offers encryption and authentication. The main difference with nerves_firmware_ssh is that you need to configure your application to know about which SSH keys to trust before doing the initial SD card burn. Then, it will allow subsequent updates using any of those keys (including updates to update the allowed keys, but obviously be careful about that :wink:).

2 Likes