Hello, is there a list of features to expect from Resin OS 2, or a list of major differences to Resin OS 1?
Hi, should have the announcement soon, and the release candidates are already up on the staging site. In the meantime the main things that I know being mentioned quite often:
- switching from btrfs to aufs for more reliable storage behaviour on devices
- switching from ConnMan to NetworkManager for networking for much-much better networking and supporting more types of networks
- Local Mode for faster development cycle
… among other things.
It should be generally faster, more reliable, more fun/useful to develop with.
2 Likes
hey @exposedwiring, here is a slightly longer list:
- File System: switched the underlying filesystem from BTRFS to ext4+AUFS. This configuration is more robust to sudden power failures and disk corruption, making 2.0 much more fault tolerant than its predecessor.
- RO-rootfs: the root file system is now Read-Only further reducing the risk of corruption in the rootFS and ensures safe HostOS upgrades are robust and atomic. From the user container, you won’t notice any difference with this change
- Networking: NetworkManager + ModemManager has replaced connman, this gives resinOS 2.0 first class cellular connectivity in hostOS, no more dangerous setups with containers managing the connectivity. We also get easy setup for wpa2-enterprise connections and the ability easily create multiple wifi connections, etc.
- We now deploy a
-dev
variant of each version of resinOS 2.0, the-dev
variant has a passwordless ssh daemon running on it and has its docker socket exposed over the network. This enables the new local mode development flow, which allows you to avoid the full push, build, download pipeline and builds containers locally on the device. The open SSH connection also aids in debugging certain types of issues while your project is in development. IMPORTANT:-dev
variants should never leave the lab environment as they are intentionally made open and will also not be eligible for hostOS upgrades later, please don’t deploy a fleet of-dev
devices, you’ll have a bad time. - Less likely to hit out-of-space issues and more easily able to get accurate free space measurements. This is again due to the change in the underlying filesystem. In the older BTRFS filesystem, it was difficult to get reliable disk usage statistics because BTRFS creates a lot of meta data to keep track of file changes and this meta data was very difficult to account for, so commands like
df -h
would return inaccurate results. This meta data additionally caused issues when one actually ran out of disk space because it made it almost impossible to delete files, since in BTRFS if you want to delete a file, it needs to create some meta data to do so, but if you don’t have any space for that meta data, then you have a bit of a catch 22. - removed the
/host_run/dbus bind-mount in the supervisor
[breaking change] in favour of a more standardised path, user will now instead need to set:DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
- kmod hack is removed and kernel modules no long compressed, so debian wheezy images will work on all variants of resinOS.
- hostname defaults to
<short-UUID>
, but can be easily customised from{hostname: my_name}
element in/boot/config.json
- Devices now advertise themselves on network via avahi with name
<hostname>.local
- can customise hostname and enable persistent journal logging from
/boot/config.json
- Patches on the way docker syncs to disk and configuration of the linux page cache to reduce page cache thrashing. This fixes some serious issue on the line of Beaglebone boards, making them much much more stable.
- Shortened UUID from 31 bytes a more standard 16 bytes. This can affect user who have external scripts interacting with the UUID and expecting a certain length.
- For the non
-dev
images, 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. - Ability to enable persistent logging. It’s now possible to retain boot logs over a power cycle, this can be enabled by adding
{persistentLogging:true}
in the config.json. 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. - 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/ - Docker pulls will now be from Docker registry V2, which should be more robust and slightly faster as registry V2 is capable of parallel downloading of layers.
- Raspberry Pi specific:
- 4.4 kernel + new/up-to-date dtbs, so many more Pi Hats will work out of the box.
- No longer loads the default audio module on startup, instead it is loaded via the setting in config.txt, which is the standard way of doing things.
- The i2c-dev module is auto load, however will not have any affect unless i2c is enabled in config.txt
- Beaglebone Specific:
- internal_uEnv.txt now becomes resinOS_uEnv.txt
-
eth*
type interfaces will be preferred over wifi. May be able to configure this with the addition of autoconnect-priority in the NetworkManager configuration. - Support for the UPboard and Kitra710
And in terms of migrating code over from 1.x to 2.x, these are the major things to be aware of:
- Deprecation of
/host_run/dbus
path in favour of/host/run/dbus
- Connman connection manager no longer available on host
-
/var/lib/connman
directory no longer exists in the container - 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.lock
and 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.
Documentation covering most of this stuff should be out by the end of the week. We are super excited about 2.0 and tons of work has gone into making it super stable and enjoyable to use. 2.0 will also be the foundation on which all our new and exciting features will land, so keep an eye out for those
3 Likes