From 7ce1bff869da970029a1a1610bedcced62cfc3e6 Mon Sep 17 00:00:00 2001 From: Jon Oster Date: Fri, 28 Feb 2020 09:38:35 +0100 Subject: [PATCH 01/11] Set display_version to 2020.3 (latest) in antora.yml Signed-off-by: Jon Oster --- docs/ota-client-guide/antora.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ota-client-guide/antora.yml b/docs/ota-client-guide/antora.yml index 63619fa77b..26941ea236 100644 --- a/docs/ota-client-guide/antora.yml +++ b/docs/ota-client-guide/antora.yml @@ -1,6 +1,6 @@ name: ota-client title: OTA Connect Developer Guide version: latest -display_version: 2020.2 (latest) +display_version: 2020.3 (latest) nav: - modules/ROOT/nav.adoc From cd842d51b8663ef61a48300ce56ddf932d8c4f2f Mon Sep 17 00:00:00 2001 From: Halyna Dumych Date: Fri, 28 Feb 2020 17:02:48 +0200 Subject: [PATCH 02/11] Add the Additional environments subsection In a separate section, describe that, instead of creating multiple accounts, users can create additional env using only one account. Add a beta icon to that feature. Relates-to: OTA-4601 Signed-off-by: Halyna Dumych --- .../modules/ROOT/pages/account-setup.adoc | 24 ++++++++++++++----- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc b/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc index 3294e4ad02..ea65739713 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc @@ -8,12 +8,24 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} endif::[] -In OTA Connect, all devices and software belong to one *user* login. However, you don't want to mix up test software and production software by creating them all under the same user. +If you do not want to mix up test and production software, you may use separate user logins or create additional environments. -In a proper production workflow, you'll need separate user logins to manage the different stages: +== Separate user logins -. A developer user such as "\dev@acme.com". -. A QA user such as "\qa@acme.com". -. A production user such as "\prod@acme.com". +To manage the different stages of production workflow, you can create separate user logins: -These logins provide you with a convenient way of clearly separating your development, QA and production resources. +* A developer user such as _\dev@acme.com_ +* A QA user such as _\qa@acme.com_ +* A production user such as _\prod@acme.com_ + +These logins provide you with a convenient way to separate your development, QA, and production resources. + +== Additional environments image:img::beta-icon.svg[Beta] + +NOTE: This feature is in beta and is only visible to users who are part of our beta program. If you would like to join the beta program, contact us at link:mailto:otaconnect.support@here.com[otaconnect.support@here.com] to request access. + +Instead of creating multiple accounts for each environment, you can now xref:ota-web::create-environment.adoc[create] additional environments using only one account. For example, you may need to have different environments for development, QA, and production. + +After you create an environment, you can xref:ota-web::manage-members.adoc[add] your colleagues to work together on device provisioning, device groups, software versions, software updates, and campaigns. + +To get more information on the environments feature, see the xref:ota-web::environments-intro.adoc[*Environments*] section in the OTA Connect User Guide. From 47a144f02bdda2a70ea6c60f6bb6885d72a8fc38 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Tue, 3 Mar 2020 17:25:33 +0100 Subject: [PATCH 03/11] New doc about getting useful information when reporting problems. This came out of a discussion with our support team. Co-Authored-By: Jon Oster Signed-off-by: Patrick Vacek --- docs/ota-client-guide/modules/ROOT/nav.adoc | 1 + .../modules/ROOT/pages/debugging-tips.adoc | 4 +- .../ROOT/pages/reporting-problems.adoc | 59 +++++++++++++++++++ 3 files changed, 62 insertions(+), 2 deletions(-) create mode 100644 docs/ota-client-guide/modules/ROOT/pages/reporting-problems.adoc diff --git a/docs/ota-client-guide/modules/ROOT/nav.adoc b/docs/ota-client-guide/modules/ROOT/nav.adoc index 5b3490d8f9..4410897f85 100644 --- a/docs/ota-client-guide/modules/ROOT/nav.adoc +++ b/docs/ota-client-guide/modules/ROOT/nav.adoc @@ -109,6 +109,7 @@ ifndef::env-github[:pageroot:] .Troubleshooting * xref:{pageroot}troubleshooting.adoc[Troubleshooting] +* xref:{pageroot}reporting-problems.adoc[Reporting problems] .For Contributors // Dev-authored topics diff --git a/docs/ota-client-guide/modules/ROOT/pages/debugging-tips.adoc b/docs/ota-client-guide/modules/ROOT/pages/debugging-tips.adoc index 48ee9106e6..0a98d3a537 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/debugging-tips.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/debugging-tips.adoc @@ -74,7 +74,7 @@ uptane-generator generate Then, serve the generated directory using a web server such as the link:{aktualizr-github-url}/tests/fake_http_server/fake_test_server.py[fake test server]. -For more information about using uptane-generator, see xref:uptane-generator.adoc[uptane-generator.adoc]. +For more information about using uptane-generator, see the xref:uptane-generator.adoc[uptane-generator article]. Here is an example configuration for nginx: @@ -98,7 +98,7 @@ server { == Inject faults -See xref:fault-injection.adoc[fault-injection.adoc] +See the xref:fault-injection.adoc[fault injection article] for more information. == Developing and debugging with an OpenEmbedded system diff --git a/docs/ota-client-guide/modules/ROOT/pages/reporting-problems.adoc b/docs/ota-client-guide/modules/ROOT/pages/reporting-problems.adoc new file mode 100644 index 0000000000..6356c64ebe --- /dev/null +++ b/docs/ota-client-guide/modules/ROOT/pages/reporting-problems.adoc @@ -0,0 +1,59 @@ += Reporting problems +ifdef::env-github[] + +[NOTE] +==== +We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname}.html[view this article in our documentation portal]. Not all of our articles render correctly in GitHub. +==== +endif::[] + +:page-layout: page +:page-categories: [tips] +:icons: font + +== Contacting HERE OTA Connect support + +If you encounter a problem with {product-name} and the xref:troubleshooting.adoc[Troubleshooting article] doesn't address it, please contact link:mailto:otaconnect.support@here.com[otaconnect.support@here.com] and we'll do our best to help! To help us diagnose your issue, please provide us with as much information as possible. What follows are some useful artifacts as well as how to retrieve them. + +=== aktualizr logs with debug logging + +By default, aktualizr writes logs to the systemd logger, which you can read with `journalctl -u aktualizr`. If you run aktualizr manually on the commandline, the logging is printed on stdout. The default loglevel is 2 (info). Lower loglevels are more verbose. To change the loglevel, there are two options: + +* To build a new image with debug logging enabled, add `IMAGE_INSTALL_append = " aktualizr-log-debug "` to your `local.conf` and bitbake a new image. See the xref:meta-updater-usage.adoc#_aktualizr_configuration[meta-updater usage article] for more details. +* To enable debug logging on a device accessible via the commandline without building a new image, stop the aktualizr service on the device (`systemctl stop aktualizr`) and manually start aktualizr on the commandline, e.g. `aktualizr --loglevel 0`. + +See also the xref:aktualizr-config-options.adoc#_logger[aktualizr configuration options article]. + +=== Output of aktualizr-info + +See the xref:debugging-tips.adoc#_inspect_stored_info_with_aktualizr_info[debugging tips] for more information. + +=== aktualizr version + +On an active device accessible via the commandline, enter `aktualizr --version`. Otherwise, you can examine the aktualizr recipe in meta-updater in your build environment and look for the `SRCREV` variable. This recipe will normally be located (relative to your Yocto build directory) at `../meta-updater/recipes-sota/aktualizr/aktualizr_git.bb`. + +=== aktualizr configuration + +If you are able to run aktualizr with loglevel 0, the final configuration will be printed to the log when aktualizr starts. See the xref:aktualizr-config-options.adoc#_logger[aktualizr configuration options article] for more information. + +If you are having problems with Secondaries, please also send us the Secondary JSON configuration file for the Primary (`secondary_config_file`) described in xref:aktualizr-config-options.adoc#_uptane[the same article]. + +=== Yocto release branch and layers used to build the image + +If you have the link:https://source.android.com/setup/build/downloading[Android repo] tool available and initialized your build environment with it (such as via the link:https://github.com/advancedtelematic/updater-repo/[updater-repo]), you can run `repo manifest -r` to print out all of the layers you are using and the revisions that are checked out. + +If Android repo is not available or was not used, please send us your `bblayers.conf` file, which normally can be found in the `conf` subdirectory of your bitbake build directory. Please also let us know which Yocto release branch you are using. + +See the xref:yocto-release-branches.adoc[Yocto release branches article] for more information. + +=== Yocto configuration + +For problems with bitbaking, please send us your `local.conf` file, which normally can be found in the `conf` subdirectory of your bitbake build directory. + +=== aktualizr-secondary logs + +If you are using aktualizr-secondary and having a problem with it, its logs may be helpful as well. aktualizr-secondary logs in the same way as aktualizr on the Primary, except for the name of the application. + +=== aktualizr-secondary configuration + +The aktualizr-secondary configuration may be helpful if applicable. aktualizr-secondary is configured similarly to aktualizr on the Primary, and it also prints the entire final configuration to the log if loglevel 0 is used. From f2c22a89b577f16fc21f9e4cf07fa0f5467901e2 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Wed, 4 Mar 2020 11:42:18 +0100 Subject: [PATCH 04/11] Add OSTree commands for pruning objects. Co-Authored-By: Amma Boateng Signed-off-by: Patrick Vacek --- .../modules/ROOT/pages/ostree-usage.adoc | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc b/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc index e047bc86c0..5dc58a0e3d 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc @@ -42,3 +42,22 @@ The -R option is supported, for recursive file listing. Refs can be branch names or commit hashes, much like in git. Note that this does not show the contents of the diff; it just shows files added, deleted, and modified. +== Pruning unused/unwanted objects + +OSTree normally manages garbage collection of objects on its own, but if your OSTree repo in your build directory is too large, you can manually remove unwanted commits and objects. You can also use the `ostree` tool on your device to remove coommits and objects on your device. This may be useful if you know that a certain commit has a flaw that you do not want to let get deployed. + +First, you will need to find which commits and refs are currently not deployed and are no longer needed. You can use these commands to help make that determination: + + ostree admin status + ostree refs + ostree log + +Then, for each ref that you would like to remove: + + ostree refs --delete + +And then for each commit that you would like to remove: + + ostree prune --delete-commit= + +Note that `ostree admin status` will still show deleted commits, but if you try to deploy a deleted commit, the operation will fail as expected. From 906e3caed1b5a0707af3d2c5f162d6159fd8aed1 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Thu, 5 Mar 2020 14:20:40 +0100 Subject: [PATCH 05/11] Update the rest of the OSTree doc. Improve some formatting, fix the branch naming logic, and add a crosslink. Signed-off-by: Patrick Vacek --- docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc b/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc index 5dc58a0e3d..05ca7aeec6 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/ostree-usage.adoc @@ -13,7 +13,7 @@ endif::[] :page-order: 3 :icons: font -Sometimes, while troubleshooting, it might be helpful to see and manipulate your local OSTree repos. You can do that using the copy of ostree that bitbake builds. For the rest of these commands, we'll assume that you've exported the executable as `$OSTREE`, and the location of your local repo as `$REPO` (for example, like so): +Sometimes, while troubleshooting, it might be helpful to see and manipulate your local OSTree repos. You can do that using the copy of `ostree` that bitbake builds. For the rest of these commands, we'll assume that you've exported the executable as `$OSTREE`, and the location of your local repo as `$REPO` (for example, like so): export OSTREE=$(pwd)/tmp/sysroots/x86_64-linux/usr/bin/ostree export REPO=$(pwd)/tmp/deploy/images/raspberrypi3/ostree_repo/ @@ -24,7 +24,7 @@ You'll need a branch name for most other commands, so it's often useful to check $OSTREE refs --repo $REPO -The branch name defaults to \{MACHINE}-ota, so if you were building for raspberrypi3, your branch name would be raspberrypi3-ota by default. However, you can set the branch name for your build in local.conf using the *OSTREE_BRANCHNAME* configuration option, letting you keep your different builds, projects, or branches under different names. +The branch name defaults to \{MACHINE}, so if you were building for raspberrypi3, your branch name would be raspberrypi3 by default. However, you can set the branch name for your build in `local.conf` using the `OSTREE_BRANCHNAME` configuration option, letting you keep your different builds, projects, or branches under different names. See the xref:build-configuration.adoc[build configuration article] for more information. == Show the log for a particular branch From 8dbb5027504aaab440a9c7f35ecc699ac6fd246b Mon Sep 17 00:00:00 2001 From: Jon Oster Date: Mon, 9 Mar 2020 13:00:46 +0100 Subject: [PATCH 06/11] Fix location of QEMU image in AGL build instructions Signed-off-by: Jon Oster --- docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc b/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc index 02762bc6da..93b5528e3a 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc @@ -102,6 +102,6 @@ TIP: You can also write the image using `dd`, but since the wrong kind of typo i === Run with QEMU -You can now run the image in QEMU using the same method as described for a xref:build-qemu.adoc#_run_the_built_image_with_qemu[regular QEMU build]. However, the exact image you'll need will vary depending on the architecture you're building forfootnote:[For example, building the `agl-image-minimal` target for QEMU creates an image at `build/tmp/deploy/images/raspberrypi3/agl-image-minimal-qemux86-64.ota-ext4`.], but it will be located in the `/tmp/deploy/images` directory under your build directory. +You can now run the image in QEMU using the same method as described for a xref:build-qemu.adoc#_run_the_built_image_with_qemu[regular QEMU build]. However, the exact image you'll need will vary depending on the architecture you're building forfootnote:[For example, building the `agl-image-minimal` target for QEMU creates an image at `build/tmp/deploy/images/qemux86-64/agl-image-minimal-qemux86-64.ota-ext4`.], but it will be located in the `/tmp/deploy/images` directory under your build directory. include::partial$recommended-steps.adoc[tags=firstbuild-nextstep] From f187e9a7cce7b88c4f0f682c99963b54cfb6f65c Mon Sep 17 00:00:00 2001 From: Jon Oster Date: Mon, 9 Mar 2020 13:20:18 +0100 Subject: [PATCH 07/11] Add note about meta-updater location in AGL Signed-off-by: Jon Oster --- docs/ota-client-guide/modules/ROOT/pages/build-qemu.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/ota-client-guide/modules/ROOT/pages/build-qemu.adoc b/docs/ota-client-guide/modules/ROOT/pages/build-qemu.adoc index fe17f2e769..8c129f6085 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/build-qemu.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/build-qemu.adoc @@ -33,6 +33,8 @@ The build process creates disk images as an artefact. You can then directly run Both arguments are optional; image name defaults to `core-image-minimal`, and if a mac address isn't specified, a random one is generated. +TIP: Depending on your build, the `meta-updater` directory might be in a slightly different location. For example, if you're building an xref:build-agl.adoc[AGL image], the meta-updater layer would be at `../external/meta-updater`. + .Persistent storage **** By default, QEMU will run your image in snapshot mode, *discarding any changes you made* to the disk image as soon as it exits. If you want to have a persistent VM, you need to create an link:https://wiki.archlinux.org/index.php/QEMU#Overlay_storage_images[overlay storage image] in qcow2 format. The helper script can also manage this for you, making it easy to create an emulated fleet of devices: From cd53aa4ed5d6a6eabdd3b2ab4fda3f8437c021c3 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 16 Mar 2020 09:51:35 +0100 Subject: [PATCH 08/11] Move the default branch to zeus. Thud in poky has been moved to community support only. We are still supporting it in our repos for now, but new users should use a newer release branch. Signed-off-by: Patrick Vacek --- .../modules/ROOT/pages/aktualizr-config-options.adoc | 2 +- docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/aktualizr-config-options.adoc b/docs/ota-client-guide/modules/ROOT/pages/aktualizr-config-options.adoc index 5661155b97..b7d8fd6b7a 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/aktualizr-config-options.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/aktualizr-config-options.adoc @@ -38,7 +38,7 @@ For examples of configuration files, see the following resources: * link:{aktualizr-github-url}/config/[Config files used by unit tests] * link:{aktualizr-github-url}/tests/config/[Config files used by continuous integration tests] -* link:https://github.com/advancedtelematic/meta-updater/tree/thud/recipes-sota/config/files[Configuration fragments used in meta-updater recipes]. +* link:https://github.com/advancedtelematic/meta-updater/tree/zeus/recipes-sota/config/files[Configuration fragments used in meta-updater recipes]. All fields are optional, and most have reasonable defaults that should be used unless you have a particular need to do otherwise. diff --git a/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc b/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc index ba8ffa10a9..f0bf169346 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc @@ -61,7 +61,7 @@ First, clone a manifest file for the quickstart project: ---- mkdir myproject cd myproject -repo init -u https://github.com/advancedtelematic/updater-repo.git -m thud.xml +repo init -u https://github.com/advancedtelematic/updater-repo.git -m zeus.xml repo sync ---- From c954ed0d81d705db067bc757f877e9d0cece2e44 Mon Sep 17 00:00:00 2001 From: Jon Oster Date: Tue, 17 Mar 2020 15:34:50 +0100 Subject: [PATCH 09/11] DOCS: OTA-4701 Fix export-credentials instructions Signed-off-by: Jon Oster --- .../modules/ROOT/pages/rotating-signing-keys.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/rotating-signing-keys.adoc b/docs/ota-client-guide/modules/ROOT/pages/rotating-signing-keys.adoc index 8f89bdbe62..0f8514653a 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/rotating-signing-keys.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/rotating-signing-keys.adoc @@ -108,7 +108,7 @@ After rotating keys, you will no longer be able to upload packages through the O Export the new offline `targets` into a new credentials file that you can use with `bitbake`: ---- -garage-sign export-credentials --repo myimagerepo --target-key-name mytargets --to offline-credentials.zip +garage-sign export-credentials --repo myimagerepo --key-name mytargets --output offline-credentials.zip ---- Update your `local.conf` to use the new `offline-credentials.zip` file and run `bitbake` as before. From 34b91dc7a52c71651bbac22f3ff27c562d0ff6af Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 23 Mar 2020 17:05:55 +0100 Subject: [PATCH 10/11] Docs: Bump yocto-version to 3.0 (zeus). Signed-off-by: Patrick Vacek --- .../modules/ROOT/pages/_partials/aktualizr-version.adoc | 2 +- .../add-ota-functonality-existing-yocto-project.adoc | 6 ++++-- .../modules/ROOT/pages/build-raspberry.adoc | 3 ++- .../modules/ROOT/pages/customise-targets-metadata.adoc | 4 +++- .../modules/ROOT/pages/pushing-updates.adoc | 4 +++- .../ROOT/pages/troubleshooting-bsp-integration.adoc | 8 ++++---- .../modules/ROOT/pages/troubleshooting.adoc | 4 +++- 7 files changed, 20 insertions(+), 11 deletions(-) diff --git a/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc b/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc index 08497097d4..ffa537e8f4 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc @@ -5,4 +5,4 @@ // latest version. :aktualizr-version: 2020.3 -:yocto-version: 2.6 +:yocto-version: 3.0 diff --git a/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc b/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc index 502e52102e..312fc9b11d 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/add-ota-functonality-existing-yocto-project.adoc @@ -7,6 +7,8 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} ==== endif::[] +include::_partials/aktualizr-version.adoc[] + :page-layout: page :page-categories: [quickstarts] :page-date: 2017-05-23 16:27:58 @@ -15,9 +17,9 @@ endif::[] If you already have a Yocto-based project, you can start your functional integration with {product-name} by following these four steps: -1. Clone the https://github.com/advancedtelematic/meta-updater[meta-updater] layer and add it to your https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[bblayers.conf]. +1. Clone the https://github.com/advancedtelematic/meta-updater[meta-updater] layer and add it to your https://www.yoctoproject.org/docs/{yocto-version}/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[bblayers.conf]. 2. Clone a 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 xref:supported-boards.adoc#_adding_support_for_your_board[Adding support for your board] for more details. -3. Set up your https://www.yoctoproject.org/docs/2.6/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` or to `poky-sota-systemd`. Alternatively, if you are using your own or a third-party distro configuration, you can add the following parameters to it, thus combining the capabilities of your distro with meta-updater features. +3. Set up your https://www.yoctoproject.org/docs/{yocto-version}/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` or to `poky-sota-systemd`. Alternatively, if you are using your own or a third-party distro configuration, you can add the following parameters to it, thus combining the capabilities of your distro with meta-updater features. + ---- INHERIT += " sota" diff --git a/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc b/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc index f0bf169346..0fd65546f7 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc @@ -8,6 +8,7 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} ==== endif::[] +include::_partials/aktualizr-version.adoc[] :page-layout: page :page-categories: [quickstarts] @@ -30,7 +31,7 @@ endif::[] You'll need a build machine with the following: -* A x86-64 Linux distro link:https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros[supported by the Yocto project] with the link:https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#required-packages-for-the-build-host[required packages] installed. +* A x86-64 Linux distro link:https://www.yoctoproject.org/docs/{yocto-version}/ref-manual/ref-manual.html#detailed-supported-distros[supported by the Yocto project] with the link:https://www.yoctoproject.org/docs/{yocto-version}/ref-manual/ref-manual.html#required-packages-for-the-build-host[required packages] installed. ** On a Debian-based system, you should be able to install all the required packages with the following command: + ---- diff --git a/docs/ota-client-guide/modules/ROOT/pages/customise-targets-metadata.adoc b/docs/ota-client-guide/modules/ROOT/pages/customise-targets-metadata.adoc index de20db896f..a825c66ef8 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/customise-targets-metadata.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/customise-targets-metadata.adoc @@ -7,6 +7,8 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} ==== endif::[] +include::_partials/aktualizr-version.adoc[] + In some cases, you might find it useful to include extra metadata about your software inside the signed Uptane metadata that OTA Connect delivers to your device. Some reasons you might want to do this include: * to provide installation instructions or scripts for an image that can't or shouldn't be included in the image itself @@ -84,4 +86,4 @@ You can then upload your customized `targets.json` to OTA Connect as normal: garage-sign targets push --repo myimagerepo ---- -NOTE: You also might want to add custom metadata while bitbaking. You can do this, for example, by modifying the `IMAGE_CMD_garagesign` function in link:https://github.com/advancedtelematic/meta-updater/blob/master/classes/image_types_ostree.bbclass#L217[image_types_ostree.bbclass]. A detailed guide on how to accomplish this is out of our scope, however. Refer to http://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html[the Yocto Reference Manual] for further details. +NOTE: You also might want to add custom metadata while bitbaking. You can do this, for example, by modifying the `IMAGE_CMD_garagesign` function in link:https://github.com/advancedtelematic/meta-updater/blob/master/classes/image_types_ostree.bbclass#L217[image_types_ostree.bbclass]. A detailed guide on how to accomplish this is out of our scope, however. Refer to http://www.yoctoproject.org/docs/{yocto-version}/dev-manual/dev-manual.html[the Yocto Reference Manual] for further details. diff --git a/docs/ota-client-guide/modules/ROOT/pages/pushing-updates.adoc b/docs/ota-client-guide/modules/ROOT/pages/pushing-updates.adoc index 86ac36f035..8372262b81 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/pushing-updates.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/pushing-updates.adoc @@ -8,6 +8,8 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} ==== endif::[] +include::_partials/aktualizr-version.adoc[] + Every time you bitbake a new image, it is automatically pushed to {product-name}. You can then send the updated image out to any of your devices. In this guide, you learn a few ways to push updated system images from your build machine or workstation to {product-name-short}. == Add a new package from an existing recipe @@ -102,7 +104,7 @@ The screen sessions will be named `pianobar` and `patiobar` respectively; use `s == Make your own recipe or layer -A complete guide to writing Yocto recipes is out of scope here, but http://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe[the Yocto Reference Manual] is a great resource. You can also take a look at the recipes in https://github.com/advancedtelematic/meta-jukebox[`meta-jukebox`] to use as examples: they're all fairly simple, and there are examples of four different types of recipe: +A complete guide to writing Yocto recipes is out of scope here, but http://www.yoctoproject.org/docs/{yocto-version}/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe[the Yocto Reference Manual] is a great resource. You can also take a look at the recipes in https://github.com/advancedtelematic/meta-jukebox[`meta-jukebox`] to use as examples: they're all fairly simple, and there are examples of four different types of recipe: * https://github.com/advancedtelematic/meta-jukebox/tree/master/recipes-multimedia/pianobar[Pianobar] itself is a fully manual recipe, though it's a pretty simple one; it has specific instructions for the compile and install steps, though they're essentially just `make` and `make install` with a couple of config options. * https://github.com/advancedtelematic/meta-jukebox/tree/master/recipes-multimedia/libao[libao] and https://github.com/advancedtelematic/meta-jukebox/tree/master/recipes-multimedia/faad2[faad2] make use of https://en.wikipedia.org/wiki/GNU_Build_System[Autotools] to build. They include the line `inherit autotools` in the recipe, which automatically generates configure, compile, and install instructions based on Autotools. diff --git a/docs/ota-client-guide/modules/ROOT/pages/troubleshooting-bsp-integration.adoc b/docs/ota-client-guide/modules/ROOT/pages/troubleshooting-bsp-integration.adoc index 8ecf52de70..0073742b39 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/troubleshooting-bsp-integration.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/troubleshooting-bsp-integration.adoc @@ -29,10 +29,10 @@ INITRAMFS_IMAGE = "initramfs-ostree-image" Building an integration with a new board involves dealing with several different systems. See the following links for more information on this: -* https://www.yoctoproject.org/docs/{yocto-version}/mega-manual/mega-manual.html[Yocto Mega Manual, v2.6]: The Yocto Mega Manual is a concatenation of all the various other reference manuals; it’s usually better to use the individual manuals if you know what you’re looking for. In particular, these three are the most frequently used in the BSP development domain: -** https://www.yoctoproject.org/docs/{yocto-version}/ref-manual/ref-manual.html[Yocto Reference Manual, v2.6] -** https://www.yoctoproject.org/docs/{yocto-version}/bsp-guide/bsp-guide.html[Yocto BSP Developer's Guide, v2.6] -** https://www.yoctoproject.org/docs/{yocto-version}/bitbake-user-manual/bitbake-user-manual.html[Bitbake User Manual, v2.6] +* https://www.yoctoproject.org/docs/{yocto-version}/mega-manual/mega-manual.html[Yocto Mega Manual, v{yocto-version}]: The Yocto Mega Manual is a concatenation of all the various other reference manuals; it’s usually better to use the individual manuals if you know what you’re looking for. In particular, these three are the most frequently used in the BSP development domain: +** https://www.yoctoproject.org/docs/{yocto-version}/ref-manual/ref-manual.html[Yocto Reference Manual, v{yocto-version}] +** https://www.yoctoproject.org/docs/{yocto-version}/bsp-guide/bsp-guide.html[Yocto BSP Developer's Guide, v{yocto-version}] +** https://www.yoctoproject.org/docs/{yocto-version}/bitbake-user-manual/bitbake-user-manual.html[Bitbake User Manual, v{yocto-version}] * https://ostree.readthedocs.io/en/latest/[libostree reference documentation] ** https://ostree.readthedocs.io/en/latest/manual/deployment/[Deployments] diff --git a/docs/ota-client-guide/modules/ROOT/pages/troubleshooting.adoc b/docs/ota-client-guide/modules/ROOT/pages/troubleshooting.adoc index 1a10319d98..9a140ea309 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/troubleshooting.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/troubleshooting.adoc @@ -7,6 +7,8 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname} ==== endif::[] +include::_partials/aktualizr-version.adoc[] + :page-layout: page :page-categories: [tips] :page-date: 2017-06-13 10:51:53 @@ -78,7 +80,7 @@ This is required if you have a service that does all of the following: * Runs as an account that is not one of the 'standard' accounts (`root`, `floppy`, `man`, `tape`, etc) * The recipe for the service creates the user (using `useradd`) -In this case, you should set `useradd`. The link:https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#ref-classes-useradd[useradd] section of the Yocto Mega Manual describes this process in more detail. +In this case, you should set `useradd`. The link:https://www.yoctoproject.org/docs/{yocto-version}/mega-manual/mega-manual.html#ref-classes-useradd[useradd] section of the Yocto Mega Manual describes this process in more detail. .Don't see your problem here? From 03301592357bdd91120e716cafd9d159d7596ef0 Mon Sep 17 00:00:00 2001 From: Patrick Vacek Date: Mon, 23 Mar 2020 16:55:49 +0100 Subject: [PATCH 11/11] Docs: prepare for 2020.4 release. Co-Authored-By: Laurent Bonnans Signed-off-by: Patrick Vacek --- CHANGELOG.md | 21 ++++++++++++++++++- docs/README.adoc | 1 + .../pages/_partials/aktualizr-version.adoc | 2 +- 3 files changed, 22 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 204e6f6730..3f19623949 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,9 +6,28 @@ Our versioning scheme is `YEAR.N` where `N` is incremented whenever a new releas ## [??? (unreleased)] + +## [2020.4] - 2020-03-24 + ### Added -- Aktualizr secondaries can now reboot automatically after triggering an update: [PR](https://github.com/advancedtelematic/aktualizr/pull/1578) +- aktualizr-secondary can now reboot automatically after triggering an update: [PR](https://github.com/advancedtelematic/aktualizr/pull/1578) +- Reports are now stored in the SQL database so they persist through unexpected shutdown: [PR](https://github.com/advancedtelematic/aktualizr/pull/1559) + +### Changed + +- garage-push now always pushes the OSTree ref to Treehub: [PR](https://github.com/advancedtelematic/aktualizr/pull/1575) +- Consistently follow the [Uptane standard's style guide](https://github.com/uptane/uptane-standard#style-guide) when using Uptane concepts, including the metadata output options of aktualizr-info: [PR](https://github.com/advancedtelematic/aktualizr/pull/1591) +- Public contributions now are tested with Github Actions instead of Travis CI: [PR](https://github.com/advancedtelematic/aktualizr/pull/1597) +- Default/recommended Yocto branch is zeus (3.0): [PR](https://github.com/advancedtelematic/aktualizr/pull/1603) +- Improved logging for aktualizr-secondary: [PR](https://github.com/advancedtelematic/aktualizr/pull/1609) + +### Fixed + +- Abort initialization if ECUs are already registered: [PR](https://github.com/advancedtelematic/aktualizr/pull/1579) +- Always use 64-bit integers for disk space arithmetic: [PR](https://github.com/advancedtelematic/aktualizr/pull/1588) +- Reject Director Targets metadata with delegations or repeated ECU IDs: [PR](https://github.com/advancedtelematic/aktualizr/pull/1600) + ## [2020.3] - 2020-02-27 diff --git a/docs/README.adoc b/docs/README.adoc index 2d0e656534..e61e8db3f3 100644 --- a/docs/README.adoc +++ b/docs/README.adoc @@ -35,6 +35,7 @@ The link above is for the doxygen docs on master. Doxygen docs for the following * https://advancedtelematic.github.io/aktualizr/2020.1/index.html[2020.1] * https://advancedtelematic.github.io/aktualizr/2020.2/index.html[2020.2] * https://advancedtelematic.github.io/aktualizr/2020.3/index.html[2020.3] +* https://advancedtelematic.github.io/aktualizr/2020.4/index.html[2020.4] ==== == Release process diff --git a/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc b/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc index ffa537e8f4..5080d59b65 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc @@ -3,6 +3,6 @@ // the version being viewed, but when we are referencing aktualizr from // the other, non-versioned docs, we want to make sure we're using the // latest version. -:aktualizr-version: 2020.3 +:aktualizr-version: 2020.4 :yocto-version: 3.0