4.3. Versioning Images

4.3.1. Introduction

This topic explains the scheme Rigado uses to add version to Vesta software builds such as the Developer Image. It is recommended you follow a similar version scheme for versioning Gateway images and the DeviceOps Distributions that deploy them.

Version information is helpful for some very important reasons:

  • Support Teams know what is installed when a customer has an issue.
  • DeviceOps has a consistent version number scheme for software modules and distributions.

4.3.2. Determining when to increment a version

Since the Gateway requires a collection of many different components, versioning is fairly complex. Each component can itself be versioned and most can be incremented or changed without affecting the others. For example, changing the DeviceOps update tools to use a different URL or tenant ID will likely not require changes in the kernel or any of the applications in the root filesystem. However, at the highest level, distributing this as an update requires the assignment of a new version number. Rigado recommends updating the entire rootfs together so the whole new system can be run through tests as it will be deployed in production. Since everything is distributed together, this collection of different components is called a Distribution and shares a common vesion number.

In general, if you need DeviceOps to push a new version, you should increment the version number of your image.

4.3.3. Example scenarios

I started with RigOS 17.05.0 which had version 0.1.0 of the Node example. When I updated that Node example to version 0.2.0, do I need to udate the RigOS version?

  • Yes, if you intend to distribute that version. Since DeviceOps is keeping track of the “Distribution” that each Vesta is assigned.

I need to update the U-Boot on my deployed gateways. Is that part of the distribution?

  • No, U-Boot is maintained seperately from the kerel, DTB and root filesystem that are loaded onto the Gateway. U-Boot has its own version. You typically don’t need to update U-Boot in production. If there is a reason to do so, there is a special procedure for that update.

4.3.4. The RigOS scheme

The RigOS scheme uses a YY.MM version naming scheme to reflect releases of the Rigado OS. There is also a BUILD_ID that can be used to keep track of what was installed on the hardware originally. This would stay the same as the VERSION_ID in most cases, because the entire rootfs is replaced during an update. If an update was attempted that only updated a few files, the VERSION_ID would increase, but BUILD_ID would not.

Use /etc/os-release for holding version information. This information is mostly determined by the release schedule and is the highest level of the versions:


  • NAME=”<Operating System name, without version, see /etc/os-release>”
  • PRETTY_NAME=”<Marketing name with version , see /etc/os-release>”
  • ID=”<distribution identifier, lowercase, see /etc/os-release>”
  • VERSION=”<Version, possibly with code name, see /etc/os-release>”
  • VERSION_ID=”<alpha numeric version, see /etc/os-release>”
  • VARIANT=”If there are different variations of the OS for their purpose or hardware configuration, see /etc/os-release>”
  • VARIANT_ID=”<lowercase id of variant, see /etc/os-release>”
  • BUILD_ID=”alpha numeric version of original build, see /etc/os-release>”
  • RIGOS_REPO_URL=”<the url of the repository that can be used to re-create this build”
  • RIGOS_REPO_COMMIT=”<commit hash>”
  • RIGOS_BUILD_SYSTEM_VERSION=”<informatin about the build system>”
  • HOME_URL=”<marketing website, see /etc/os-release>”
  • SUPPORT_URL=”<support website, see /etc/os-release>>”
  • BUG_REPORT_URL=”issue reporting website, see /etc/os-release>”

Here is an example for the Developer RigOS:

root@081020317-00001:~# cat /etc/os-release
PRETTY_NAME="Rig OS Developer 17.05.0 Hydrogen"
VERSION="17.05.0, Hydrogen"

4.3.5. See also


A good rule for capturing version information is to have enough information to recreate the same version (where the source lives) and verify that you have created the correct version.

4.3.6. Additional version and revision numbers

There are other versions that are available on the Vesta Gateway:

root@081020317-00001:~# cat /etc/version

root@081020317-00001:~# cat /etc/hwrevision
vesta 2.0

The Kernel also reports its version with the uname utility or by accessing /proc/version

root@081020317-00001:~# uname -a
Linux 081020317-00001.rigadogateway.com 4.1.29+g9cee2a2 #1 SMP PREEMPT Fri Apr 28 11:27:17 PDT 2017 armv7l GNU/Linux
root@081020317-00001:~# uname -m
root@081020317-00001:~# uname -o
root@081020317-00001:~# uname -i
root@081020317-00001:~# uname -p
root@081020317-00001:~# uname -v
#1 SMP PREEMPT Fri Apr 28 11:27:17 PDT 2017
root@081020317-00001:~# uname -r
root@081020317-00001:~# uname -n
root@081020317-00001:~# uname -s

root@081020317-00001:~# cat /proc/version
Linux version 4.1.29+g9cee2a2 (user@buildmachine) (gcc version 6.2.0 (GCC) ) #1 SMP PREEMPT Fri Apr 28 11:27:17 PDT 2017

The DTB has a model that identifies the hwrevision:

root@081020317-00001:~# cat /proc/device-tree/model
Rigado Vesta 300 Board

U-Boot has a version. You can access it:

root@081020317-00001:~# strings u-boot.imx | grep 'U-Boot 2015'
U-Boot 2015.04+vesta+g7b89f9d (Jun 06 2017 - 17:06:34)

Many Rigado provided Tools also have versions:

root@081020317-00001:~# rigtools -V

Side note, Yocto puts info in /etc/issue that looks like:

Poky (Yocto Project Reference Distro) 2.2.1 \n \l

which is shown before the login prompt. So, if you need to change that, OVERRIDE the DISTRO settings from meta-yocto/conf/distro/poky.conf by setting your custom settings in build/conf/local.conf