Veethree D7 SDK
Loading...
Searching...
No Matches
Partitions on the D7 Platform

< Details index

As described in A/B update scheme, the D7 uses an A/B update scheme. To achieve that, the internal storage is partitioned such that applying an unstable software update cannot break a stable image.

The device uses:

  • 2 boot containers
  • 2 kernel boot partitions
  • 2 application partitions
  • 2 root file system partitions
  • 1 persistent data partition
  • 1 staging partition used by software updates

For development purposes, the relevant partitions are just the application and persistent data partitions.

A B
/app /app
/appdata
  • Each /app partition is 512MB.
  • The /appdata partition is 512MB.
  • The /staging partition is 1GB.

The /app partition

This is the partition where software updates will put your applications and service files. An application can create files in /app, but it is not recommended to try to persist data here.

Note: Only root can write to the /app partition. Applications that start via system services are run as root. This, as well as the ownership of /app, is subject to change in future releases.

The files will not be available when the next software update is applied because it will be using the partition from the next step in the A/B update scheme. Also, the current partition will be reformatted the next time a software update writes to the current step in the A/B update scheme.

It should also not be used for temporary files either. The /tmp directory is available and writable by applications and, on the release image, by the non-root user as well.

From this partition, /app/sys/etc is overlaid on top of /etc.

The /appdata partition

This partition is where applications should keep their persistent data. The partition is not formatted by software updates.

Note: Only root can write to the /appdata partition. Applications that start via system services are run as root. This, as well as the ownership of /appdata, is subject to change in future releases.

From this partition, /appdata/sys/etc is overlaid on top of /etc, which is why /etc is writable.

Overlays

The /etc folder is part of a 3 way overlay.

The order of precedence is:

  1. /appdata/sys/etc
  2. /app/sys/etc
  3. /etc

If a file is present in more than one of these locations, the file in the location with higher precedence is the one that will be visible when accessing it via the /etc overlay.

The characteristics of the different partitions are:

  1. /appdata: Files which must be persistent between software updates
  2. /app: Files which will be overwritten by software updates
  3. /etc: Files provided by the SDK in the rootfs. On release images, this is read-only.

File visibility

The three possible scenarios are described in the following tables

  1. File exists in /etc, but not in /app/sys/etc or /appdata/sys/etc
    Exists Is visible
    /etc/file1 ✅ ✅
    /app/sys/etc/file1 ❌ ❌
    /appdata/sys/etc/file1 ❌ ❌
  2. File exists in /etc and /app/sys/etc, but not in /appdata/sys/etc
    Exists Is visible
    /etc/file1 ✅ ❌
    /app/sys/etc/file1 ✅ ✅
    /appdata/sys/etc/file1 ❌ ❌
  3. File exists in /etc, /app/sys/etc and /appdata/sys/etc
    Exists Is visible
    /etc/file1 ✅ ❌
    /app/sys/etc/file1 ✅ ❌
    /appdata/sys/etc/file1 ✅ ✅

For more information about how overlay filesystems work, please refer to the kernel documentation.

The root file system

The root file system is readonly on release images, so any path other than /etc, /app, /appdata and /tmp is readonly.

On development images, the rootfs is writable, but applications must not depend on that, as they will not function on release images.

Remarks
Do not use development images in production.

Checking the active partition

On both the development and the release image there is a utility for checking which partition is currently active.

vt-switch-partition.sh --current

The utility needs root privileges, so on release images it should be run with sudo.

It can also reboot the device into a specific partition.

vt-switch-partition.sh --partition A

This will reboot the board immediately and boot using partition A.

This may be useful during debugging to make sure the board did not automatically change partitions due to a bug in a software update, or to boot into a specific partition to allow debugging a process.