We are preparing to roll out resinOS 1.x to 2.x updates for resin.io-managed devices. Here’s the previous update regarding the availability of resinOS 2.0, which includes a number of big changes between 1.x and 2.x version of resinOS, including using AUFS for data storage instead of BTRFS and switching the network controller from Connman to NetworkManager. These migrations on live devices can be hairy, so we are doing as much testing as possible.
If you are interested in living on the edge, you can be a beta tester for 1.x->2.x updates!
These are the current preconditions:
you have some Raspberry Pi or BeagleBone devices
you don’t have too much data stored in your /data parition (and nothing that you are afraid to lose)
regular (ie. not exotic) network connections (Ethernet, or Wifi with SSID/Password).
(optional but recommended) have tried your application with another device that is running resinOS 2.x, so you know your application is compatible with the new host OS version
If it sounds good, let us know, and we’d love to have a chance to update your device! We have tested it extensively ourselves, but please note, that there is some chance of losing the device, however small.
At this stage, the updates would be run by our support team, and when we the code has sufficient milage, it will be added to the dashboard as a self-service update option (as is the case for 1.x->1.x updates at the moment, many thanks for the testers of that update!).
@imrehg just updated three devices for me, running two different applications.
First two were running a fairly simple software which reads data via USB-adapter either from RS422 or RS485. It then relays the messages to our server via MQTT.
The first device was connected via ethernet and everything went just as expected. The update didn’t take long and the device was working fine after the update.
The second device proved to be a bit more problematic, as it was connected via wifi. Furthermore the connection credentials weren’t inserted when downloading the OS image through resin.io. If they were, the update should have worked fine and the credentials would have been copied also.
Instead the device used the same method for configuring the wifi as resin-wifi-connect uses. This involves storing the credentials to /data/network.config and copying them to Connman -path during the start of the application.
This lead to the situation that I needed to plug the device in with ethernet and reconfigure the wifi, as the credentials were lost. This was something I was prepared though.
The third device was running a different application, my personal home automation. This was very old (resinOS 1.2.1), and required running the update in two parts. The first was bumping to 1.26 and from there to 2.0.8.
The update once again went fine, and everything including UART and bluetooth are working fine.
All-in-all, after the updates were run, everything is working fine Big thanks to @imrehg for running the updates!
We’re interested in remotely upgrading 7 of our devices from 2.0.0 to 2.2.0, to test a possibly much larger remote upgrade. My colleague Daniel already tried this with one device and we’d like to run it on a slightly bigger test set!
Hi @sheng, thanks, got it! Those devices were actually on resinOS 2.x already and needed updates to the latest 2.x version, so I guess the relevant thread for the conversation is Beta testers: resinOS 2.x updates! Wrote back to you, and thanks a lot for volunteering, really appreciate it!
Running updates on 100+ RPi devices now, so far so good, only comment would be that OS version doesn’t update in realtime in Resin Dashboard so it’s a little tricky to keep track of which ones have been updated
Hi @eblex the dashboard lag should be pretty short, what part does not update for you? Just to see if we’ve overlooked something.
Using the CLI to run the updates is in the works, should be soon! And thanks checking this out! Out of curiosity, what versions are you updating from in general?
Sounds like I’ve run into an issue then, I’m seeing 30mins+ lag
The update runs, Dashboard says successful “close”, I go back to summary and I see the device rebooting, it comes back with old OS version in both devices list and device summary
I see, I think the point there is that if you are running 1.x->2.x updates, the device will necessarily come online with no docker images (including supervisor). Thus when it first starts, it has to download the supervisor, which will report back the new version when it starts to run (and start to redownload the user container). There it can be a lag depending on how long the supervisor download takes. That’s a limitation of the current system. See more details in the “what happens in a resin host OS update” doc: https://docs.resin.io/updates/update-process/
For the 2.x->2.x updates there should not be any lag.
I see you mention 1.6 version, that should be outside of the self-service range, is that really the version you are doing? If so would be happy to run an update for you through our support.
Thank you for the explanation, that makes sense, all devices are on 3G connection so may take some time to download the supervisor, I’ll give them some time.
I indeed have a couple of old devices on 1.6, didn’t get around to update them yet but will ping you when I get to it
Sounds perfect!
For the update, fortunately the supervisor is actually smaller than was before, so the download should be generally faster. And we are working delta updates for both the OS and the supervisor, which will be great for exactly the slow networks like you have. These few updates though will have to happen like the way they happen now, though, but we are always looking at things to improve/speed up/shrink…
