Updating an application
There are two ways to update an MBL application:
MBL provides a wrapper around the Device Management firmware update service and manifest tool. This means you can use the same file type (
tar, containing the
ipk) for both processes, allowing you to pick the update method independently of your packaging process. It also means that any file that MBL CLI manages to update, the manifest tool should also be able to update, so you can use MBL CLI as a proxy for testing on Device Management.
Using MBL CLI
To install or update an application:
Prepare a tar file containing an OPKG package (
.ipkfile), as explained in the manifest tool section above
Transfer an application update tar file to the
/scratchpartition on the device:
$ mbl-cli put <application update payload> <destination on device under the /scratch partition> [address]
For example, if
payload.taris the payload name for an application update, and 169.254.111.222 is a link-local IPv4 address on the device:
$ mbl-cli -a 169.254.111.222 put payload.tar /scratch
Use the MBL CLI
shellcommand to get shell access on the device:
$ mbl-cli [-a address] shell
$ mbl-cli -a 169.254.111.222 shell
$ mbl-firmware-update-manager -i /path/to/payload.tar --skip-reboot
The application is installed.
The application starts automatically, without a device reboot.
We recommend deleting the old tar files from the
scratch partition after updates finish.
Using the manifest tool
Create an update payload file: Make a
tarfile containing the
.ipkfiles for the applications to update.
Note that the
.ipkfiles must be in the
.tar's root directory, not a subdirectory (we use
-Cin the tar command to specify a directory where the package is).
For example, to create an update payload file at
.ipkfile with the path
user01@dev-machine:~$ tar -cf /tmp/payload.tar -C /home/user01 my_app.ipk
Find the device ID in the
mbl-cloud-clientlog file at
/var/log/mbl-cloud-client.log, using the following command on the device's console:
root@mbed-linux-os-1234:~# grep -i 'device id' /var/log/mbl-cloud-client.log
If you only have one registered device, or if each devices has a been assigned a descriptive name in Portal, you can go to Device Management Portal > Device Directory to find the device ID.
Change the current working directory to the directory where the manifest tool was initialized. You initialized the manifest tool when you created the
Run the following command:
user01@dev-machine:manifests$ manifest-tool update device --device-id <device-id> --payload <payload-file> --api-key <api-key>
<device-id>is the device ID.
<payload-file>is the update payload (
<api-key>is the Pelion API key you generated as a prerequisite.
For a root file system update, the process can take a long time, depending on your file size and network bandwidth.
The system does not reboot after an application update.
Identifying the running applications
You can use
runc list to list all the active applications and their status.
The first steps of an application update include stopping and terminating a running instance of the application (if one exists).
If you perform
runc listwhen the application is stopped, you will see:
root@mbed-linux-os-1234:/home/app# runc list ID PID STATUS BUNDLE CREATED OWNER user-sample-app-package 0 stopped /home/app/user-sample-app-package/0 2018-12-07T08:23:36.742467741Z root
If you perform
runc listwhen the application is terminated, the application will not appear on the list.
When the application is installed or updated, it starts automatically.
If you perform
runc listfor a running application, you will see:
root@mbed-linux-os-1234:/home/app# runc list ID PID STATUS BUNDLE CREATED OWNER user-sample-app-package 3654 running /home/app/user-sample-app-package/0 2018-12-07T08:23:36.742467741Z root
Note: The Hello World application runs for about 20 seconds. When it finishes, it once again appears as stopped.
You can monitor the update payload download progress by tailing the
root@mbed-linux-os-1234:~# tail -f /var/log/mbl-cloud-client.log
You can monitor the update payload installation progress by tailing:
/var/log/arm_update_activate.log: for messages about the overall progress of the installation, and messages specific to
/var/log/mbl-app-update-manager-daemon.log: for messages about application updates.