As many of you know, we released resinOS 2.0 as a standalone open source operating system last fall, with new features designed to improve reliability and performance. We kept resinOS 1.x as the recommended version within the resin.io dashboard as we worked to get 2.0 fully production ready.
Now we’re happy to announce that the production version of resinOS 2.0 is available from the resin.io dashboard! You can download either a production or development version of the OS from within your application (more on development versions below, but know that they are designed to provide a great local development experience).
For the initial release, we’re supporting the Raspberry Pi 0, 1, 2, and 3; the BeagleBone Black; the TS4900; the Intel NUC; the ARTIK 520 and 710; and the KITRA 710; and the UP board.
We’re also releasing an update to standalone resinOS and bringing it out of beta – you can download the new images at resinos.io.
More reliable performance
Like its standalone cousin, resinOS 2.0 on resin.io includes a number of features and fixes to improve reliability and performance. All of these improvements mean safer and more seamless application and hostOS updates. You can read more about 2.0 in the docs as well.
Most notably, we’ve switched the underlying filesystem from BTRFS to ext4+AUFS, which is more robust to sudden power failures and reduces the risk of disk corruption. You can also get more accurate space estimates with AUFS by running df from the container; if you do hit out of space issues, purging /data should almost always do the trick.
We made the root filesystem read-only on 2.0 as well, further reducing the risk of corruption in the rootFS, plus ensuring robust and atomic hostOS upgrades. You won’t notice any difference from the user container with this change.
Better networking and connectivity
We’ve also improved the networking stack on 2.0 as NetworkManager + ModemManager replace ConnMan. ConnMan has been a reliable connection manager for the 1.x line, but we’ve seen NetworkManager improve a lot, and it offers first class support for cellular connectivity. This means 2.0 can easily support 3G modems in the host OS, something we know our users have been waiting for. The switch to NetworkManager + ModemManager also means easier setup of wpa2-enterprise connections and multiple wifi connections.
-dev variants and local mode
With the 2.0 release, we’ve introduced dedicated development images to the resin.io platform, which are more open and allow for faster iteration cycles. The -dev variant has a passwordless ssh daemon running and has its docker socket exposed over the network. This feature enables the new local mode development flow, which allows you to build containers locally on the device and avoid the full push, build, and download pipeline when testing your code. The open SSH connection also aids in debugging connectivity issues and gives you insight into the system while your project is in development mode.
IMPORTANT: -dev variants should never leave the lab environment, as they are intentionally made to be open, and will not be eligible for hostOS updates. Please don’t deploy a fleet of -dev devices, you’ll have a bad time.
Other features and fixes
We’ve introduced some features in 2.0 to enable more user customization. The device hostname defaults to <short-UUID>, but can be easily customised from the {“hostname”: “my_name”} element in /resin-boot/config.json. Users can also enable persistent journal logging by adding {“persistentLogging”:true} in the config.json from /resin-boot/config.json and retain boot logs over a power cycle. This will result in the journal being written to disk, so this setting should be used with extreme caution as it can drastically shorten the lifetime of your SD card. Currently it’s recommended only during development and debugging.
Finally, we incorporated a lot of general fixes and made some changes that will affect user behavior, which we’ve listed here:
- Devices now advertise themselves on the local network via Avahi with name
<hostname>.local. - The kmod hack previously added in the supervisor was removed as the kernel modules are no longer compressed, so debian wheezy images will work on all variants of resinOS.
- Shortened UUID from 31 bytes to 16 bytes, which also means a shorter device URL. This can affect users who have external scripts interacting with the UUID and are expecting a certain length.
- Improved boot times by 30 seconds on some device types.
- For non -dev variants , the logs and tty1 are no longer diverted to the HDMI screen, so the splash screen will stay up until the user container takes over.
Some Raspberry Pi specific fixes to note:
- Upgraded to the 4.4 kernel
- No longer loads the default audio module on startup. It is instead loaded via the setting in config.txt, which is the standard way of doing things. This may require changes to your code.
- The i2c-dev module is auto loaded, which won’t have any impact on users unless i2c is enabled in config.txt.
- Bundled all the latest dtbs, which enables more hats and sensors to work on resinOS out the box
- Added support for the Compute Module 1 & 3
And a few BeagleBone specific fixes as well:
internal_uEnv.txtnow becomesresinOS_uEnv.txt; this may require changes to your code- Patches on the way the Docker daemon syncs to disk and configuration of the Linux page cache to reduce page cache thrashing. This fixes some serious issues on the BeagleBone family of boards where the page cache would get trashed so badly that the device would end up corrupted and the whole filesystem would become Read-Only.
And, along with the OS release, we’re releasing the following Supervisor changes:
- New and improved update lock mechanism, which fixes the issue of the supervisor removing the currently held lock because it couldn’t be sure of who owned the lock. The new locking mechanism requires the lock to be written to /tmp/resin/resin-updates.lock and requires some minor changes to code behaviour since the lock does not persist over power loss, so needs to be taken by the user container at startup. For more information check out the docs: https://docs.resin.io/runtime/update-locking/
- Restore default value when clearing a special action config variable
- Allow all config variables to take truthy or falsy values
- Use Docker logs to get all logs from the container, including those before supervisor start
Compatibility and migration between 1.x and 2.0
Some notes on compatibility between 1.x and 2.0 (with more in the docs):
- Breaking Change 2.0 removed the
/host_run/dbus bind-mountin the supervisor, so instead you will need to set:DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket - 2.0 removed the
/var/lib/connmanbind mount, so dbus calls to connman will fail as the service no longer exists - Change in update locks. You should now write the lock at
/tmp/resin/resin-update.lockand this lock should be taken immediately as the container starts if you would like to continually block updates until the override. This is due to the fact that the lock now lives in a tmpfs and is cleared whenever power is lost or a reboot happens, so your application should always explicitly take the lock on startup. - The device uuid has been shortened from 31bytes to 16bytes to be a bit more standards compliant. This can cause some issues with external scripts or regex relying on a set uuid length.
- If you use resin.io base images, you will notice that the hostname has changed from
<device_type>-<short_uuid>to just<short_uuid>, however, if you set a customised hostname in your config.json, that will also be reflected in the container hostname. - If using resin-wifi connect, then need to update to current master because it has support for both 2.0 and 1.x. You will need to use version 5.7.0 or greater of resin cli when working with 2.0 devices.
ResinHUP, our recently released (and still experimental!) feature to perform remote host OS updates, will support updates from 1.x to 2.0 in a couple of months. It’s a difficult and invasive procedure, since resinHUP has to wipe everything and repartition the device, so we want to make sure we create a safe process for remotely updating from 1.x to 2.0. For now, you’ll have to reprovision each device to migrate from 1.x to 2.0.
If you have any questions about moving your fleet from 1.x to 2.0, feel free to reach out in the forums.
Standalone resinOS
We’re also releasing updated versions of the standalone resinOS, which we first released as an open source project back in the fall of 2016. With this release, standalone (or “unmanaged”) resinOS and the resin.io platform (or “managed”) resinOS are more alike than they were before, but still with some key differences, namely that standalone resinOS currently does not contain the resin.io supervisor and does not connect to the resin.io management console. This is a great OS to use if you just want a stable Linux OS to run Docker containers.
If you start your project on standalone resinOS and later want to move onto the resin.io platform, we’re building functionality to promote your device to a development device within the resin.io platform. More on that soon.
We are super excited about resinOS 2.0 coming to the resin.io platform, and tons of work has gone into making it stable and enjoyable to use. 2.0 will also be the foundation on which all of our new and exciting features will land, so keep an eye out in the coming months!
