From 63314d9fccdb369c0d24af7631dd83097b087038 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Tue, 20 Aug 2019 16:59:49 +0200 Subject: aktualizr: latest garage-sign with expiration support. Use GARAGE_TARGET_EXPIRES or GARAGE_TARGET_EXPIRE_AFTER (but not both!) to set the garage-sign parameters. Signed-off-by: Patrick Vacek --- README.adoc | 3 +++ classes/image_types_ostree.bbclass | 17 +++++++++++++---- classes/sota.bbclass | 2 ++ recipes-sota/aktualizr/aktualizr_git.bb | 6 +++--- 4 files changed, 21 insertions(+), 7 deletions(-) diff --git a/README.adoc b/README.adoc index dd07425..455b5d9 100644 --- a/README.adoc +++ b/README.adoc @@ -107,6 +107,9 @@ Your images will also need network connectivity to be able to reach an actual OT * `OSTREE_UPDATE_SUMMARY` - Set this to '1' to update summary of OSTree repository on each commit. '0' by default. * `OSTREE_DEPLOY_DEVICETREE` - Set this to '1' to include devicetree(s) to boot * `GARAGE_SIGN_AUTOVERSION` - Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. +* `GARAGE_TARGET_URL` - sets the `--url` parameter of `garage-sign targets add`, which sets a custom URL for the Image repository targets. +* `GARAGE_TARGET_EXPIRES` - sets the `--expires` parameter of `garage-sign targets sign`. Format is a UTC instant such as '2018-01-01T00:01:00Z'. +* `GARAGE_TARGET_EXPIRE_AFTER` - sets the `--expire-after` parameter of `garage-sign targets sign`. Format is in years, months, and days (each optional, but in that order), such as '1Y3M5D'. * `INITRAMFS_IMAGE` - initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such a proxy. * `SOTA_PACKED_CREDENTIALS` - when set, your ostree commit will be pushed to a remote repo as a bitbake step. This should be the path to a zipped credentials file in https://github.com/advancedtelematic/aktualizr/blob/master/docs/credentials.adoc[the format accepted by garage-push]. * `SOTA_DEPLOY_CREDENTIALS` - when set to '1' (default value), deploys credentials to the built image. Override it in `local.conf` to built a generic image that can be provisioned manually after the build. diff --git a/classes/image_types_ostree.bbclass b/classes/image_types_ostree.bbclass index 2e8e8f5..fd67865 100644 --- a/classes/image_types_ostree.bbclass +++ b/classes/image_types_ostree.bbclass @@ -237,10 +237,18 @@ IMAGE_CMD_garagesign () { # Push may fail due to race condition when multiple build machines try to push simultaneously # in which case targets.json should be pulled again and the whole procedure repeated push_success=0 - target_url="" - if [ -n "${GARAGE_TARGET_URL}" ]; then - target_url='--url ${GARAGE_TARGET_URL}' - fi + target_url="" + if [ -n "${GARAGE_TARGET_URL}" ]; then + target_url="--url ${GARAGE_TARGET_URL}" + fi + target_expiry="" + if [ -n "${GARAGE_TARGET_EXPIRES}" ] && [ -n "${GARAGE_TARGET_EXPIRE_AFTER}" ]; then + bbfatal "Both GARAGE_TARGET_EXPIRES and GARAGE_TARGET_EXPIRE_AFTER are set. Only one can be set at a time." + elif [ -n "${GARAGE_TARGET_EXPIRES}" ]; then + target_expiry="--expires ${GARAGE_TARGET_EXPIRES}" + elif [ -n "${GARAGE_TARGET_EXPIRE_AFTER}" ]; then + target_expiry="--expire-after ${GARAGE_TARGET_EXPIRE_AFTER}" + fi for push_retries in $( seq 3 ); do garage-sign targets pull --repo tufrepo \ @@ -262,6 +270,7 @@ IMAGE_CMD_garagesign () { fi garage-sign targets sign --repo tufrepo \ --home-dir ${GARAGE_SIGN_REPO} \ + ${target_expiry} \ --key-name=targets errcode=0 garage-sign targets push --repo tufrepo \ diff --git a/classes/sota.bbclass b/classes/sota.bbclass index 5506428..5620b76 100644 --- a/classes/sota.bbclass +++ b/classes/sota.bbclass @@ -51,6 +51,8 @@ GARAGE_SIGN_KEYNAME ?= "garage-key" GARAGE_TARGET_NAME ?= "${OSTREE_BRANCHNAME}" GARAGE_TARGET_VERSION ?= "" GARAGE_TARGET_URL ?= "" +GARAGE_TARGET_EXPIRES ?= "" +GARAGE_TARGET_EXPIRE_AFTER ?= "" GARAGE_CUSTOMIZE_TARGET ?= "" SOTA_MACHINE ??="none" diff --git a/recipes-sota/aktualizr/aktualizr_git.bb b/recipes-sota/aktualizr/aktualizr_git.bb index 9adfce8..5ee9399 100644 --- a/recipes-sota/aktualizr/aktualizr_git.bb +++ b/recipes-sota/aktualizr/aktualizr_git.bb @@ -15,7 +15,7 @@ RDEPENDS_${PN}-ptest += "bash cmake curl python3-misc python3-modules openssl-bi PV = "1.0+git${SRCPV}" PR = "7" -GARAGE_SIGN_PV = "0.7.0-19-g89ec974" +GARAGE_SIGN_PV = "0.7.0-25-ge74a964" SRC_URI = " \ gitsm://github.com/advancedtelematic/aktualizr;branch=${BRANCH} \ @@ -28,8 +28,8 @@ SRC_URI = " \ " # for garage-sign archive -SRC_URI[md5sum] = "3ed27c1142860cd9b4a2594067312b8b" -SRC_URI[sha256sum] = "e54eef3863118f373c3ebd9e2877f9de5bab4950ed157a15fb4f4ec575bc2ece" +SRC_URI[md5sum] = "9601dd891abac754400852cf367e86a2" +SRC_URI[sha256sum] = "1ebe2c9655b1fcc8d597dbda10c8a413eca12e5351582d916d0b088a84c33cd2" SRCREV = "03778511cc937d07bf53a8092f8b268e65f5d9a6" BRANCH ?= "master" -- cgit v1.2.3-54-g00ecf From 6317861fc5a0c1fe804a84f5b44c7c3535faf4ed Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Wed, 21 Aug 2019 09:48:35 +0200 Subject: Use a default expiry of one month if nothing is specified. This mimics the intended behavior of the default in garage-sign, but doesn't rely on the date in the unsigned targets. Signed-off-by: Patrick Vacek --- classes/image_types_ostree.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/classes/image_types_ostree.bbclass b/classes/image_types_ostree.bbclass index fd67865..795e01b 100644 --- a/classes/image_types_ostree.bbclass +++ b/classes/image_types_ostree.bbclass @@ -248,6 +248,8 @@ IMAGE_CMD_garagesign () { target_expiry="--expires ${GARAGE_TARGET_EXPIRES}" elif [ -n "${GARAGE_TARGET_EXPIRE_AFTER}" ]; then target_expiry="--expire-after ${GARAGE_TARGET_EXPIRE_AFTER}" + else + target_expiry="--expire-after 1M" fi for push_retries in $( seq 3 ); do -- cgit v1.2.3-54-g00ecf From 43277ebbced942b134316df77a5af638f6644fe9 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Wed, 21 Aug 2019 11:31:39 +0200 Subject: README: new section for garage-sign. Specifically to explain the metadata expiry topic better. Signed-off-by: Patrick Vacek --- README.adoc | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.adoc b/README.adoc index 455b5d9..bcbcf96 100644 --- a/README.adoc +++ b/README.adoc @@ -200,6 +200,12 @@ IMAGE_INSTALL_append += " aktualizr-resource-control " RESOURCE_CPU_WEIGHT_pn-aktualizr = "50" .... +=== garage-sign configuration + +The https://github.com/advancedtelematic/ota-tuf/tree/master/cli[garage-sign] tool can be configured with variables described in the <> section. + +Of particular importance is controlling the expiration of the Targets metadata signed with garage-sign. This is described in detail in the https://docs.ota.here.com/ota-client/dev/metadata-expiry.html[OTA Connect documentation]. To set a manual expiration date, you can use either of the variables `GARAGE_TARGET_EXPIRES` or `GARAGE_TARGET_EXPIRE_AFTER`. Both cannot be supplied simultaneously. If neither are provided, a default of one month will be used. + == Development configuration === Logging -- cgit v1.2.3-54-g00ecf From 9dfb9607216189e0c3c093c96a0e5bc4c648f3ef Mon Sep 17 00:00:00 2001 From: Mykhaylo Sul Date: Mon, 26 Aug 2019 11:19:25 +0300 Subject: Use --wait-until-provisioned option while getting aktualizr status in the ip secondary tests Signed-off-by: Mykhaylo Sul --- lib/oeqa/selftest/cases/updater_qemux86_64.py | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/lib/oeqa/selftest/cases/updater_qemux86_64.py b/lib/oeqa/selftest/cases/updater_qemux86_64.py index 24abcff..4506300 100644 --- a/lib/oeqa/selftest/cases/updater_qemux86_64.py +++ b/lib/oeqa/selftest/cases/updater_qemux86_64.py @@ -360,17 +360,7 @@ class IpSecondaryTests(OESelftestTestCase): self._test_ctx.append_config('SOTA_CLIENT_PROV = " aktualizr-shared-prov "') def is_ecu_registered(self, ecu_id): - max_number_of_tries = 120 - try_counter = 0 - - # aktualizr-info is not always able to load ECU serials from DB - # so, let's run it a few times until it actually succeeds - while try_counter < max_number_of_tries: - device_status = self.get_info() - try_counter += 1 - if device_status.find("load ECU serials") == -1: - break - sleep(1) + device_status = self.get_info() if not ((device_status.find(ecu_id[0]) != -1) and (device_status.find(ecu_id[1]) != -1)): return False @@ -379,7 +369,7 @@ class IpSecondaryTests(OESelftestTestCase): return not_reg_start == -1 or (device_status.find(ecu_id[1], not_reg_start) == -1) def get_info(self): - stdout, stderr, retcode = self.send_command('aktualizr-info') + stdout, stderr, retcode = self.send_command('aktualizr-info --wait-until-provisioned', timeout=620) self._test_ctx.assertEqual(retcode, 0, 'Unable to run aktualizr-info: {}'.format(stderr)) return stdout -- cgit v1.2.3-54-g00ecf From c62172982c26581941d59523f12d2fb3e6a27a23 Mon Sep 17 00:00:00 2001 From: Merlin Carter Date: Wed, 21 Aug 2019 15:00:29 +0200 Subject: OTA-3594: adding restructured Antora-friendly content -Adding Antora dir structure - Break up content into individual file - Setting up files for including in other repos - Making options easier to read and more consistent with other reference doc. - Updated README to link to individual topic files rather than all on one page. - Added Mathias's requested HW and bootloader info - Added xaviers requested NRE clause. Signed-off-by: Merlin Carter --- README.adoc | 324 +++------------------- docs/antora.yml | 5 + docs/modules/ROOT/nav.adoc | 17 ++ docs/modules/ROOT/pages/build.adoc | 62 +++++ docs/modules/ROOT/pages/dev-config.adoc | 46 +++ docs/modules/ROOT/pages/meta-updater-testing.adoc | 44 +++ docs/modules/ROOT/pages/meta-updater-usage.adoc | 87 ++++++ docs/modules/ROOT/pages/provisioning-methods.adoc | 22 ++ docs/modules/ROOT/pages/sota-variables.adoc | 50 ++++ docs/modules/ROOT/pages/supported-boards.adoc | 47 ++++ 10 files changed, 412 insertions(+), 292 deletions(-) create mode 100644 docs/antora.yml create mode 100644 docs/modules/ROOT/nav.adoc create mode 100644 docs/modules/ROOT/pages/build.adoc create mode 100644 docs/modules/ROOT/pages/dev-config.adoc create mode 100644 docs/modules/ROOT/pages/meta-updater-testing.adoc create mode 100644 docs/modules/ROOT/pages/meta-updater-usage.adoc create mode 100644 docs/modules/ROOT/pages/provisioning-methods.adoc create mode 100644 docs/modules/ROOT/pages/sota-variables.adoc create mode 100644 docs/modules/ROOT/pages/supported-boards.adoc diff --git a/README.adoc b/README.adoc index bcbcf96..ab7879b 100644 --- a/README.adoc +++ b/README.adoc @@ -1,8 +1,11 @@ = meta-updater :toc: macro :toc-title: +:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/blob/master/ -This layer enables over-the-air updates (OTA) with https://github.com/ostreedev/ostree[OSTree] and https://github.com/advancedtelematic/aktualizr[Aktualizr]. +ifndef::env-github[:meta-updater-github-url:] + +Meta-updater is a link:https://www.yoctoproject.org/software-overview/layers/[Yocto layer] that enables over-the-air updates (OTA) with https://github.com/ostreedev/ostree[OSTree] and https://github.com/advancedtelematic/aktualizr[Aktualizr]. https://github.com/ostreedev/ostree[OSTree] is a tool for atomic full file system upgrades with rollback capability. OSTree has several advantages over traditional dual-bank systems, but the most important one is that it minimizes network bandwidth and data storage footprint by sharing files with the same contents across file system deployments. @@ -10,300 +13,37 @@ https://github.com/advancedtelematic/aktualizr[Aktualizr] (and https://github.co [discrete] == Table of Contents - -toc::[] - -== Build - -=== Quickstart - -If you don't already have a Yocto project that you want to add OTA to, you can use the https://docs.atsgarage.com/quickstarts/raspberry-pi.html[HERE OTA Connect Quickstart] project to rapidly get up and running on a Raspberry Pi. It takes a standard https://www.yoctoproject.org/tools-resources/projects/poky[poky] distribution, and adds OTA and OSTree capabilities. - -=== Dependencies - -In addition to the link:https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-packages-for-the-build-host[standard Yocto dependencies], meta-updater generally requires a few additional dependencies, depending on your use case and target platform. To install these additional packages on Debian/Ubuntu, run this: - -.... -sudo apt install cpu-checker default-jre parted -.... - -To build for https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] with GRUB, you will also need to install https://github.com/tianocore/tianocore.github.io/wiki/OVMF[TianoCore's ovmf] package on your host system. On Debian/Ubuntu, you can do so with this command: - -.... -sudo apt install ovmf -.... - -=== Adding meta-updater capabilities to your build - -If you already have a Yocto-based project and you want to add atomic filesystem updates to it, you just need to do three things: - -1. Clone the `meta-updater` layer and add it to your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[bblayers.conf]. -2. Clone BSP integration layer (`meta-updater-$\{PLATFORM}`, e.g. https://github.com/advancedtelematic/meta-updater-raspberrypi[meta-updater-raspberrypi]) and add it to your `conf/bblayers.conf`. If your board isn't supported yet, you could write a BSP integration for it yourself. See the <> section for the details. -3. Set up your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-DISTRO[distro]. If you are using "poky", the default distro in Yocto, you can change it in your `conf/local.conf` to "poky-sota". Alternatively, if you are using your own or third party distro configuration, you can add `INHERIT += " sota"` to it, thus combining capabilities of your distro with meta-updater features. - -You can then build your image as usual, with bitbake. After building the root file system, bitbake will then create an https://ostree.readthedocs.io/en/latest/manual/adapting-existing/[OSTree-enabled version] of it, commit it to your local OSTree repo and (optionally) push it to a remote server. Additionally, a live disk image will be created (normally named `$\{IMAGE_NAME}.-sdimg-ota` e.g. `core-image-raspberrypi3.rpi-sdimg-ota`). You can control this behaviour through <>. - -=== Build in AGL - -With AGL you can just add agl-sota feature while configuring your build environment: - -.... -source meta-agl/scripts/aglsetup.sh -m porter agl-demo agl-appfw-smack agl-devel agl-sota -.... - -You can then run: - -.... -bitbake agl-demo-platform -.... - -and get as a result an `ostree_repo` folder in your images directory (`tmp/deploy/images/$\{MACHINE}/ostree_repo`). It will contain: - -* your OSTree repository, with the rootfs committed as an OSTree deployment, -* an `ota-ext4` bootstrap image, which is an OSTree physical sysroot as a burnable filesystem image, and optionally -* some machine-dependent live images (e.g. `.wic` for Raspberry Pi or `.porter-sdimg-ota` for Renesas Porter board). - -Although `aglsetup.sh` hooks provide reasonable defaults for SOTA-related variables, you may want to tune some of them. - -=== Build problems - -Ubuntu users that encounter an error due to missing `Python.h` should install `libpython2.7-dev` on their host machine. - -== Supported boards - -Currently supported platforms are: - -* https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi 2 and 3] -* https://github.com/advancedtelematic/meta-updater-minnowboard[Intel Minnowboard] -* https://github.com/advancedtelematic/meta-updater-qemux86-64[Native QEMU emulation] -* Renesas R-Car H3 and M3 -* https://github.com/advancedtelematic/meta-updater-ti/[TI BeagleBone Black] (rocko only, using TI SDK 05.03) -* https://github.com/advancedtelematic/meta-updater-ti/[TI AM65x industrial development kit] (rocko only, using TI SDK 05.03) - -Additionally, there is community support for https://github.com/ricardosalveti/meta-updater-riscv[RISC-V] boards, in particular the Freedom U540. - -We also historically supported the https://github.com/advancedtelematic/meta-updater-porter[Renesas Porter] board. - -=== Adding support for your board - -If your board isn't supported yet, you can add board integration code yourself. The main purpose of this code is to provide a bootloader that will be able to use https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/[OSTree's boot directory]. In the meta-updater integration layers we have written so far, the basic steps are: - -1. Make the board boot into http://www.denx.de/wiki/U-Boot[U-Boot] -2. Make U-boot import variables from /boot/loader/uEnv.txt and load the kernel with initramfs and kernel command line arguments according to what is set in this file. - -You may take a look into https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] or https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi] integration layers for examples. - -Although we have focused on U-Boot and GRUB so far, other bootloaders can be configured to work with OSTree as well. - -Your images will also need network connectivity to be able to reach an actual OTA backend. Our 'poky-sota' distribution does not mandate or install a default network manager but our supported platforms use the `virtual/network-configuration` recipe, which can be used as a starting example. - -== SOTA-related variables in local.conf - -* `OSTREE_BRANCHNAME` - OSTree branch name. Defaults to `${SOTA_HARDWARE_ID}`. Particularly useful for grouping similar images. -* `OSTREE_REPO` - path to your OSTree repository. Defaults to `$\{DEPLOY_DIR_IMAGE}/ostree_repo` -* `OSTREE_OSNAME` - OS deployment name on your target device. For more information about deployments and osnames see the https://ostree.readthedocs.io/en/latest/manual/deployment/[OSTree documentation]. Defaults to "poky". -* `OSTREE_COMMIT_BODY` - Message attached to OSTree commit. Empty by default. -* `OSTREE_COMMIT_SUBJECT` - Commit subject used by OSTree. Defaults to `Commit-id: ${IMAGE_NAME}` -* `OSTREE_UPDATE_SUMMARY` - Set this to '1' to update summary of OSTree repository on each commit. '0' by default. -* `OSTREE_DEPLOY_DEVICETREE` - Set this to '1' to include devicetree(s) to boot -* `GARAGE_SIGN_AUTOVERSION` - Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. -* `GARAGE_TARGET_URL` - sets the `--url` parameter of `garage-sign targets add`, which sets a custom URL for the Image repository targets. -* `GARAGE_TARGET_EXPIRES` - sets the `--expires` parameter of `garage-sign targets sign`. Format is a UTC instant such as '2018-01-01T00:01:00Z'. -* `GARAGE_TARGET_EXPIRE_AFTER` - sets the `--expire-after` parameter of `garage-sign targets sign`. Format is in years, months, and days (each optional, but in that order), such as '1Y3M5D'. -* `INITRAMFS_IMAGE` - initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such a proxy. -* `SOTA_PACKED_CREDENTIALS` - when set, your ostree commit will be pushed to a remote repo as a bitbake step. This should be the path to a zipped credentials file in https://github.com/advancedtelematic/aktualizr/blob/master/docs/credentials.adoc[the format accepted by garage-push]. -* `SOTA_DEPLOY_CREDENTIALS` - when set to '1' (default value), deploys credentials to the built image. Override it in `local.conf` to built a generic image that can be provisioned manually after the build. -* `SOTA_CLIENT_PROV` - which provisioning method to use. Valid options are `aktualizr-shared-prov`, `aktualizr-device-prov`, and `aktualizr-device-prov-hsm`. For more information on these provisioning methods, see the https://docs.ota.here.com/client-config/client-provisioning-methods.html[OTA Connect documentation]. The default is `aktualizr-shared-prov`. This can also be set to an empty string to avoid using a provisioning recipe. -* `SOTA_CLIENT_FEATURES` - extensions to aktualizr. The only valid options are `hsm` (to build with HSM support) and `secondary-network` (to set up a simulated 'in-vehicle' network with support for a primary node with a DHCP server and a secondary node with a DHCP client). -* `SOTA_SECONDARY_CONFIG` - a file containing JSON configuration for secondaries. It will be installed into `/etc/sota/ecus` on the device and automatically provided to aktualizr. See link:https://github.com/advancedtelematic/aktualizr/blob/master/docs/posix-secondaries-bitbaking.adoc[here] for more details. -* `SOTA_HARDWARE_ID` - a custom hardware ID that will be written to the aktualizr config. Defaults to MACHINE if not set. -* `SOTA_MAIN_DTB` - base device tree to use with the kernel. Used together with FIT images. You can change it, and the device tree will also be changed after the update. -* `SOTA_DT_OVERLAYS` - whitespace-separated list of used device tree overlays for FIT image. This list is OSTree-updateable as well. -* `SOTA_EXTRA_CONF_FRAGS` - extra https://lxr.missinglinkelectronics.com/uboot/doc/uImage.FIT/overlay-fdt-boot.txt[configuration fragments] for FIT image. -* `RESOURCE_xxx_pn-aktualizr` - controls maximum resource usage of the aktualizr service, when `aktualizr-resource-control` is installed on the image. See <> for details. -* `SOTA_POLLING_SEC` - sets polling interval for aktualizr to check for updates if aktualizr-polling-interval is included in the image. - -== Usage - -=== OSTree - -OSTree used to include a simple HTTP server as part of the ostree binary, but this has been removed in more recent versions. However, OSTree repositories are self-contained directories, and can be trivially served over the network using any HTTP server. For example, you could use Python's SimpleHTTPServer: - -.... -cd tmp/deploy/images/qemux86-64/ostree_repo -python -m SimpleHTTPServer # port defaults to 8000 -.... - -You can then run ostree from inside your device by adding your repo: - -.... -# This behaves like adding a Git remote; you can name it anything -ostree remote add --no-gpg-verify my-remote http://: - -# If OSTREE_BRANCHNAME is set in local.conf, that will be the name of the -# branch. If not set, it defaults to the value of MACHINE (e.g. qemux86-64). -ostree pull my-remote - -# poky is the OS name as set in OSTREE_OSNAME -ostree admin deploy --os=poky my-remote: -.... - -After restarting, you will boot into the newly deployed OS image. - -For example, on the raspberry pi you can try this sequence: - -.... -# add remote -ostree remote add --no-gpg-verify agl-snapshot https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/images/raspberrypi3/ostree_repo/ agl-ota - -# pull -ostree pull agl-snapshot agl-ota - -# deploy -ostree admin deploy --os=agl agl-snapshot:agl-ota -.... - -=== garage-push - -The https://github.com/advancedtelematic/aktualizr[aktualizr repo] contains a tool, garage-push, which lets you push the changes in OSTree repository generated by bitbake process. It communicates with an http server capable of querying files with HEAD requests and uploading them with POST requests. In particular, this can be used with https://connect.ota.here.com/[HERE OTA Connect]. garage-push is used as follows: - -.... -garage-push --repo=/path/to/ostree-repo --ref=mybranch --credentials=/path/to/credentials.zip -.... - -You can set `SOTA_PACKED_CREDENTIALS` in your `local.conf` to automatically synchronize your build results with a remote server. Credentials are stored in an archive as described in the https://github.com/advancedtelematic/aktualizr/blob/master/docs/credentials.adoc[aktualizr documentation]. - -=== aktualizr configuration - -https://github.com/advancedtelematic/aktualizr[Aktualizr] supports a variety of https://github.com/advancedtelematic/aktualizr/blob/master/docs/configuration.adoc[configuration options via a configuration file and the command line]. There are two primary ways to control aktualizr's configuration from meta-updater. - -First, you can set `SOTA_CLIENT_PROV` to control which provisioning recipe is used. Each recipe installs an appropriate `sota.toml` file from aktualizr according to the provisioning needs. See the <> section for more information. - -Second, you can write recipes to install additional config files with customized options. A few recipes already exist to address common needs and provide an example: - -* link:recipes-sota/config/aktualizr-auto-reboot.bb[aktualizr-auto-reboot.bb] configures aktualizr to automatically reboot after new updates are installed in order to apply the updates immediately. This is only relevant for package managers (such as OSTree) that require a reboot to complete the installation process. If this is not enabled, you will need to reboot the system through other means. -* link:recipes-sota/config/aktualizr-disable-send-ip.bb[aktualizr-disable-send-ip.bb] disables the reporting of networking information to the server. This is enabled by default and supported by https://connect.ota.here.com/[HERE OTA Connect]. However, if you are using a different server that does not support this feature, you may want to disable it in aktualizr. -* link:recipes-sota/config/aktualizr-log-debug.bb[aktualizr-log-debug.bb] sets the log level of aktualizr to 0 (trace). The default is 2 (info). This recipe is intended for development and debugging purposes. - -To use these recipes, you will need to add them to your image with a line such as `IMAGE_INSTALL_append = " aktualizr-log-debug "` in your `local.conf`. - -=== aktualizr service resource control - -With systemd based images, it is possible to set resource policies for the aktualizr service. The main use case is to provide a safeguard against resource exhaustion during an unforeseen failure scenario. - -To enable it, install `aktualizr-resource-control` on the target image and optionally override the default resource limits set in link:recipes-sota/aktualizr/aktualizr_git.bb[aktualizr_git.bb], from your `local.conf`. - -For example: - -.... -IMAGE_INSTALL_append += " aktualizr-resource-control " -RESOURCE_CPU_WEIGHT_pn-aktualizr = "50" -.... - -=== garage-sign configuration - -The https://github.com/advancedtelematic/ota-tuf/tree/master/cli[garage-sign] tool can be configured with variables described in the <> section. - -Of particular importance is controlling the expiration of the Targets metadata signed with garage-sign. This is described in detail in the https://docs.ota.here.com/ota-client/dev/metadata-expiry.html[OTA Connect documentation]. To set a manual expiration date, you can use either of the variables `GARAGE_TARGET_EXPIRES` or `GARAGE_TARGET_EXPIRE_AFTER`. Both cannot be supplied simultaneously. If neither are provided, a default of one month will be used. - -== Development configuration - -=== Logging - -To troubleshoot problems that you might encounter during development, we recommend that you enable persistent `systemd` logging. This setting is enabled by default for newly configured environments (see link:conf/local.conf.sample.append[]). To enable it manually, put this to your `local.conf`: - -.... -IMAGE_INSTALL_append += " systemd-journald-persistent" -.... - -It may also be helpful to run with debug logging enabled in aktualizr. To do so, add this to your `local.conf`: - -.... -IMAGE_INSTALL_append += " aktualizr-log-debug" -.... - -=== Custom aktualizr versions - -You can override the version of aktualizr included in your image. This requires that the version you wish to run is pushed to the https://github.com/advancedtelematic/aktualizr[aktualizr github repo]. You can then use these settings in your `local.conf` to simplify the development process: - -[options="header"] -|====================== -| Option | Effect -| `require classes/sota_bleeding.inc` | Build the latest head (by default, using the master branch) of Aktualizr -| `BRANCH_pn-aktualizr = "mybranch"` - -`BRANCH_pn-aktualizr-native = "mybranch"` | Build `mybranch` of Aktualizr. Note that both of these need to be set. This is normally used in conjunction with `require classes/sota_bleeding.inc` -| `SRCREV_pn-aktualizr = "1004efa3f86cef90c012b34620992b5762b741e3"` - -`SRCREV_pn-aktualizr-native = "1004efa3f86cef90c012b34620992b5762b741e3"` | Build the specified revision of Aktualizr. Note that both of these need to be set. This can be used in conjunction with `BRANCH_pn-aktualizr` and `BRANCH_pn-aktualizr-native` but will conflict with `require classes/sota_bleeding.inc` -| `TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake "` | Use with `bitbake -c populate_sdk core-image-minimal` to build an SDK. See the https://github.com/advancedtelematic/aktualizr#developing-against-an-openembedded-system[aktualizr repo] for more information. -|====================== - -=== Overriding target version -*Warning: overriding target version is a dangerous operation, make sure you understand this section completely before doing it.* - -Every time you build an image with `SOTA_PACKED_CREDENTIALS` set, a new entry in your Uptane metadata is created and you can see it in the OTA Garage UI if you're using one. Normally this version will be equal to OSTree hash of your root file system. If you want it to be different though you can override is using one of two methods: - -1. Set `GARAGE_TARGET_VERSION` variable in your `local.conf`. -2. Write a recipe or a bbclass to write the desired version to `${STAGING_DATADIR_NATIVE}/target_version`. An example of such bbclass can be found in `classes/target_version_example.bbclass`. - -Please note that [target name, target version] pairs are expected to be unique in the system. If you build a new target with the same target version as a previously built one, the old package will be overwritten on the update server. It can have unpredictable effect on devices that have this version installed, and it is not guaranteed that information will be reported correctly for such devices or that you will be able to update them (we're doing our best though). The easiest way to avoid problems is to make sure that your overriding version is as unique as an OSTree commit hash. - -== QA with oe-selftest - -This layer relies on the test framework oe-selftest for quality assurance. Currently, you will need to run this in a build directory with `MACHINE` set to `qemux86-64`. Follow the steps below to run the tests: - -1. Append the line below to `conf/local.conf` to disable the warning about supported operating systems: +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/build.adoc[Build] + -``` -SANITY_TESTED_DISTROS = "" -``` - -2. If your image does not already include an ssh daemon such as dropbear or openssh, add this line to `conf/local.conf` as well: +Learn how to use this layer to build a basic disk image and add it to your own Yocto project. + -``` -IMAGE_INSTALL_append = " dropbear " -``` - -3. Some tests require that `SOTA_PACKED_CREDENTIALS` is set in your `conf/local.conf`. See the <> section. - -4. To be able to build an image for the GRUB tests, you will need to install the ovmf package as described in the <>. - -5. Run oe-selftest: +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/supported-boards.adoc[Supported boards] + -``` -oe-selftest -r updater_native updater_qemux86_64 updater_minnowboard updater_raspberrypi updater_qemux86_64_ptest -``` - -For more information about oe-selftest, including details about how to run individual test modules or classes, please refer to the https://wiki.yoctoproject.org/wiki/Oe-selftest[Yocto Project wiki]. - -== Aktualizr test suite with ptest - -The meta-updater layer includes support for running parts of the aktualizr test suite on deployed devices through link:https://wiki.yoctoproject.org/wiki/Ptest[Yocto's ptest functionality]. Since it adds significant build time cost, it is currently disabled by default. To enable it, add the following to your `conf/local.conf`: - -``` -PTEST_ENABLED_pn-aktualizr = "1" -IMAGE_INSTALL_append += " aktualizr-ptest ptest-runner " -``` - -Be aware that it will add several hundreds of MB to the generated file system. - -The aktualizr tests will now be part of the deployed ptest suite, which can be run by calling `ptest-runner`. Alternatively, the required files and run script can be found in `/usr/lib/aktualizr/ptest`. - -== Manual provisoning - -As described in <> section you can set `SOTA_DEPLOY_CREDENTIALS` to `0` to prevent deploying credentials to the built `wic` image. In this case you get a generic image that you can use e.g. on a production line to flash a series of devices. The cost of this approach is that this image is half-baked and should be provisioned before it can connect to the backend. - -Provisioning procedure depends on your provisioning recipe, i.e. the value of `SOTA_CLIENT_PROV` (equal to `aktualizr-shared-prov` by default): - -* For `aktualizr-shared-prov` put your `credentials.zip` to `/var/sota/sota_provisioning_credentials.zip` on the filesystem of a running device. If you have the filesystem of our device mounted to your build machine, prefix all paths with `/ostree/deploy/poky` as in `/ostree/deploy/poky/var/sota/sota_provisioning_credentials.zip`. -* For `aktualizr-device-prov` -** put URL to the backend server (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. -** put client certificate, private key and root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/client.pem`, `/var/sota/import/pkey.pem` and `/var/sota/import/root.crt` respectively. -* For `aktualizr-device-prov-hsm` -** put URL to the server backend (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. -** put root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/root.crt`. -** put client certificate and private key to slots 1 and 2 of the PKCS#11-compatible device. +Find out if your board is supported and learn about the minimum hardware requirements. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/sota-variables.adoc[SOTA-related variables in local.conf] ++ +Learn how to configure OTA-related functionality when building disk images. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-usage.adoc[Usage] ++ +Learn about the `garage-push` and `garage-sign` utilities, aktualizr configuration and service resource control, and OSTree. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/dev-config.adoc[Development configuration] ++ +Learn how to configure logging, install custom versions of aktualizr, and override the version indicator for sofware updates. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-testing.adoc#_qa_with_oe_selftest[QA with oe-selftest] ++ +Learn how to use the `oe-selftest` framework for quality assurance. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-testing.adoc#_aktualizr_test_suite_with_ptest[Aktualizr test suite with ptest] ++ +Learn how to enable Yocto's package test functionality and run parts of the aktualizr test suite. ++ +* xref:{meta-updater-github-url}docs/modules/ROOT/pages/provisioning-methods.adoc[Provisoning methods] ++ +Learn how to enable different methods for provisioning devices. == License diff --git a/docs/antora.yml b/docs/antora.yml new file mode 100644 index 0000000..5ed1239 --- /dev/null +++ b/docs/antora.yml @@ -0,0 +1,5 @@ +name: ota-build +title: OTA Connect Build Tools +version: dev +nav: +- modules/ROOT/nav.adoc diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc new file mode 100644 index 0000000..d4b577b --- /dev/null +++ b/docs/modules/ROOT/nav.adoc @@ -0,0 +1,17 @@ +// MC: NOTE ABOUT TOC +// Adding "pageroot" attr so that TOC that will also work directly in GitHub. Because... +// In Antora the "pages" subdir is implcit added to the xref path at build time. +// if you add "/pages" Antora will intepret it as "pages/pages". +// The pages subdir is NOT implicit when viewing source files in Github. + +ifdef::env-github[:pageroot: pages/] +ifndef::env-github[:pageroot:] + +.Guide to the Build Tools +* xref:{pageroot}metaupdater-whatis.adoc[What are the build tools?] +* xref:{pageroot}build.adoc[Build a disk image] +* xref:{pageroot}supported-boards.adoc[Supported Boards] +* xref:{pageroot}meta-updater-usage.adoc[How to] +* xref:{pageroot}sota-variables.adoc[Configuration reference] +* xref:{pageroot}dev-config.adoc[Development configuration] +* xref:{pageroot}meta-updater-testing.adoc[Testing] \ No newline at end of file diff --git a/docs/modules/ROOT/pages/build.adoc b/docs/modules/ROOT/pages/build.adoc new file mode 100644 index 0000000..135d468 --- /dev/null +++ b/docs/modules/ROOT/pages/build.adoc @@ -0,0 +1,62 @@ += Build +:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master + +== Quickstart + +If you don't already have a Yocto project that you want to add OTA to, you can use the xref:dev@getstarted::raspberry-pi.adoc[HERE OTA Connect Quickstart] project to rapidly get up and running on a Raspberry Pi. It takes a standard https://www.yoctoproject.org/tools-resources/projects/poky[poky] distribution, and adds OTA and OSTree capabilities. + +== Dependencies + +//MC: TOMERGE: These "dependencies" mostly just duplicates the prerequisite sections: https://main.gitlab.in.here.com/olp/edge/ota/documentation/ota-connect-docs/blob/master/docs/getstarted/modules/ROOT/pages/raspberry-pi.adoc + +In addition to the link:https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-packages-for-the-build-host[standard Yocto dependencies], meta-updater generally requires a few additional dependencies, depending on your use case and target platform. To install these additional packages on Debian/Ubuntu, run this: + +.... +sudo apt install cpu-checker default-jre parted +.... + +To build for https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] with GRUB, you will also need to install https://github.com/tianocore/tianocore.github.io/wiki/OVMF[TianoCore's ovmf] package on your host system. On Debian/Ubuntu, you can do so with this command: + +.... +sudo apt install ovmf +.... + +== Adding meta-updater capabilities to your build + +// MC: TOMERGE: This content mosty duplicates https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc + +If you already have a Yocto-based project and you want to add atomic filesystem updates to it, you just need to do three things: + +1. Clone the `meta-updater` layer and add it to your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[bblayers.conf]. +2. Clone BSP integration layer (`meta-updater-$\{PLATFORM}`, e.g. https://github.com/advancedtelematic/meta-updater-raspberrypi[meta-updater-raspberrypi]) and add it to your `conf/bblayers.conf`. If your board isn't supported yet, you could write a BSP integration for it yourself. See the <> section for the details. +3. Set up your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-DISTRO[distro]. If you are using "poky", the default distro in Yocto, you can change it in your `conf/local.conf` to "poky-sota". Alternatively, if you are using your own or third party distro configuration, you can add `INHERIT += " sota"` to it, thus combining capabilities of your distro with meta-updater features. + +You can then build your image as usual, with bitbake. After building the root file system, bitbake will then create an https://ostree.readthedocs.io/en/latest/manual/adapting-existing/[OSTree-enabled version] of it, commit it to your local OSTree repo and (optionally) push it to a remote server. Additionally, a live disk image will be created (normally named `$\{IMAGE_NAME}.-sdimg-ota` e.g. `core-image-raspberrypi3.rpi-sdimg-ota`). You can control this behaviour through <>. + +== Build in AGL + +// MC: TOMERGE: This content duplicates https://main.gitlab.in.here.com/olp/edge/ota/documentation/ota-connect-docs/blob/master/docs/getstarted/modules/ROOT/pages/automotive-grade-linux.adoc (except that it is a lot sparser) + +With AGL you can just add agl-sota feature while configuring your build environment: + +.... +source meta-agl/scripts/aglsetup.sh -m porter agl-demo agl-appfw-smack agl-devel agl-sota +.... + +You can then run: + +.... +bitbake agl-demo-platform +.... + +and get as a result an `ostree_repo` folder in your images directory (`tmp/deploy/images/$\{MACHINE}/ostree_repo`). It will contain: + +* your OSTree repository, with the rootfs committed as an OSTree deployment, +* an `ota-ext4` bootstrap image, which is an OSTree physical sysroot as a burnable filesystem image, and optionally +* some machine-dependent live images (e.g. `.wic` for Raspberry Pi or `.porter-sdimg-ota` for Renesas Porter board). + +Although `aglsetup.sh` hooks provide reasonable defaults for SOTA-related variables, you may want to tune some of them. + +== Build problems + +Ubuntu users that encounter an error due to missing `Python.h` should install `libpython2.7-dev` on their host machine. diff --git a/docs/modules/ROOT/pages/dev-config.adoc b/docs/modules/ROOT/pages/dev-config.adoc new file mode 100644 index 0000000..60002a5 --- /dev/null +++ b/docs/modules/ROOT/pages/dev-config.adoc @@ -0,0 +1,46 @@ += Development configuration +:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master + +//MC: The dev guide already has a recommended config topic: https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/recommended-clientconfig.adoc +// This content pretty much serves the same purpose except 'local.conf' instead of 'sota_conf.toml' Clean this up and use an :include: ref reuse in that topic? + +== Logging + +To troubleshoot problems that you might encounter during development, we recommend that you enable persistent `systemd` logging. This setting is enabled by default for newly configured environments (see link:{meta-updater-github-url}/conf/local.conf.sample.append[]). To enable it manually, put this to your `local.conf`: + +.... +IMAGE_INSTALL_append += " systemd-journald-persistent" +.... + +It may also be helpful to run with debug logging enabled in aktualizr. To do so, add this to your `local.conf`: + +.... +IMAGE_INSTALL_append += " aktualizr-log-debug" +.... + +== Custom aktualizr versions + +You can override the version of aktualizr included in your image. This requires that the version you wish to run is pushed to the https://github.com/advancedtelematic/aktualizr[aktualizr github repo]. You can then use these settings in your `local.conf` to simplify the development process: + +[options="header"] +|====================== +| Option | Effect +| `require classes/sota_bleeding.inc` | Build the latest head (by default, using the master branch) of Aktualizr +| `BRANCH_pn-aktualizr = "mybranch"` + +`BRANCH_pn-aktualizr-native = "mybranch"` | Build `mybranch` of Aktualizr. Note that both of these need to be set. This is normally used in conjunction with `require classes/sota_bleeding.inc` +| `SRCREV_pn-aktualizr = "1004efa3f86cef90c012b34620992b5762b741e3"` + +`SRCREV_pn-aktualizr-native = "1004efa3f86cef90c012b34620992b5762b741e3"` | Build the specified revision of Aktualizr. Note that both of these need to be set. This can be used in conjunction with `BRANCH_pn-aktualizr` and `BRANCH_pn-aktualizr-native` but will conflict with `require classes/sota_bleeding.inc` +| `TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake "` | Use with `bitbake -c populate_sdk core-image-minimal` to build an SDK. See the https://github.com/advancedtelematic/aktualizr#developing-against-an-openembedded-system[aktualizr repo] for more information. +|====================== + +== Overriding target version +*Warning: overriding target version is a dangerous operation, make sure you understand this section completely before doing it.* + +Every time you build an image with `SOTA_PACKED_CREDENTIALS` set, a new entry in your Uptane metadata is created and you can see it in the OTA Garage UI if you're using one. Normally this version will be equal to OSTree hash of your root file system. If you want it to be different though you can override is using one of two methods: + +1. Set `GARAGE_TARGET_VERSION` variable in your `local.conf`. +2. Write a recipe or a bbclass to write the desired version to `${STAGING_DATADIR_NATIVE}/target_version`. An example of such bbclass can be found in `classes/target_version_example.bbclass`. + +Please note that [target name, target version] pairs are expected to be unique in the system. If you build a new target with the same target version as a previously built one, the old package will be overwritten on the update server. It can have unpredictable effect on devices that have this version installed, and it is not guaranteed that information will be reported correctly for such devices or that you will be able to update them (we're doing our best though). The easiest way to avoid problems is to make sure that your overriding version is as unique as an OSTree commit hash. diff --git a/docs/modules/ROOT/pages/meta-updater-testing.adoc b/docs/modules/ROOT/pages/meta-updater-testing.adoc new file mode 100644 index 0000000..1e20c87 --- /dev/null +++ b/docs/modules/ROOT/pages/meta-updater-testing.adoc @@ -0,0 +1,44 @@ += Testing + +//MC: No overlap with any content currently in the developer guide, but probably useful content to clean up and include. + +== QA with oe-selftest + +This layer relies on the test framework oe-selftest for quality assurance. Currently, you will need to run this in a build directory with `MACHINE` set to `qemux86-64`. Follow the steps below to run the tests: + +1. Append the line below to `conf/local.conf` to disable the warning about supported operating systems: ++ +``` +SANITY_TESTED_DISTROS = "" +``` + +2. If your image does not already include an ssh daemon such as dropbear or openssh, add this line to `conf/local.conf` as well: ++ +``` +IMAGE_INSTALL_append = " dropbear " +``` + +3. Some tests require that `SOTA_PACKED_CREDENTIALS` is set in your `conf/local.conf`. See the xref:dev@ota-build::sota-variables.adoc[SOTA-related variables in local.conf]. + +4. To be able to build an image for the GRUB tests, you will need to install the `ovmf` package as described in the xref:dev@ota-build::build.adoc#_dependencies[dependencies section]. + +5. Run oe-selftest: ++ +``` +oe-selftest -r updater_native updater_qemux86_64 updater_minnowboard updater_raspberrypi updater_qemux86_64_ptest +``` + +For more information about oe-selftest, including details about how to run individual test modules or classes, please refer to the https://wiki.yoctoproject.org/wiki/Oe-selftest[Yocto Project wiki]. + +== Aktualizr test suite with ptest + +The meta-updater layer includes support for running parts of the aktualizr test suite on deployed devices through link:https://wiki.yoctoproject.org/wiki/Ptest[Yocto's ptest functionality]. Since it adds significant build time cost, it is currently disabled by default. To enable it, add the following to your `conf/local.conf`: + +``` +PTEST_ENABLED_pn-aktualizr = "1" +IMAGE_INSTALL_append += " aktualizr-ptest ptest-runner " +``` + +Be aware that it will add several hundreds of MB to the generated file system. + +The aktualizr tests will now be part of the deployed ptest suite, which can be run by calling `ptest-runner`. Alternatively, the required files and run script can be found in `/usr/lib/aktualizr/ptest`. diff --git a/docs/modules/ROOT/pages/meta-updater-usage.adoc b/docs/modules/ROOT/pages/meta-updater-usage.adoc new file mode 100644 index 0000000..cc53a9f --- /dev/null +++ b/docs/modules/ROOT/pages/meta-updater-usage.adoc @@ -0,0 +1,87 @@ += Usage +:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master +:metadata-expiry-article: xref:dev@ota-client::metadata-expiry.adoc[OTA Connect documentation] +ifdef::env-github[:metadata-expiry-article: link:https://docs.ota.here.com/ota-client/dev/metadata-expiry.html[OTA Connect documentation]] + +//MC: No overlap with any content currently in the developer guide, but probably useful content to clean up and include. eg: use cases. + +== OSTree + +OSTree used to include a simple HTTP server as part of the ostree binary, but this has been removed in more recent versions. However, OSTree repositories are self-contained directories, and can be trivially served over the network using any HTTP server. For example, you could use Python's SimpleHTTPServer: + +.... +cd tmp/deploy/images/qemux86-64/ostree_repo +python -m SimpleHTTPServer # port defaults to 8000 +.... + +You can then run ostree from inside your device by adding your repo: + +.... +# This behaves like adding a Git remote; you can name it anything +ostree remote add --no-gpg-verify my-remote http://: + +# If OSTREE_BRANCHNAME is set in local.conf, that will be the name of the +# branch. If not set, it defaults to the value of MACHINE (e.g. qemux86-64). +ostree pull my-remote + +# poky is the OS name as set in OSTREE_OSNAME +ostree admin deploy --os=poky my-remote: +.... + +After restarting, you will boot into the newly deployed OS image. + +For example, on the raspberry pi you can try this sequence: + +.... +# add remote +ostree remote add --no-gpg-verify agl-snapshot https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/images/raspberrypi3/ostree_repo/ agl-ota + +# pull +ostree pull agl-snapshot agl-ota + +# deploy +ostree admin deploy --os=agl agl-snapshot:agl-ota +.... + +== garage-push + +The https://github.com/advancedtelematic/aktualizr[aktualizr repo] contains a tool, garage-push, which lets you push the changes in OSTree repository generated by bitbake process. It communicates with an http server capable of querying files with HEAD requests and uploading them with POST requests. In particular, this can be used with https://connect.ota.here.com/[HERE OTA Connect]. garage-push is used as follows: + +.... +garage-push --repo=/path/to/ostree-repo --ref=mybranch --credentials=/path/to/credentials.zip +.... + +You can set `SOTA_PACKED_CREDENTIALS` in your `local.conf` to automatically synchronize your build results with a remote server. Credentials are stored in an archive as described in the xref:dev@ota-client::provisioning-methods-and-credentialszip.adoc[aktualizr documentation]. + +== aktualizr configuration + +https://github.com/advancedtelematic/aktualizr[Aktualizr] supports a variety of xref:dev@ota-client::aktualizr-config-options.adoc[configuration options via a configuration file and the command line]. There are two primary ways to control aktualizr's configuration from meta-updater. + +First, you can set `SOTA_CLIENT_PROV` to control which provisioning recipe is used. Each recipe installs an appropriate `sota.toml` file from aktualizr according to the provisioning needs. See the xref:dev@ota-build::sota-variables.adoc[SOTA-related variables in local.conf] section for more information. + +Second, you can write recipes to install additional config files with customized options. A few recipes already exist to address common needs and provide an example: + +* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-auto-reboot.bb[aktualizr-auto-reboot.bb] configures aktualizr to automatically reboot after new updates are installed in order to apply the updates immediately. This is only relevant for package managers (such as OSTree) that require a reboot to complete the installation process. If this is not enabled, you will need to reboot the system through other means. +* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-disable-send-ip.bb[aktualizr-disable-send-ip.bb] disables the reporting of networking information to the server. This is enabled by default and supported by https://connect.ota.here.com/[HERE OTA Connect]. However, if you are using a different server that does not support this feature, you may want to disable it in aktualizr. +* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-log-debug.bb[aktualizr-log-debug.bb] sets the log level of aktualizr to 0 (trace). The default is 2 (info). This recipe is intended for development and debugging purposes. + +To use these recipes, you will need to add them to your image with a line such as `IMAGE_INSTALL_append = " aktualizr-log-debug "` in your `local.conf`. + +== aktualizr service resource control + +With systemd based images, it is possible to set resource policies for the aktualizr service. The main use case is to provide a safeguard against resource exhaustion during an unforeseen failure scenario. + +To enable it, install `aktualizr-resource-control` on the target image and optionally override the default resource limits set in link:{meta-updater-github-url}/recipes-sota/aktualizr/aktualizr_git.bb[aktualizr_git.bb], from your `local.conf`. + +For example: + +.... +IMAGE_INSTALL_append += " aktualizr-resource-control " +RESOURCE_CPU_WEIGHT_pn-aktualizr = "50" +.... + +=== garage-sign configuration + +The https://github.com/advancedtelematic/ota-tuf/tree/master/cli[garage-sign] tool can be configured with variables described in the xref:sota-variables.adoc[SOTA-related variables in local.conf] section. + +Of particular importance is controlling the expiration of the Targets metadata signed with garage-sign. This is described in detail in the {metadata-expiry-article}. To set a manual expiration date, you can use either of the variables `GARAGE_TARGET_EXPIRES` or `GARAGE_TARGET_EXPIRE_AFTER`. Both cannot be supplied simultaneously. If neither are provided, a default of one month will be used. \ No newline at end of file diff --git a/docs/modules/ROOT/pages/provisioning-methods.adoc b/docs/modules/ROOT/pages/provisioning-methods.adoc new file mode 100644 index 0000000..c376c78 --- /dev/null +++ b/docs/modules/ROOT/pages/provisioning-methods.adoc @@ -0,0 +1,22 @@ += Manual provisoning + +//MC: TOMERGE: Looks mostly like a duplicate of this topic: https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/simulate-device-cred-provtest.adoc + +As described in the xref:xref:dev@ota-build::sota-variables.adoc[configuration reference], you can set `SOTA_DEPLOY_CREDENTIALS` to `0` to prevent deploying credentials to the built `wic` image. In this case you get a generic image that you can use e.g. on a production line to flash a series of devices. The cost of this approach is that this image is half-baked and should be provisioned before it can connect to the backend. + +Provisioning procedure depends on your provisioning recipe, i.e. the value of `SOTA_CLIENT_PROV` (equal to `aktualizr-shared-prov` by default): + +* For `aktualizr-shared-prov` put your `credentials.zip` to `/var/sota/sota_provisioning_credentials.zip` on the filesystem of a running device. If you have the filesystem of our device mounted to your build machine, prefix all paths with `/ostree/deploy/poky` as in `/ostree/deploy/poky/var/sota/sota_provisioning_credentials.zip`. +* For `aktualizr-device-prov` +** put URL to the backend server (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. +** put client certificate, private key and root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/client.pem`, `/var/sota/import/pkey.pem` and `/var/sota/import/root.crt` respectively. +* For `aktualizr-device-prov-hsm` +** put URL to the server backend (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. +** put root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/root.crt`. +** put client certificate and private key to slots 1 and 2 of the PKCS#11-compatible device. + +For more extensive information on provisioning methods, see the following topics from the OTA Connect Developer guide: + +//MC: Web links because this topic is only viewable in Github +* link:https://docs.ota.here.com/ota-client/dev/client-provisioning-methods.html[Device provisioning methods] +* link:https://docs.ota.here.com/ota-client/dev/enable-device-cred-provisioning.html[Enable device-credential provisioning and install device certificates] \ No newline at end of file diff --git a/docs/modules/ROOT/pages/sota-variables.adoc b/docs/modules/ROOT/pages/sota-variables.adoc new file mode 100644 index 0000000..1dbc89a --- /dev/null +++ b/docs/modules/ROOT/pages/sota-variables.adoc @@ -0,0 +1,50 @@ += Build Configuration Options +:page-partial: +// MC: Included in aktualizr/docs/ota-client-guide/modules/ROOT/pages/build-configuration.adoc + +.OTA-related options for building disk images +[cols="1,2a",options="header"] +|==================== +| Option | Description +| `OSTREE_BRANCHNAME`|OSTree branch name. Defaults to `${SOTA_HARDWARE_ID}`. Particularly useful for grouping similar images. +| `OSTREE_REPO`|Path to your OSTree repository. Defaults to `$\{DEPLOY_DIR_IMAGE}/ostree_repo` +| `OSTREE_OSNAME`|OS deployment name on your target device. For more information about deployments and osnames see the https://ostree.readthedocs.io/en/latest/manual/deployment/[OSTree documentation]. Defaults to "poky". +| `OSTREE_COMMIT_BODY`|Message attached to OSTree commit. Empty by default. +| `OSTREE_COMMIT_SUBJECT`|Commit subject used by OSTree. Defaults to `Commit-id: ${IMAGE_NAME}` +| `OSTREE_UPDATE_SUMMARY`|Set this to '1' to update summary of OSTree repository on each commit. '0' by default. +| `OSTREE_DEPLOY_DEVICETREE`|Set this to '1' to include devicetree(s) to boot +| `GARAGE_SIGN_AUTOVERSION`|Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. +| `GARAGE_TARGET_URL` | Sets the `--url` parameter of `garage-sign targets add`, which sets a custom URL for the Image repository targets. +ifndef::env-github[] +[NOTE] +==== +Currently, this only works when using the master branch of meta-updater. +==== +endif::[] +| `GARAGE_TARGET_EXPIRES` | Sets the `--expires` parameter of `garage-sign targets sign`. Format is a UTC instant such as '2018-01-01T00:01:00Z'. +ifndef::env-github[] +[NOTE] +==== +Currently, this only works when using the master branch of meta-updater. +==== +endif::[] +| `GARAGE_TARGET_EXPIRE_AFTER` | Sets the `--expire-after` parameter of `garage-sign targets sign`. Format is in years, months, and days (each optional, but in that order), such as '1Y3M5D'. +ifndef::env-github[] +[NOTE] +==== +Currently, this only works when using the master branch of meta-updater. +==== +endif::[] +| `INITRAMFS_IMAGE`|The initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such a proxy. +| `SOTA_PACKED_CREDENTIALS`|When set, your ostree commit will be pushed to a remote repo as a bitbake step. This should be the path to a zipped credentials file in xref:dev@ota-build::provisioning-methods-and-credentialszip.adoc[the format accepted by garage-push]. +| `SOTA_DEPLOY_CREDENTIALS`|When set to '1' (default value), deploys credentials to the built image. Override it in `local.conf` to built a generic image that can be provisioned manually after the build. +| `SOTA_CLIENT_PROV`|Which provisioning method to use. Valid options are `aktualizr-shared-prov`, `aktualizr-device-prov`, and `aktualizr-device-prov-hsm`. For more information on these provisioning methods, see the xref:dev@ota-client::client-provisioning-methods.adoc[OTA Connect documentation]. The default is `aktualizr-shared-prov`. This can also be set to an empty string to avoid using a provisioning recipe. +| `SOTA_CLIENT_FEATURES`|Extensions to aktualizr. The only valid options are `hsm` (to build with HSM support) and `secondary-network` (to set up a simulated 'in-vehicle' network with support for a primary node with a DHCP server and a secondary node with a DHCP client). +| `SOTA_SECONDARY_CONFIG`|A file containing JSON configuration for secondaries. It will be installed into `/etc/sota/ecus` on the device and automatically provided to aktualizr. See xref:dev@ota-client::posix-secondaries-bitbaking.adoc[here] for more details. +| `SOTA_HARDWARE_ID`|A custom hardware ID that will be written to the aktualizr config. Defaults to MACHINE if not set. +| `SOTA_MAIN_DTB`|The base device tree to use with the kernel. Used together with FIT images. You can change it, and the device tree will also be changed after the update. +| `SOTA_DT_OVERLAYS`|A whitespace-separated list of used device tree overlays for FIT image. This list is OSTree-updateable as well. +| `SOTA_EXTRA_CONF_FRAGS`|Extra https://lxr.missinglinkelectronics.com/uboot/doc/uImage.FIT/overlay-fdt-boot.txt[configuration fragments] for FIT image. +| `RESOURCE_xxx_pn-aktualizr`|Controls maximum resource usage of the aktualizr service, when `aktualizr-resource-control` is installed on the image. See xref:dev@ota-build::meta-updater-usage.adoc#_aktualizr_service_resource_control[aktualizr service resource control] for details. +| `SOTA_POLLING_SEC`|Sets polling interval for aktualizr to check for updates if aktualizr-polling-interval is included in the image. +|==================== \ No newline at end of file diff --git a/docs/modules/ROOT/pages/supported-boards.adoc b/docs/modules/ROOT/pages/supported-boards.adoc new file mode 100644 index 0000000..c3b29bf --- /dev/null +++ b/docs/modules/ROOT/pages/supported-boards.adoc @@ -0,0 +1,47 @@ += Supported boards +:page-partial: +// MC: Included in aktualizr/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc +Currently supported platforms are: + +* https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi 2 and 3] +* https://github.com/advancedtelematic/meta-updater-minnowboard[Intel Minnowboard] +* https://github.com/advancedtelematic/meta-updater-qemux86-64[Native QEMU emulation] +* Renesas R-Car H3 and M3 +* https://github.com/advancedtelematic/meta-updater-ti/[TI BeagleBone Black] (rocko only, using TI SDK 05.03) +* https://github.com/advancedtelematic/meta-updater-ti/[TI AM65x industrial development kit] (rocko only, using TI SDK 05.03) + +Additionally, there is community support for https://github.com/ricardosalveti/meta-updater-riscv[RISC-V] boards, in particular the Freedom U540. + +We also historically supported the https://github.com/advancedtelematic/meta-updater-porter[Renesas Porter] board. + +== Adding support for your board + +If your board isn't supported yet, you can add board integration code yourself. The main purpose of this code is to provide a bootloader that will be able to use https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/[OSTree's boot directory]. In the meta-updater integration layers we have written so far, the basic steps are: + +1. Make the board boot into http://www.denx.de/wiki/U-Boot[U-Boot] +2. Make U-boot import variables from /boot/loader/uEnv.txt and load the kernel with initramfs and kernel command line arguments according to what is set in this file. + +Take a look at the https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] or https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi] integration layers for examples. + +If you want our developers to add support for your board, contact us at mailto:otaconnect.support@here.com[] and we can discuss a potential NRE (Non-recurring Engineering) aggreement. + +[NOTE] +==== +Although we have focused on U-Boot and GRUB so far, other bootloaders can be configured to work with OSTree as well. If you want to use a different bootloader, contact us at mailto:otaconnect.support@here.com[]. +==== + +Your images will also need network connectivity to be able to reach an actual OTA backend. Our 'poky-sota' distribution does not mandate or install a default network manager but our supported platforms use the `virtual/network-configuration` recipe, which can be used as a starting example. + +== Minimum hardware requirements for controllers (ECUs) + +The aktuallizr binary is a lightweight {cpp} application between 2-5 MB in size. It uses a miniumum about of resources when idle. + +The following hardware is required for your primary ECU: + +* At a minimum, aktualizr needs **16 MB of RAM** and **128 MB of storage** to run. +* We recommend that you use a controller with **128 MB of RAM** and **512 MB storage** -- especially if you if your plan to process large, complex sofware updates. + +[NOTE] +==== +If you plan to send updates to secondary, low-performance ECUs, you can also use a more minimal implementaton called link:https://github.com/advancedtelematic/aktualizr/tree/master/partial/libuptiny[`libuptiny`]. This utility is only 10 KB and performs a minimal verification of software metadata that is less resource intensive. For more information on `libuptiny`, contact us at mailto:otaconnect.support@here.com[]. +==== \ No newline at end of file -- cgit v1.2.3-54-g00ecf From 567701ad1932be68badac2bff369d60eb46d73e6 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Fri, 30 Aug 2019 16:42:08 +0200 Subject: Move rocko and sumo to the passive support list. Signed-off-by: Patrick Vacek --- CONTRIBUTING.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index 0b40438..efaccbb 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -3,11 +3,11 @@ We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent previous branches and welcome bug fixes and backports for those. Currently, the actively maintained branches are: * thud -* sumo -* rocko Previously, some older branches were also regularly supported, and while they should still be stable, they have not been updated or actively maintained for a while. These branches include: +* sumo +* rocko * pyro * morty -- cgit v1.2.3-54-g00ecf From 142e6b5665dc81dd35821b8ca7df54222b22d585 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 12 Aug 2019 17:15:08 +0200 Subject: Fix some minor typos. Signed-off-by: Patrick Vacek --- docs/modules/ROOT/pages/provisioning-methods.adoc | 4 ++-- docs/modules/ROOT/pages/supported-boards.adoc | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/modules/ROOT/pages/provisioning-methods.adoc b/docs/modules/ROOT/pages/provisioning-methods.adoc index c376c78..0f9051e 100644 --- a/docs/modules/ROOT/pages/provisioning-methods.adoc +++ b/docs/modules/ROOT/pages/provisioning-methods.adoc @@ -1,4 +1,4 @@ -= Manual provisoning += Manual provisioning //MC: TOMERGE: Looks mostly like a duplicate of this topic: https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/simulate-device-cred-provtest.adoc @@ -19,4 +19,4 @@ For more extensive information on provisioning methods, see the following topics //MC: Web links because this topic is only viewable in Github * link:https://docs.ota.here.com/ota-client/dev/client-provisioning-methods.html[Device provisioning methods] -* link:https://docs.ota.here.com/ota-client/dev/enable-device-cred-provisioning.html[Enable device-credential provisioning and install device certificates] \ No newline at end of file +* link:https://docs.ota.here.com/ota-client/dev/enable-device-cred-provisioning.html[Enable device-credential provisioning and install device certificates] diff --git a/docs/modules/ROOT/pages/supported-boards.adoc b/docs/modules/ROOT/pages/supported-boards.adoc index c3b29bf..3c7e3f9 100644 --- a/docs/modules/ROOT/pages/supported-boards.adoc +++ b/docs/modules/ROOT/pages/supported-boards.adoc @@ -23,7 +23,7 @@ If your board isn't supported yet, you can add board integration code yourself. Take a look at the https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] or https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi] integration layers for examples. -If you want our developers to add support for your board, contact us at mailto:otaconnect.support@here.com[] and we can discuss a potential NRE (Non-recurring Engineering) aggreement. +If you want our developers to add support for your board, contact us at mailto:otaconnect.support@here.com[] and we can discuss a potential NRE (Non-recurring Engineering) agreement. [NOTE] ==== @@ -34,7 +34,7 @@ Your images will also need network connectivity to be able to reach an actual OT == Minimum hardware requirements for controllers (ECUs) -The aktuallizr binary is a lightweight {cpp} application between 2-5 MB in size. It uses a miniumum about of resources when idle. +The aktualizr binary is a lightweight {cpp} application between 2-5 MB in size. It uses a minimum amount of resources when idle. The following hardware is required for your primary ECU: @@ -44,4 +44,4 @@ The following hardware is required for your primary ECU: [NOTE] ==== If you plan to send updates to secondary, low-performance ECUs, you can also use a more minimal implementaton called link:https://github.com/advancedtelematic/aktualizr/tree/master/partial/libuptiny[`libuptiny`]. This utility is only 10 KB and performs a minimal verification of software metadata that is less resource intensive. For more information on `libuptiny`, contact us at mailto:otaconnect.support@here.com[]. -==== \ No newline at end of file +==== -- cgit v1.2.3-54-g00ecf From 2ecaee697c86c8596ba0306b5ccbfcb31ce274ab Mon Sep 17 00:00:00 2001 From: Merlin Carter Date: Thu, 29 Aug 2019 12:36:03 +0200 Subject: OTA-3629: Responding to PR comments - added "tree" instead of "blob" in root path. - Adding ref to developer guide - fixed erroneous note. Signed-off-by: Merlin Carter --- README.adoc | 7 +++++-- docs/modules/ROOT/pages/sota-variables.adoc | 6 ------ 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/README.adoc b/README.adoc index ab7879b..97b9987 100644 --- a/README.adoc +++ b/README.adoc @@ -1,11 +1,11 @@ = meta-updater :toc: macro :toc-title: -:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/blob/master/ +:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master/ ifndef::env-github[:meta-updater-github-url:] -Meta-updater is a link:https://www.yoctoproject.org/software-overview/layers/[Yocto layer] that enables over-the-air updates (OTA) with https://github.com/ostreedev/ostree[OSTree] and https://github.com/advancedtelematic/aktualizr[Aktualizr]. +Meta-updater is a link:https://www.yoctoproject.org/software-overview/layers/[Yocto layer] that enables over-the-air updates (OTA) with https://github.com/ostreedev/ostree[OSTree] and https://github.com/advancedtelematic/aktualizr[Aktualizr] -- the default client for link:https://www.here.com/products/automotive/ota-technology[HERE OTA Connect]. https://github.com/ostreedev/ostree[OSTree] is a tool for atomic full file system upgrades with rollback capability. OSTree has several advantages over traditional dual-bank systems, but the most important one is that it minimizes network bandwidth and data storage footprint by sharing files with the same contents across file system deployments. @@ -13,6 +13,9 @@ https://github.com/advancedtelematic/aktualizr[Aktualizr] (and https://github.co [discrete] == Table of Contents + +The following documentation focuses on tasks that involve the meta-updater layer. If you want to get an idea of the overall developer workflow in OTA Connect, see the link:https://docs.ota.here.com/ota-client/dev/index.html[OTA Connect Developer Guide]. + * xref:{meta-updater-github-url}docs/modules/ROOT/pages/build.adoc[Build] + Learn how to use this layer to build a basic disk image and add it to your own Yocto project. diff --git a/docs/modules/ROOT/pages/sota-variables.adoc b/docs/modules/ROOT/pages/sota-variables.adoc index 1dbc89a..7614a8a 100644 --- a/docs/modules/ROOT/pages/sota-variables.adoc +++ b/docs/modules/ROOT/pages/sota-variables.adoc @@ -15,12 +15,6 @@ | `OSTREE_DEPLOY_DEVICETREE`|Set this to '1' to include devicetree(s) to boot | `GARAGE_SIGN_AUTOVERSION`|Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. | `GARAGE_TARGET_URL` | Sets the `--url` parameter of `garage-sign targets add`, which sets a custom URL for the Image repository targets. -ifndef::env-github[] -[NOTE] -==== -Currently, this only works when using the master branch of meta-updater. -==== -endif::[] | `GARAGE_TARGET_EXPIRES` | Sets the `--expires` parameter of `garage-sign targets sign`. Format is a UTC instant such as '2018-01-01T00:01:00Z'. ifndef::env-github[] [NOTE] -- cgit v1.2.3-54-g00ecf From f017f75fd5f142799a0453b8faf368ac2adad5af Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Wed, 4 Sep 2019 17:22:33 +0200 Subject: Remove redundant content from the contrib doc. Signed-off-by: Patrick Vacek --- CONTRIBUTING.adoc | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index efaccbb..6e1f219 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -1,15 +1,6 @@ = Contributing -We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent previous branches and welcome bug fixes and backports for those. Currently, the actively maintained branches are: - -* thud - -Previously, some older branches were also regularly supported, and while they should still be stable, they have not been updated or actively maintained for a while. These branches include: - -* sumo -* rocko -* pyro -* morty +We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent release branches and welcome bug fixes and backports for those. Please see the link:docs/modules/ROOT/pages/yocto-release-branches.adoc[release branches] documentation for the current list of support branches. If you are developing with meta-updater, it may be helpful to read the README and other documentation for link:README.adoc[this repo], https://github.com/advancedtelematic/aktualizr[aktualizr], and the https://github.com/advancedtelematic/updater-repo/[updater-repo], particularly the sections about development and debugging. -- cgit v1.2.3-54-g00ecf From 04567551cd386f57778ad08a803a1b0260c3faab Mon Sep 17 00:00:00 2001 From: Merlin Carter Date: Thu, 5 Sep 2019 15:42:59 +0200 Subject: OTA-3682: Remove the existing doc Removing the existing meta-updater doc so it can be moved into the aktualizr repo. Also updated README to point to same files in aktualizr repo. Signed-off-by: Merlin Carter --- CONTRIBUTING.adoc | 7 +- README.adoc | 24 ++++--- docs/antora.yml | 5 -- docs/modules/ROOT/nav.adoc | 17 ----- docs/modules/ROOT/pages/build.adoc | 62 ---------------- docs/modules/ROOT/pages/dev-config.adoc | 46 ------------ docs/modules/ROOT/pages/meta-updater-testing.adoc | 44 ------------ docs/modules/ROOT/pages/meta-updater-usage.adoc | 87 ----------------------- docs/modules/ROOT/pages/provisioning-methods.adoc | 22 ------ docs/modules/ROOT/pages/sota-variables.adoc | 44 ------------ docs/modules/ROOT/pages/supported-boards.adoc | 47 ------------ 11 files changed, 17 insertions(+), 388 deletions(-) delete mode 100644 docs/antora.yml delete mode 100644 docs/modules/ROOT/nav.adoc delete mode 100644 docs/modules/ROOT/pages/build.adoc delete mode 100644 docs/modules/ROOT/pages/dev-config.adoc delete mode 100644 docs/modules/ROOT/pages/meta-updater-testing.adoc delete mode 100644 docs/modules/ROOT/pages/meta-updater-usage.adoc delete mode 100644 docs/modules/ROOT/pages/provisioning-methods.adoc delete mode 100644 docs/modules/ROOT/pages/sota-variables.adoc delete mode 100644 docs/modules/ROOT/pages/supported-boards.adoc diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index 6e1f219..ffe0d73 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -1,8 +1,9 @@ = Contributing +:aktualizr-docsroot: https://github.com/advancedtelematic/aktualizr/tree/master/docs/ota-client-guide/modules/ROOT/pages/ -We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent release branches and welcome bug fixes and backports for those. Please see the link:docs/modules/ROOT/pages/yocto-release-branches.adoc[release branches] documentation for the current list of support branches. +We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent release branches and welcome bug fixes and backports for those. Please see the xref:{aktualizr-docsroot}yocto-release-branches.adoc[release branches] documentation for the current list of support branches. -If you are developing with meta-updater, it may be helpful to read the README and other documentation for link:README.adoc[this repo], https://github.com/advancedtelematic/aktualizr[aktualizr], and the https://github.com/advancedtelematic/updater-repo/[updater-repo], particularly the sections about development and debugging. +If you are developing with meta-updater, it may be helpful to read the README and other documentation for xref:README.adoc[this repo], https://github.com/advancedtelematic/aktualizr[aktualizr], and the link:https://github.com/advancedtelematic/updater-repo/[updater-repo], particularly the sections about development and debugging. == Developer Certificate of Origin (DCO) @@ -14,7 +15,7 @@ New pull requests will automatically be checked by the https://probot.github.io/ * OTA-enabled build succeeds for at least one platform, the resulting image boots, and an update can be installed. This check is absolutely necessary for every pull request unless it only touches documentation. * If your change touches platform code (like `classes/sota_.bbclass`), please check building and updating on this particular platform. -* oe-selftest succeeds. To test meta-updater, run `oe-selftest -r updater` from a build directory with `MACHINE` set to `qemux86-64`. See the link:README.adoc#qa-with-oe-selftest[relevant section of the README] for more details. +* oe-selftest succeeds. To test meta-updater, run `oe-selftest -r updater` from a build directory with `MACHINE` set to `qemux86-64`. See the link:{aktualizr-docsroot}meta-updater-testing.adoc#qa-with-oe-selftest[relevant section of the README] for more details. * Updates are forwards- and backwards-compatible. You should be able to update an OTA-enabled build before the change is applied to the version with change applied and vice versa. One should pay double attention to the compatibility when bootloader code is affected. * The patch/branch should be based on the latest version of the target branch. This may mean that rebasing is necessary if other PRs are merged before yours is approved. diff --git a/README.adoc b/README.adoc index 97b9987..af3d2ff 100644 --- a/README.adoc +++ b/README.adoc @@ -1,9 +1,7 @@ = meta-updater :toc: macro :toc-title: -:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master/ - -ifndef::env-github[:meta-updater-github-url:] +:aktualizr-docsroot: https://github.com/advancedtelematic/aktualizr/tree/master/docs/ota-client-guide/modules/ROOT/pages/ Meta-updater is a link:https://www.yoctoproject.org/software-overview/layers/[Yocto layer] that enables over-the-air updates (OTA) with https://github.com/ostreedev/ostree[OSTree] and https://github.com/advancedtelematic/aktualizr[Aktualizr] -- the default client for link:https://www.here.com/products/automotive/ota-technology[HERE OTA Connect]. @@ -15,36 +13,40 @@ https://github.com/advancedtelematic/aktualizr[Aktualizr] (and https://github.co == Table of Contents The following documentation focuses on tasks that involve the meta-updater layer. If you want to get an idea of the overall developer workflow in OTA Connect, see the link:https://docs.ota.here.com/ota-client/dev/index.html[OTA Connect Developer Guide]. +[NOTE] +==== +The following links point to files in the aktualizr repository where the source of the developer guide is stored. +==== -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/build.adoc[Build] +* xref:{aktualizr-docsroot}meta-updater-build.adoc[Build] + Learn how to use this layer to build a basic disk image and add it to your own Yocto project. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/supported-boards.adoc[Supported boards] +* xref:{aktualizr-docsroot}supported-boards.adoc[Supported boards] + Find out if your board is supported and learn about the minimum hardware requirements. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/sota-variables.adoc[SOTA-related variables in local.conf] +* xref:{aktualizr-docsroot}sota-variables.adoc[SOTA-related variables in local.conf] + Learn how to configure OTA-related functionality when building disk images. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-usage.adoc[Usage] +* xref:{aktualizr-docsroot}meta-updater-usage.adoc[Usage] + Learn about the `garage-push` and `garage-sign` utilities, aktualizr configuration and service resource control, and OSTree. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/dev-config.adoc[Development configuration] +* xref:{aktualizr-docsroot}meta-updater-dev-config.adoc[Development configuration] + Learn how to configure logging, install custom versions of aktualizr, and override the version indicator for sofware updates. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-testing.adoc#_qa_with_oe_selftest[QA with oe-selftest] +* xref:{aktualizr-docsroot}meta-updater-testing.adoc#_qa_with_oe_selftest[QA with oe-selftest] + Learn how to use the `oe-selftest` framework for quality assurance. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/meta-updater-testing.adoc#_aktualizr_test_suite_with_ptest[Aktualizr test suite with ptest] +* xref:{aktualizr-docsroot}meta-updater-testing.adoc#_aktualizr_test_suite_with_ptest[Aktualizr test suite with ptest] + Learn how to enable Yocto's package test functionality and run parts of the aktualizr test suite. + -* xref:{meta-updater-github-url}docs/modules/ROOT/pages/provisioning-methods.adoc[Provisoning methods] +* xref:{aktualizr-docsroot}meta-updater-provisioning-methods.adoc[Provisoning methods] + Learn how to enable different methods for provisioning devices. diff --git a/docs/antora.yml b/docs/antora.yml deleted file mode 100644 index 5ed1239..0000000 --- a/docs/antora.yml +++ /dev/null @@ -1,5 +0,0 @@ -name: ota-build -title: OTA Connect Build Tools -version: dev -nav: -- modules/ROOT/nav.adoc diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc deleted file mode 100644 index d4b577b..0000000 --- a/docs/modules/ROOT/nav.adoc +++ /dev/null @@ -1,17 +0,0 @@ -// MC: NOTE ABOUT TOC -// Adding "pageroot" attr so that TOC that will also work directly in GitHub. Because... -// In Antora the "pages" subdir is implcit added to the xref path at build time. -// if you add "/pages" Antora will intepret it as "pages/pages". -// The pages subdir is NOT implicit when viewing source files in Github. - -ifdef::env-github[:pageroot: pages/] -ifndef::env-github[:pageroot:] - -.Guide to the Build Tools -* xref:{pageroot}metaupdater-whatis.adoc[What are the build tools?] -* xref:{pageroot}build.adoc[Build a disk image] -* xref:{pageroot}supported-boards.adoc[Supported Boards] -* xref:{pageroot}meta-updater-usage.adoc[How to] -* xref:{pageroot}sota-variables.adoc[Configuration reference] -* xref:{pageroot}dev-config.adoc[Development configuration] -* xref:{pageroot}meta-updater-testing.adoc[Testing] \ No newline at end of file diff --git a/docs/modules/ROOT/pages/build.adoc b/docs/modules/ROOT/pages/build.adoc deleted file mode 100644 index 135d468..0000000 --- a/docs/modules/ROOT/pages/build.adoc +++ /dev/null @@ -1,62 +0,0 @@ -= Build -:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master - -== Quickstart - -If you don't already have a Yocto project that you want to add OTA to, you can use the xref:dev@getstarted::raspberry-pi.adoc[HERE OTA Connect Quickstart] project to rapidly get up and running on a Raspberry Pi. It takes a standard https://www.yoctoproject.org/tools-resources/projects/poky[poky] distribution, and adds OTA and OSTree capabilities. - -== Dependencies - -//MC: TOMERGE: These "dependencies" mostly just duplicates the prerequisite sections: https://main.gitlab.in.here.com/olp/edge/ota/documentation/ota-connect-docs/blob/master/docs/getstarted/modules/ROOT/pages/raspberry-pi.adoc - -In addition to the link:https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-packages-for-the-build-host[standard Yocto dependencies], meta-updater generally requires a few additional dependencies, depending on your use case and target platform. To install these additional packages on Debian/Ubuntu, run this: - -.... -sudo apt install cpu-checker default-jre parted -.... - -To build for https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] with GRUB, you will also need to install https://github.com/tianocore/tianocore.github.io/wiki/OVMF[TianoCore's ovmf] package on your host system. On Debian/Ubuntu, you can do so with this command: - -.... -sudo apt install ovmf -.... - -== Adding meta-updater capabilities to your build - -// MC: TOMERGE: This content mosty duplicates https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc - -If you already have a Yocto-based project and you want to add atomic filesystem updates to it, you just need to do three things: - -1. Clone the `meta-updater` layer and add it to your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[bblayers.conf]. -2. Clone BSP integration layer (`meta-updater-$\{PLATFORM}`, e.g. https://github.com/advancedtelematic/meta-updater-raspberrypi[meta-updater-raspberrypi]) and add it to your `conf/bblayers.conf`. If your board isn't supported yet, you could write a BSP integration for it yourself. See the <> section for the details. -3. Set up your https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-DISTRO[distro]. If you are using "poky", the default distro in Yocto, you can change it in your `conf/local.conf` to "poky-sota". Alternatively, if you are using your own or third party distro configuration, you can add `INHERIT += " sota"` to it, thus combining capabilities of your distro with meta-updater features. - -You can then build your image as usual, with bitbake. After building the root file system, bitbake will then create an https://ostree.readthedocs.io/en/latest/manual/adapting-existing/[OSTree-enabled version] of it, commit it to your local OSTree repo and (optionally) push it to a remote server. Additionally, a live disk image will be created (normally named `$\{IMAGE_NAME}.-sdimg-ota` e.g. `core-image-raspberrypi3.rpi-sdimg-ota`). You can control this behaviour through <>. - -== Build in AGL - -// MC: TOMERGE: This content duplicates https://main.gitlab.in.here.com/olp/edge/ota/documentation/ota-connect-docs/blob/master/docs/getstarted/modules/ROOT/pages/automotive-grade-linux.adoc (except that it is a lot sparser) - -With AGL you can just add agl-sota feature while configuring your build environment: - -.... -source meta-agl/scripts/aglsetup.sh -m porter agl-demo agl-appfw-smack agl-devel agl-sota -.... - -You can then run: - -.... -bitbake agl-demo-platform -.... - -and get as a result an `ostree_repo` folder in your images directory (`tmp/deploy/images/$\{MACHINE}/ostree_repo`). It will contain: - -* your OSTree repository, with the rootfs committed as an OSTree deployment, -* an `ota-ext4` bootstrap image, which is an OSTree physical sysroot as a burnable filesystem image, and optionally -* some machine-dependent live images (e.g. `.wic` for Raspberry Pi or `.porter-sdimg-ota` for Renesas Porter board). - -Although `aglsetup.sh` hooks provide reasonable defaults for SOTA-related variables, you may want to tune some of them. - -== Build problems - -Ubuntu users that encounter an error due to missing `Python.h` should install `libpython2.7-dev` on their host machine. diff --git a/docs/modules/ROOT/pages/dev-config.adoc b/docs/modules/ROOT/pages/dev-config.adoc deleted file mode 100644 index 60002a5..0000000 --- a/docs/modules/ROOT/pages/dev-config.adoc +++ /dev/null @@ -1,46 +0,0 @@ -= Development configuration -:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master - -//MC: The dev guide already has a recommended config topic: https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/recommended-clientconfig.adoc -// This content pretty much serves the same purpose except 'local.conf' instead of 'sota_conf.toml' Clean this up and use an :include: ref reuse in that topic? - -== Logging - -To troubleshoot problems that you might encounter during development, we recommend that you enable persistent `systemd` logging. This setting is enabled by default for newly configured environments (see link:{meta-updater-github-url}/conf/local.conf.sample.append[]). To enable it manually, put this to your `local.conf`: - -.... -IMAGE_INSTALL_append += " systemd-journald-persistent" -.... - -It may also be helpful to run with debug logging enabled in aktualizr. To do so, add this to your `local.conf`: - -.... -IMAGE_INSTALL_append += " aktualizr-log-debug" -.... - -== Custom aktualizr versions - -You can override the version of aktualizr included in your image. This requires that the version you wish to run is pushed to the https://github.com/advancedtelematic/aktualizr[aktualizr github repo]. You can then use these settings in your `local.conf` to simplify the development process: - -[options="header"] -|====================== -| Option | Effect -| `require classes/sota_bleeding.inc` | Build the latest head (by default, using the master branch) of Aktualizr -| `BRANCH_pn-aktualizr = "mybranch"` - -`BRANCH_pn-aktualizr-native = "mybranch"` | Build `mybranch` of Aktualizr. Note that both of these need to be set. This is normally used in conjunction with `require classes/sota_bleeding.inc` -| `SRCREV_pn-aktualizr = "1004efa3f86cef90c012b34620992b5762b741e3"` - -`SRCREV_pn-aktualizr-native = "1004efa3f86cef90c012b34620992b5762b741e3"` | Build the specified revision of Aktualizr. Note that both of these need to be set. This can be used in conjunction with `BRANCH_pn-aktualizr` and `BRANCH_pn-aktualizr-native` but will conflict with `require classes/sota_bleeding.inc` -| `TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake "` | Use with `bitbake -c populate_sdk core-image-minimal` to build an SDK. See the https://github.com/advancedtelematic/aktualizr#developing-against-an-openembedded-system[aktualizr repo] for more information. -|====================== - -== Overriding target version -*Warning: overriding target version is a dangerous operation, make sure you understand this section completely before doing it.* - -Every time you build an image with `SOTA_PACKED_CREDENTIALS` set, a new entry in your Uptane metadata is created and you can see it in the OTA Garage UI if you're using one. Normally this version will be equal to OSTree hash of your root file system. If you want it to be different though you can override is using one of two methods: - -1. Set `GARAGE_TARGET_VERSION` variable in your `local.conf`. -2. Write a recipe or a bbclass to write the desired version to `${STAGING_DATADIR_NATIVE}/target_version`. An example of such bbclass can be found in `classes/target_version_example.bbclass`. - -Please note that [target name, target version] pairs are expected to be unique in the system. If you build a new target with the same target version as a previously built one, the old package will be overwritten on the update server. It can have unpredictable effect on devices that have this version installed, and it is not guaranteed that information will be reported correctly for such devices or that you will be able to update them (we're doing our best though). The easiest way to avoid problems is to make sure that your overriding version is as unique as an OSTree commit hash. diff --git a/docs/modules/ROOT/pages/meta-updater-testing.adoc b/docs/modules/ROOT/pages/meta-updater-testing.adoc deleted file mode 100644 index 1e20c87..0000000 --- a/docs/modules/ROOT/pages/meta-updater-testing.adoc +++ /dev/null @@ -1,44 +0,0 @@ -= Testing - -//MC: No overlap with any content currently in the developer guide, but probably useful content to clean up and include. - -== QA with oe-selftest - -This layer relies on the test framework oe-selftest for quality assurance. Currently, you will need to run this in a build directory with `MACHINE` set to `qemux86-64`. Follow the steps below to run the tests: - -1. Append the line below to `conf/local.conf` to disable the warning about supported operating systems: -+ -``` -SANITY_TESTED_DISTROS = "" -``` - -2. If your image does not already include an ssh daemon such as dropbear or openssh, add this line to `conf/local.conf` as well: -+ -``` -IMAGE_INSTALL_append = " dropbear " -``` - -3. Some tests require that `SOTA_PACKED_CREDENTIALS` is set in your `conf/local.conf`. See the xref:dev@ota-build::sota-variables.adoc[SOTA-related variables in local.conf]. - -4. To be able to build an image for the GRUB tests, you will need to install the `ovmf` package as described in the xref:dev@ota-build::build.adoc#_dependencies[dependencies section]. - -5. Run oe-selftest: -+ -``` -oe-selftest -r updater_native updater_qemux86_64 updater_minnowboard updater_raspberrypi updater_qemux86_64_ptest -``` - -For more information about oe-selftest, including details about how to run individual test modules or classes, please refer to the https://wiki.yoctoproject.org/wiki/Oe-selftest[Yocto Project wiki]. - -== Aktualizr test suite with ptest - -The meta-updater layer includes support for running parts of the aktualizr test suite on deployed devices through link:https://wiki.yoctoproject.org/wiki/Ptest[Yocto's ptest functionality]. Since it adds significant build time cost, it is currently disabled by default. To enable it, add the following to your `conf/local.conf`: - -``` -PTEST_ENABLED_pn-aktualizr = "1" -IMAGE_INSTALL_append += " aktualizr-ptest ptest-runner " -``` - -Be aware that it will add several hundreds of MB to the generated file system. - -The aktualizr tests will now be part of the deployed ptest suite, which can be run by calling `ptest-runner`. Alternatively, the required files and run script can be found in `/usr/lib/aktualizr/ptest`. diff --git a/docs/modules/ROOT/pages/meta-updater-usage.adoc b/docs/modules/ROOT/pages/meta-updater-usage.adoc deleted file mode 100644 index cc53a9f..0000000 --- a/docs/modules/ROOT/pages/meta-updater-usage.adoc +++ /dev/null @@ -1,87 +0,0 @@ -= Usage -:meta-updater-github-url: https://github.com/advancedtelematic/meta-updater/tree/master -:metadata-expiry-article: xref:dev@ota-client::metadata-expiry.adoc[OTA Connect documentation] -ifdef::env-github[:metadata-expiry-article: link:https://docs.ota.here.com/ota-client/dev/metadata-expiry.html[OTA Connect documentation]] - -//MC: No overlap with any content currently in the developer guide, but probably useful content to clean up and include. eg: use cases. - -== OSTree - -OSTree used to include a simple HTTP server as part of the ostree binary, but this has been removed in more recent versions. However, OSTree repositories are self-contained directories, and can be trivially served over the network using any HTTP server. For example, you could use Python's SimpleHTTPServer: - -.... -cd tmp/deploy/images/qemux86-64/ostree_repo -python -m SimpleHTTPServer # port defaults to 8000 -.... - -You can then run ostree from inside your device by adding your repo: - -.... -# This behaves like adding a Git remote; you can name it anything -ostree remote add --no-gpg-verify my-remote http://: - -# If OSTREE_BRANCHNAME is set in local.conf, that will be the name of the -# branch. If not set, it defaults to the value of MACHINE (e.g. qemux86-64). -ostree pull my-remote - -# poky is the OS name as set in OSTREE_OSNAME -ostree admin deploy --os=poky my-remote: -.... - -After restarting, you will boot into the newly deployed OS image. - -For example, on the raspberry pi you can try this sequence: - -.... -# add remote -ostree remote add --no-gpg-verify agl-snapshot https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/images/raspberrypi3/ostree_repo/ agl-ota - -# pull -ostree pull agl-snapshot agl-ota - -# deploy -ostree admin deploy --os=agl agl-snapshot:agl-ota -.... - -== garage-push - -The https://github.com/advancedtelematic/aktualizr[aktualizr repo] contains a tool, garage-push, which lets you push the changes in OSTree repository generated by bitbake process. It communicates with an http server capable of querying files with HEAD requests and uploading them with POST requests. In particular, this can be used with https://connect.ota.here.com/[HERE OTA Connect]. garage-push is used as follows: - -.... -garage-push --repo=/path/to/ostree-repo --ref=mybranch --credentials=/path/to/credentials.zip -.... - -You can set `SOTA_PACKED_CREDENTIALS` in your `local.conf` to automatically synchronize your build results with a remote server. Credentials are stored in an archive as described in the xref:dev@ota-client::provisioning-methods-and-credentialszip.adoc[aktualizr documentation]. - -== aktualizr configuration - -https://github.com/advancedtelematic/aktualizr[Aktualizr] supports a variety of xref:dev@ota-client::aktualizr-config-options.adoc[configuration options via a configuration file and the command line]. There are two primary ways to control aktualizr's configuration from meta-updater. - -First, you can set `SOTA_CLIENT_PROV` to control which provisioning recipe is used. Each recipe installs an appropriate `sota.toml` file from aktualizr according to the provisioning needs. See the xref:dev@ota-build::sota-variables.adoc[SOTA-related variables in local.conf] section for more information. - -Second, you can write recipes to install additional config files with customized options. A few recipes already exist to address common needs and provide an example: - -* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-auto-reboot.bb[aktualizr-auto-reboot.bb] configures aktualizr to automatically reboot after new updates are installed in order to apply the updates immediately. This is only relevant for package managers (such as OSTree) that require a reboot to complete the installation process. If this is not enabled, you will need to reboot the system through other means. -* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-disable-send-ip.bb[aktualizr-disable-send-ip.bb] disables the reporting of networking information to the server. This is enabled by default and supported by https://connect.ota.here.com/[HERE OTA Connect]. However, if you are using a different server that does not support this feature, you may want to disable it in aktualizr. -* link:{meta-updater-github-url}/recipes-sota/config/aktualizr-log-debug.bb[aktualizr-log-debug.bb] sets the log level of aktualizr to 0 (trace). The default is 2 (info). This recipe is intended for development and debugging purposes. - -To use these recipes, you will need to add them to your image with a line such as `IMAGE_INSTALL_append = " aktualizr-log-debug "` in your `local.conf`. - -== aktualizr service resource control - -With systemd based images, it is possible to set resource policies for the aktualizr service. The main use case is to provide a safeguard against resource exhaustion during an unforeseen failure scenario. - -To enable it, install `aktualizr-resource-control` on the target image and optionally override the default resource limits set in link:{meta-updater-github-url}/recipes-sota/aktualizr/aktualizr_git.bb[aktualizr_git.bb], from your `local.conf`. - -For example: - -.... -IMAGE_INSTALL_append += " aktualizr-resource-control " -RESOURCE_CPU_WEIGHT_pn-aktualizr = "50" -.... - -=== garage-sign configuration - -The https://github.com/advancedtelematic/ota-tuf/tree/master/cli[garage-sign] tool can be configured with variables described in the xref:sota-variables.adoc[SOTA-related variables in local.conf] section. - -Of particular importance is controlling the expiration of the Targets metadata signed with garage-sign. This is described in detail in the {metadata-expiry-article}. To set a manual expiration date, you can use either of the variables `GARAGE_TARGET_EXPIRES` or `GARAGE_TARGET_EXPIRE_AFTER`. Both cannot be supplied simultaneously. If neither are provided, a default of one month will be used. \ No newline at end of file diff --git a/docs/modules/ROOT/pages/provisioning-methods.adoc b/docs/modules/ROOT/pages/provisioning-methods.adoc deleted file mode 100644 index 0f9051e..0000000 --- a/docs/modules/ROOT/pages/provisioning-methods.adoc +++ /dev/null @@ -1,22 +0,0 @@ -= Manual provisioning - -//MC: TOMERGE: Looks mostly like a duplicate of this topic: https://github.com/advancedtelematic/aktualizr/blob/master/docs/ota-client-guide/modules/ROOT/pages/simulate-device-cred-provtest.adoc - -As described in the xref:xref:dev@ota-build::sota-variables.adoc[configuration reference], you can set `SOTA_DEPLOY_CREDENTIALS` to `0` to prevent deploying credentials to the built `wic` image. In this case you get a generic image that you can use e.g. on a production line to flash a series of devices. The cost of this approach is that this image is half-baked and should be provisioned before it can connect to the backend. - -Provisioning procedure depends on your provisioning recipe, i.e. the value of `SOTA_CLIENT_PROV` (equal to `aktualizr-shared-prov` by default): - -* For `aktualizr-shared-prov` put your `credentials.zip` to `/var/sota/sota_provisioning_credentials.zip` on the filesystem of a running device. If you have the filesystem of our device mounted to your build machine, prefix all paths with `/ostree/deploy/poky` as in `/ostree/deploy/poky/var/sota/sota_provisioning_credentials.zip`. -* For `aktualizr-device-prov` -** put URL to the backend server (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. -** put client certificate, private key and root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/client.pem`, `/var/sota/import/pkey.pem` and `/var/sota/import/root.crt` respectively. -* For `aktualizr-device-prov-hsm` -** put URL to the server backend (together with protocol prefix and port number) at `/var/sota/gateway.url`. If you're using HERE OTA Connect, you can find the URL in the `autoprov.url` file in your credentials archive. -** put root CA certificate (for the *server*, not for the *device*) at `/var/sota/import/root.crt`. -** put client certificate and private key to slots 1 and 2 of the PKCS#11-compatible device. - -For more extensive information on provisioning methods, see the following topics from the OTA Connect Developer guide: - -//MC: Web links because this topic is only viewable in Github -* link:https://docs.ota.here.com/ota-client/dev/client-provisioning-methods.html[Device provisioning methods] -* link:https://docs.ota.here.com/ota-client/dev/enable-device-cred-provisioning.html[Enable device-credential provisioning and install device certificates] diff --git a/docs/modules/ROOT/pages/sota-variables.adoc b/docs/modules/ROOT/pages/sota-variables.adoc deleted file mode 100644 index 7614a8a..0000000 --- a/docs/modules/ROOT/pages/sota-variables.adoc +++ /dev/null @@ -1,44 +0,0 @@ -= Build Configuration Options -:page-partial: -// MC: Included in aktualizr/docs/ota-client-guide/modules/ROOT/pages/build-configuration.adoc - -.OTA-related options for building disk images -[cols="1,2a",options="header"] -|==================== -| Option | Description -| `OSTREE_BRANCHNAME`|OSTree branch name. Defaults to `${SOTA_HARDWARE_ID}`. Particularly useful for grouping similar images. -| `OSTREE_REPO`|Path to your OSTree repository. Defaults to `$\{DEPLOY_DIR_IMAGE}/ostree_repo` -| `OSTREE_OSNAME`|OS deployment name on your target device. For more information about deployments and osnames see the https://ostree.readthedocs.io/en/latest/manual/deployment/[OSTree documentation]. Defaults to "poky". -| `OSTREE_COMMIT_BODY`|Message attached to OSTree commit. Empty by default. -| `OSTREE_COMMIT_SUBJECT`|Commit subject used by OSTree. Defaults to `Commit-id: ${IMAGE_NAME}` -| `OSTREE_UPDATE_SUMMARY`|Set this to '1' to update summary of OSTree repository on each commit. '0' by default. -| `OSTREE_DEPLOY_DEVICETREE`|Set this to '1' to include devicetree(s) to boot -| `GARAGE_SIGN_AUTOVERSION`|Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. -| `GARAGE_TARGET_URL` | Sets the `--url` parameter of `garage-sign targets add`, which sets a custom URL for the Image repository targets. -| `GARAGE_TARGET_EXPIRES` | Sets the `--expires` parameter of `garage-sign targets sign`. Format is a UTC instant such as '2018-01-01T00:01:00Z'. -ifndef::env-github[] -[NOTE] -==== -Currently, this only works when using the master branch of meta-updater. -==== -endif::[] -| `GARAGE_TARGET_EXPIRE_AFTER` | Sets the `--expire-after` parameter of `garage-sign targets sign`. Format is in years, months, and days (each optional, but in that order), such as '1Y3M5D'. -ifndef::env-github[] -[NOTE] -==== -Currently, this only works when using the master branch of meta-updater. -==== -endif::[] -| `INITRAMFS_IMAGE`|The initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such a proxy. -| `SOTA_PACKED_CREDENTIALS`|When set, your ostree commit will be pushed to a remote repo as a bitbake step. This should be the path to a zipped credentials file in xref:dev@ota-build::provisioning-methods-and-credentialszip.adoc[the format accepted by garage-push]. -| `SOTA_DEPLOY_CREDENTIALS`|When set to '1' (default value), deploys credentials to the built image. Override it in `local.conf` to built a generic image that can be provisioned manually after the build. -| `SOTA_CLIENT_PROV`|Which provisioning method to use. Valid options are `aktualizr-shared-prov`, `aktualizr-device-prov`, and `aktualizr-device-prov-hsm`. For more information on these provisioning methods, see the xref:dev@ota-client::client-provisioning-methods.adoc[OTA Connect documentation]. The default is `aktualizr-shared-prov`. This can also be set to an empty string to avoid using a provisioning recipe. -| `SOTA_CLIENT_FEATURES`|Extensions to aktualizr. The only valid options are `hsm` (to build with HSM support) and `secondary-network` (to set up a simulated 'in-vehicle' network with support for a primary node with a DHCP server and a secondary node with a DHCP client). -| `SOTA_SECONDARY_CONFIG`|A file containing JSON configuration for secondaries. It will be installed into `/etc/sota/ecus` on the device and automatically provided to aktualizr. See xref:dev@ota-client::posix-secondaries-bitbaking.adoc[here] for more details. -| `SOTA_HARDWARE_ID`|A custom hardware ID that will be written to the aktualizr config. Defaults to MACHINE if not set. -| `SOTA_MAIN_DTB`|The base device tree to use with the kernel. Used together with FIT images. You can change it, and the device tree will also be changed after the update. -| `SOTA_DT_OVERLAYS`|A whitespace-separated list of used device tree overlays for FIT image. This list is OSTree-updateable as well. -| `SOTA_EXTRA_CONF_FRAGS`|Extra https://lxr.missinglinkelectronics.com/uboot/doc/uImage.FIT/overlay-fdt-boot.txt[configuration fragments] for FIT image. -| `RESOURCE_xxx_pn-aktualizr`|Controls maximum resource usage of the aktualizr service, when `aktualizr-resource-control` is installed on the image. See xref:dev@ota-build::meta-updater-usage.adoc#_aktualizr_service_resource_control[aktualizr service resource control] for details. -| `SOTA_POLLING_SEC`|Sets polling interval for aktualizr to check for updates if aktualizr-polling-interval is included in the image. -|==================== \ No newline at end of file diff --git a/docs/modules/ROOT/pages/supported-boards.adoc b/docs/modules/ROOT/pages/supported-boards.adoc deleted file mode 100644 index 3c7e3f9..0000000 --- a/docs/modules/ROOT/pages/supported-boards.adoc +++ /dev/null @@ -1,47 +0,0 @@ -= Supported boards -:page-partial: -// MC: Included in aktualizr/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc -Currently supported platforms are: - -* https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi 2 and 3] -* https://github.com/advancedtelematic/meta-updater-minnowboard[Intel Minnowboard] -* https://github.com/advancedtelematic/meta-updater-qemux86-64[Native QEMU emulation] -* Renesas R-Car H3 and M3 -* https://github.com/advancedtelematic/meta-updater-ti/[TI BeagleBone Black] (rocko only, using TI SDK 05.03) -* https://github.com/advancedtelematic/meta-updater-ti/[TI AM65x industrial development kit] (rocko only, using TI SDK 05.03) - -Additionally, there is community support for https://github.com/ricardosalveti/meta-updater-riscv[RISC-V] boards, in particular the Freedom U540. - -We also historically supported the https://github.com/advancedtelematic/meta-updater-porter[Renesas Porter] board. - -== Adding support for your board - -If your board isn't supported yet, you can add board integration code yourself. The main purpose of this code is to provide a bootloader that will be able to use https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/[OSTree's boot directory]. In the meta-updater integration layers we have written so far, the basic steps are: - -1. Make the board boot into http://www.denx.de/wiki/U-Boot[U-Boot] -2. Make U-boot import variables from /boot/loader/uEnv.txt and load the kernel with initramfs and kernel command line arguments according to what is set in this file. - -Take a look at the https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] or https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi] integration layers for examples. - -If you want our developers to add support for your board, contact us at mailto:otaconnect.support@here.com[] and we can discuss a potential NRE (Non-recurring Engineering) agreement. - -[NOTE] -==== -Although we have focused on U-Boot and GRUB so far, other bootloaders can be configured to work with OSTree as well. If you want to use a different bootloader, contact us at mailto:otaconnect.support@here.com[]. -==== - -Your images will also need network connectivity to be able to reach an actual OTA backend. Our 'poky-sota' distribution does not mandate or install a default network manager but our supported platforms use the `virtual/network-configuration` recipe, which can be used as a starting example. - -== Minimum hardware requirements for controllers (ECUs) - -The aktualizr binary is a lightweight {cpp} application between 2-5 MB in size. It uses a minimum amount of resources when idle. - -The following hardware is required for your primary ECU: - -* At a minimum, aktualizr needs **16 MB of RAM** and **128 MB of storage** to run. -* We recommend that you use a controller with **128 MB of RAM** and **512 MB storage** -- especially if you if your plan to process large, complex sofware updates. - -[NOTE] -==== -If you plan to send updates to secondary, low-performance ECUs, you can also use a more minimal implementaton called link:https://github.com/advancedtelematic/aktualizr/tree/master/partial/libuptiny[`libuptiny`]. This utility is only 10 KB and performs a minimal verification of software metadata that is less resource intensive. For more information on `libuptiny`, contact us at mailto:otaconnect.support@here.com[]. -==== -- cgit v1.2.3-54-g00ecf From e5478daf9f678f7281fe9cf7c211fc57eba65585 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Thu, 5 Sep 2019 16:29:30 +0200 Subject: Fix typo. Signed-off-by: Patrick Vacek --- CONTRIBUTING.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index ffe0d73..24916cc 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -1,7 +1,7 @@ = Contributing :aktualizr-docsroot: https://github.com/advancedtelematic/aktualizr/tree/master/docs/ota-client-guide/modules/ROOT/pages/ -We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent release branches and welcome bug fixes and backports for those. Please see the xref:{aktualizr-docsroot}yocto-release-branches.adoc[release branches] documentation for the current list of support branches. +We welcome pull requests from anyone. The master branch is the primary branch for development, and if you wish to add new functionality, it probably belongs there. We attempt to maintain recent release branches and welcome bug fixes and backports for those. Please see the xref:{aktualizr-docsroot}yocto-release-branches.adoc[release branches] documentation for the current list of supported branches. If you are developing with meta-updater, it may be helpful to read the README and other documentation for xref:README.adoc[this repo], https://github.com/advancedtelematic/aktualizr[aktualizr], and the link:https://github.com/advancedtelematic/updater-repo/[updater-repo], particularly the sections about development and debugging. -- cgit v1.2.3-54-g00ecf From b81f7958398b7de2e317808c35a3717e6e027eba Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Thu, 5 Sep 2019 17:17:05 +0200 Subject: Restore basic doc about getting started and dependencies. Signed-off-by: Patrick Vacek --- README.adoc | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/README.adoc b/README.adoc index af3d2ff..787aaf6 100644 --- a/README.adoc +++ b/README.adoc @@ -9,6 +9,24 @@ https://github.com/ostreedev/ostree[OSTree] is a tool for atomic full file syste https://github.com/advancedtelematic/aktualizr[Aktualizr] (and https://github.com/advancedtelematic/rvi_sota_client[RVI SOTA client]) add authentication and provisioning capabilities to OTA and are integrated with OSTree. You can connect with these open-source applications or sign up for a free account at https://connect.ota.here.com/[HERE OTA Connect] to get started. +== Quickstart + +If you don't already have a Yocto project that you want to add OTA to, you can use the xref:dev@getstarted::raspberry-pi.adoc[HERE OTA Connect Quickstart] project to rapidly get up and running on a Raspberry Pi. It takes a standard https://www.yoctoproject.org/tools-resources/projects/poky[poky] distribution, and adds OTA and OSTree capabilities. + +== Dependencies + +In addition to the link:https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-packages-for-the-build-host[standard Yocto dependencies], meta-updater generally requires a few additional dependencies, depending on your use case and target platform. To install these additional packages on Debian/Ubuntu, run this: + +.... +sudo apt install cpu-checker default-jre parted +.... + +To build for https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] with GRUB, you will also need to install https://github.com/tianocore/tianocore.github.io/wiki/OVMF[TianoCore's ovmf] package on your host system. On Debian/Ubuntu, you can do so with this command: + +.... +sudo apt install ovmf +.... + [discrete] == Table of Contents -- cgit v1.2.3-54-g00ecf From 91194567bc621fcc1b95a421435b11c747b38d0f Mon Sep 17 00:00:00 2001 From: Merlin Carter Date: Fri, 6 Sep 2019 10:45:40 +0200 Subject: fixing broken link Signed-off-by: Merlin Carter --- README.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.adoc b/README.adoc index 787aaf6..12e0446 100644 --- a/README.adoc +++ b/README.adoc @@ -44,7 +44,7 @@ Learn how to use this layer to build a basic disk image and add it to your own Y + Find out if your board is supported and learn about the minimum hardware requirements. + -* xref:{aktualizr-docsroot}sota-variables.adoc[SOTA-related variables in local.conf] +* xref:{aktualizr-docsroot}build-configuration.adoc[SOTA-related variables in local.conf] + Learn how to configure OTA-related functionality when building disk images. + -- cgit v1.2.3-54-g00ecf From 81c124178e950cd756d8effb72c19505b7651727 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Fri, 6 Sep 2019 16:42:37 +0200 Subject: Copy the image and U-Boot rom when using overlays. Since bitbake can remove old images that an overlay was non-obviously dependent on, the safest thing to do is make a copy of the image and keep it alongside the overlay. When using the overlay later, automatically use that image. Also do the same thing with the U-Boot rom. This should also make moving the overlay file to another machine much easier. Signed-off-by: Patrick Vacek --- scripts/qemucommand.py | 50 ++++++++++++++++++++++++++++++++++++++++++-------- scripts/run-qemu-ota | 2 +- 2 files changed, 43 insertions(+), 9 deletions(-) diff --git a/scripts/qemucommand.py b/scripts/qemucommand.py index a869d4d..9b23c54 100644 --- a/scripts/qemucommand.py +++ b/scripts/qemucommand.py @@ -2,6 +2,7 @@ from os.path import exists, isdir, join, realpath, abspath from os import listdir import random import socket +from shutil import copyfile from subprocess import check_output EXTENSIONS = { @@ -39,6 +40,8 @@ def random_mac(): class QemuCommand(object): def __init__(self, args): + self.dry_run = args.dry_run + self.overlay = args.overlay if args.machine: self.machine = args.machine else: @@ -49,21 +52,53 @@ class QemuCommand(object): self.machine = machines[0] else: raise ValueError("Could not autodetect machine type. More than one entry in %s. Maybe --machine qemux86-64?" % args.dir) + + # If using an overlay with U-Boot, copy the rom when we create the + # overlay so that we can keep it around just in case. if args.efi: self.bios = 'OVMF.fd' else: - uboot = abspath(join(args.dir, self.machine, 'u-boot-qemux86-64.rom')) - if not exists(uboot): - raise ValueError("U-Boot image %s does not exist" % uboot) - self.bios = uboot + uboot_path = abspath(join(args.dir, self.machine, 'u-boot-qemux86-64.rom')) + if self.overlay: + new_uboot_path = self.overlay + '.u-boot.rom' + if not exists(self.overlay): + if not exists(uboot_path): + raise ValueError("U-Boot image %s does not exist" % uboot_path) + if not exists(new_uboot_path): + if self.dry_run: + print("cp %s %s" % (uboot_path, new_uboot_path)) + else: + copyfile(uboot_path, new_uboot_path) + uboot_path = new_uboot_path + if not exists(uboot_path) and not (self.dry_run and not exists(self.overlay)): + raise ValueError("U-Boot image %s does not exist" % uboot_path) + self.bios = uboot_path + + # If using an overlay, we need to keep the "backing" image around, as + # bitbake will often clean it up, and the overlay silently depends on + # the hardcoded path. The easiest solution is to keep the file and use + # a relative path to it. if exists(args.imagename): - image = args.imagename + image = realpath(args.imagename) else: ext = EXTENSIONS.get(self.machine, 'wic') image = join(args.dir, self.machine, '%s-%s.%s' % (args.imagename, self.machine, ext)) - self.image = realpath(image) - if not exists(self.image): + if self.overlay: + new_image_path = self.overlay + '.img' + if not exists(self.overlay): + if not exists(image): + raise ValueError("OS image %s does not exist" % image) + if not exists(new_image_path): + if self.dry_run: + print("cp %s %s" % (image, new_image_path)) + else: + copyfile(image, new_image_path) + self.image = new_image_path + else: + self.image = realpath(image) + if not exists(self.image) and not (self.dry_run and not exists(self.overlay)): raise ValueError("OS image %s does not exist" % self.image) + if args.mac: self.mac_address = args.mac else: @@ -86,7 +121,6 @@ class QemuCommand(object): self.gui = not args.no_gui self.gdb = args.gdb self.pcap = args.pcap - self.overlay = args.overlay self.secondary_network = args.secondary_network def command_line(self): diff --git a/scripts/run-qemu-ota b/scripts/run-qemu-ota index de63297..e9f44d6 100755 --- a/scripts/run-qemu-ota +++ b/scripts/run-qemu-ota @@ -53,7 +53,7 @@ def main(): cmdline = qemu_command.command_line() if args.overlay and not exists(args.overlay): - print("Image file %s does not yet exist, creating." % args.overlay) + print("Overlay file %s does not yet exist, creating." % args.overlay) img_cmdline = qemu_command.img_command_line() if args.dry_run: print(" ".join(img_cmdline)) -- cgit v1.2.3-54-g00ecf From cfa1b1cd6e00bdac6bc15718e7e9f285c731834a Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 9 Sep 2019 14:31:40 +0200 Subject: Prevent creating an overlay with any path but the current directory. Anything else will cause problems because of the hackery with keeping backup copies of the image and the u-boot rom. Also warn about supplying a different image name after the overlay has been created. That doesn't work and it will be ignored. Signed-off-by: Patrick Vacek --- scripts/run-qemu-ota | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/scripts/run-qemu-ota b/scripts/run-qemu-ota index e9f44d6..3312fd3 100755 --- a/scripts/run-qemu-ota +++ b/scripts/run-qemu-ota @@ -2,7 +2,7 @@ from argparse import ArgumentParser from subprocess import Popen -from os.path import exists +from os.path import exists, dirname import sys from qemucommand import QemuCommand @@ -39,6 +39,16 @@ def main(): 'This can be used to test Uptane Primary/Secondary communication.') parser.add_argument('-n', '--dry-run', help='Print qemu command line rather then run it', action='store_true') args = parser.parse_args() + + if args.overlay and not exists(args.overlay) and dirname(args.overlay) and not dirname(args.overlay) == '.': + print('Error: please provide a file name in the current working directory. ' + + 'Overlays do not work properly with other directories.') + sys.exit(1) + if args.overlay and exists(args.overlay) and args.imagename != parser.get_default('imagename'): + # qemu-img amend -o might work, but it has not yet been done + # successfully. + print('Warning: cannot change backing image of overlay after it has been created.') + try: qemu_command = QemuCommand(args) except ValueError as e: -- cgit v1.2.3-54-g00ecf From 7243d9ff8c033cf211d2fa81b7609b0ff9d9bf3f Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 9 Sep 2019 14:32:44 +0200 Subject: Print usage information after parameter checking. No use printing all that if there's a problem anyway. Signed-off-by: Patrick Vacek --- scripts/run-qemu-ota | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/run-qemu-ota b/scripts/run-qemu-ota index 3312fd3..232ee11 100755 --- a/scripts/run-qemu-ota +++ b/scripts/run-qemu-ota @@ -55,12 +55,6 @@ def main(): print(e.message) sys.exit(1) - print("Launching %s with mac address %s" % (args.imagename, qemu_command.mac_address)) - print("To connect via SSH:") - print(" ssh -o StrictHostKeyChecking=no root@localhost -p %d" % qemu_command.ssh_port) - print("To connect to the serial console:") - print(" nc localhost %d" % qemu_command.serial_port) - cmdline = qemu_command.command_line() if args.overlay and not exists(args.overlay): print("Overlay file %s does not yet exist, creating." % args.overlay) @@ -70,6 +64,12 @@ def main(): else: Popen(img_cmdline).wait() + print("Launching %s with mac address %s" % (args.imagename, qemu_command.mac_address)) + print("To connect via SSH:") + print(" ssh -o StrictHostKeyChecking=no root@localhost -p %d" % qemu_command.ssh_port) + print("To connect to the serial console:") + print(" nc localhost %d" % qemu_command.serial_port) + if args.dry_run: print(" ".join(cmdline)) else: -- cgit v1.2.3-54-g00ecf From 096c095fd7bc24c80352b36aeb06fc0f6a955f42 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 9 Sep 2019 17:06:02 +0200 Subject: Don't try to put the repo manifest in the initramfs image. It isn't very useful there and just takes up space. Signed-off-by: Patrick Vacek --- recipes-core/images/initramfs-ostree-image.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-core/images/initramfs-ostree-image.bb b/recipes-core/images/initramfs-ostree-image.bb index b21be1c..7e03f3d 100644 --- a/recipes-core/images/initramfs-ostree-image.bb +++ b/recipes-core/images/initramfs-ostree-image.bb @@ -29,4 +29,4 @@ IMAGE_OVERHEAD_FACTOR = "1.0" BAD_RECOMMENDATIONS += "busybox-syslog" - +IMAGE_PREPROCESS_COMMAND_remove = "buildinfo_manifest;" -- cgit v1.2.3-54-g00ecf From 5452e9fd7a0fec5e4894c1ecc096dc22e047cfd2 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 19 Aug 2019 13:45:31 +0200 Subject: aktualizr: aktualizr-repo was renamed to uptane-generator. Also bump to 2019.7 release of aktualizr and latest garage-sign. Signed-off-by: Patrick Vacek --- recipes-sota/aktualizr/aktualizr_git.bb | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/recipes-sota/aktualizr/aktualizr_git.bb b/recipes-sota/aktualizr/aktualizr_git.bb index 5ee9399..17aa15a 100644 --- a/recipes-sota/aktualizr/aktualizr_git.bb +++ b/recipes-sota/aktualizr/aktualizr_git.bb @@ -8,14 +8,14 @@ LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=9741c346eef56131163e13b9db1241b3" DEPENDS = "boost curl openssl libarchive libsodium sqlite3 asn1c-native" DEPENDS_append = "${@bb.utils.contains('PTEST_ENABLED', '1', ' coreutils-native net-tools-native ostree-native aktualizr-native ', '', d)}" RDEPENDS_${PN}_class-target = "aktualizr-configs lshw" -RDEPENDS_${PN}-host-tools = "aktualizr aktualizr-repo aktualizr-cert-provider ${@bb.utils.contains('PACKAGECONFIG', 'sota-tools', 'garage-deploy garage-push', '', d)}" +RDEPENDS_${PN}-host-tools = "aktualizr aktualizr-cert-provider ${@bb.utils.contains('PACKAGECONFIG', 'sota-tools', 'garage-deploy garage-push', '', d)}" RDEPENDS_${PN}-ptest += "bash cmake curl python3-misc python3-modules openssl-bin sqlite3 valgrind" PV = "1.0+git${SRCPV}" PR = "7" -GARAGE_SIGN_PV = "0.7.0-25-ge74a964" +GARAGE_SIGN_PV = "0.7.0-33-g214dfb1" SRC_URI = " \ gitsm://github.com/advancedtelematic/aktualizr;branch=${BRANCH} \ @@ -28,10 +28,10 @@ SRC_URI = " \ " # for garage-sign archive -SRC_URI[md5sum] = "9601dd891abac754400852cf367e86a2" -SRC_URI[sha256sum] = "1ebe2c9655b1fcc8d597dbda10c8a413eca12e5351582d916d0b088a84c33cd2" +SRC_URI[md5sum] = "66ffe8dcd61d4c15646e1c4b7dde7401" +SRC_URI[sha256sum] = "7a7193ddf7e1a33ea60fbb20f98318a8bd78c325dab391d8c4ebd644a738abdc" -SRCREV = "03778511cc937d07bf53a8092f8b268e65f5d9a6" +SRCREV = "3bb9fe91b4c614a79373beadc721272fcf7acce2" BRANCH ?= "master" S = "${WORKDIR}/git" -- cgit v1.2.3-54-g00ecf