diff --git a/CHANGELOG.md b/CHANGELOG.md index 5d2eb04ffe..1c873a3d57 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,30 @@ Our versioning scheme is `YEAR.N` where `N` is incremented whenever a new releas ## [??? (unreleased)] +## [2019.10] - 2019-11-15 + +### Added + +- Option to send Android repo manifest via garage-push: [PR](https://github.com/advancedtelematic/aktualizr/pull/1440) +- Expanded [C API](https://github.com/advancedtelematic/aktualizr/blob/master/include/libaktualizr-c.h): [PR #1387](https://github.com/advancedtelematic/aktualizr/pull/1387) and [PR #1429](https://github.com/advancedtelematic/aktualizr/pull/1429) + +### Changed + +- Hardware information is only sent if it has changed: [PR](https://github.com/advancedtelematic/aktualizr/pull/1434) +- Builds without OSTree now default to using the binary package manager: [PR](https://github.com/advancedtelematic/aktualizr/pull/1432) +- New endpoint for reporting hardware information: [PR](https://github.com/advancedtelematic/aktualizr/pull/1421) + +### Removed + +- libsystemd dependency and socket activation support: [PR](https://github.com/advancedtelematic/aktualizr/pull/1437) + +### Fixed + +- Enforce a limit of 10 HTTP redirects: [PR](https://github.com/advancedtelematic/aktualizr/pull/1420) +- Reject malformed root.json: [PR](https://github.com/advancedtelematic/aktualizr/pull/1417) +- Fall back on full file download if byte range requests are not supported: [PR](https://github.com/advancedtelematic/aktualizr/pull/1416) + + ## [2019.9] - 2019-10-16 ### Added diff --git a/docs/README.adoc b/docs/README.adoc index a59f06b31d..13a6ee9e78 100644 --- a/docs/README.adoc +++ b/docs/README.adoc @@ -30,6 +30,7 @@ The link above is for the doxygen docs on master. Doxygen docs for the following * https://advancedtelematic.github.io/aktualizr/2019.7/index.html[2019.7] * https://advancedtelematic.github.io/aktualizr/2019.8/index.html[2019.8] * https://advancedtelematic.github.io/aktualizr/2019.9/index.html[2019.9] +* https://advancedtelematic.github.io/aktualizr/2019.10/index.html[2019.10] ==== == Release process diff --git a/docs/ota-client-guide/antora.yml b/docs/ota-client-guide/antora.yml index c805f430e4..8cf10f9aa0 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: 2019.8 (latest) +display_version: 2019.9 (latest) nav: - modules/ROOT/nav.adoc diff --git a/docs/ota-client-guide/modules/ROOT/nav.adoc b/docs/ota-client-guide/modules/ROOT/nav.adoc index 3960072ae2..d305f60aec 100644 --- a/docs/ota-client-guide/modules/ROOT/nav.adoc +++ b/docs/ota-client-guide/modules/ROOT/nav.adoc @@ -35,7 +35,7 @@ ifndef::env-github[:pageroot:] * xref:{pageroot}build-images.adoc[Use our sample recipes to build disk images] ** xref:{pageroot}build-raspberry.adoc[Build for a Raspberry Pi] ** xref:{pageroot}build-qemu.adoc[Build for QEMU] -// OTA-3629: Uncomment when AGL ready:** xref:{pageroot}build-agl.adoc[Build for Automotive Grade Linux] +** xref:{pageroot}build-agl.adoc[Build for Automotive Grade Linux] * xref:{pageroot}simulate-device-basic.adoc[Simulate a device without building a disk image] * xref:{pageroot}pushing-updates.adoc[Add software to your Yocto image] * xref:{pageroot}update-single-device.adoc[Update a second device with the sample software] 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 48a367b52e..eaaf453458 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,4 +3,4 @@ // 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: 2019.9 +:aktualizr-version: 2019.10 diff --git a/docs/ota-client-guide/modules/ROOT/pages/_partials/recommended-steps.adoc b/docs/ota-client-guide/modules/ROOT/pages/_partials/recommended-steps.adoc index 088ca981fc..37f64eb3dd 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/_partials/recommended-steps.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/_partials/recommended-steps.adoc @@ -35,9 +35,9 @@ In OTA Connect, each user account gets its own personal software repositories an + A better strategy for production is to create separate user logins to manage the different stages. For example, you might want a three-step process: + -. A developer user such as "dev@acme.com". -. A QA user such as "qa@acme.com". -. A production user such as "prod@acme.com". +. 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 way of clearly separating your development, QA and production resources. 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 7a16771d16..3294e4ad02 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/account-setup.adoc @@ -12,8 +12,8 @@ In OTA Connect, all devices and software belong to one *user* login. However, yo In a proper production workflow, you'll need separate user logins to manage the different stages: -. A developer user such as "dev@acme.com". -. A QA user such as ""qa@acme.com"". -. A production user such as "prod@acme.com"". +. 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 of clearly separating your development, QA and production resources. \ No newline at end of file +These logins provide you with a convenient way of clearly separating your development, QA and production resources. 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 aaef8f8158..f2802e8d90 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc @@ -26,19 +26,17 @@ include::build-raspberry.adoc[tags=prereqs] == Create your AGL Yocto build environment -=== Get AGL master manifest +=== Get the AGL code -First, clone a manifest file for AGL Electric Eel: +First, use the manifest file for AGL's Happy Halibut release to download the required repositories: ---- mkdir myproject cd myproject -repo init -b eel -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo.git +repo init -b halibut -m halibut_8.0.2.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo repo sync ---- -This will download the basic Yocto layers you need. Generally, HERE Technologies recommends using AGL's latest point release. - .What is this actually doing? **** Yocto is a set of tools, templates and methods for building Linux systems from scratch. Automotive Grade Linux is a complete Linux distribution designed for in-car systems. It includes base system layers from Poky and OpenEmbedded, board support layers for popular automotive platforms, and quite a lot more. @@ -51,28 +49,55 @@ All of these layers are assembled into a built Linux system by Bitbake, the buil Now you can run the following script to get the environment set up: ---- -source meta-agl/scripts/aglsetup.sh -m agl-demo agl-appfw-smack agl-sota <1> +source meta-agl/scripts/aglsetup.sh -m agl-sota <1> ---- <1> Where `` is either `raspberrypi3` or `qemux86-64`. -IMPORTANT: Only `raspberrypi3` and `qemux86-64` will work out of the box. If you want to create an {product-name-short}-compatible build for one of the other architectures AGL supports, you'll need to write a BSP layer for that board. You can take the link:https://github.com/advancedtelematic/meta-updater-raspberrypi/tree/morty/recipes-bsp[Raspberry Pi BSP] as an example of what's needed. You can also link:mailto:otaconnect.support@here.com[contact us directly] to inquire about commercial development of BSP layers for specific boards. +IMPORTANT: Only `raspberrypi3` and `qemux86-64` will work out of the box. If you want to create an {product-name-short}-compatible build for one of the other architectures AGL supports, you may need to write a BSP layer for that board. You can take the link:https://github.com/advancedtelematic/meta-updater-raspberrypi/tree/morty/recipes-bsp[Raspberry Pi BSP] as an example of what's needed. You can also link:mailto:otaconnect.support@here.com[contact us directly] to inquire about commercial development of BSP layers for specific boards. -include::build-raspberry.adoc[tags=config;bitbake] +=== Additional configuration for Raspberry Pi 3 -== Put the built image on your device's boot media +As described in the link:https://wiki.automotivelinux.org/agl-distro/agl-raspberrypi#sota[AGL wiki], you will need to edit your `bblayers.conf` to replace `meta-updater-qemux86-64` with `meta-updater-raspberrypi`. -The build process creates disk images as an artefact. The exact image you'll need will vary depending on the architecture you're building forfootnote:[For example, building the `agl-demo-platform` target for Raspberry Pi 3 creates an image at `build/tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic`.], but it will be located in the `/tmp/deploy/images` directory under your build directory. We recommend using https://www.balena.io/etcher/[Etcher, window="_blank"] to write the image, or following the normal flashing procedure for your device if applicable. +=== Additional configuration for QEMU -TIP: You can also write the image using `dd`, but since the wrong kind of typo in a dd command is so dangerous, we don't recommend it. +By default, AGL for QEMU boots into an initrd before loading the root filesystem, but as of thud, meta-updater by default uses an initramfs. You will need to force the build to use an initramfs by adding this to your `local.conf`: + +---- +AGL_DEFAULT_INITRAMFS_FSTYPES = "cpio.gz" +---- -You'll probably also want to resize the main partition to fill all of the space on the boot media: +include::build-raspberry.adoc[tags=config] +== Bitbake + +Now you're ready to build your image. + +[subs=+attributes] ---- -sudo parted -s /dev/sdX resizepart 2 '100%' <1> -sudo resize2fs /dev/sdX2 <1> +bitbake agl-image-minimal ---- -<1> Where /dev/sdX is the device you wrote the image to. -You should now be able to boot your device and have it show up in your {product-name-short} account. +This step will take a while. Building everything from scratch, it will likely take several hours. + +If the build fails due a problem with the tar recipe, try this command: + +---- +bitbake -c clean tar-native +---- + +You can then retry bitbaking your image. + +== Running the built image + +=== Put the built image on an SD card for Raspberry Pi 3 + +You can now flash the image onto an SD card using the same method as described for a xref:{pageroot}build-raspberry.adoc#_put_the_built_image_on_an_sd_card[regular Raspberry Pi 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 Raspberry Pi 3 creates an image at `build/tmp/deploy/images/raspberrypi3/agl-image-minimal-raspberrypi3.wic`.], but it will be located in the `/tmp/deploy/images` directory under your build directory. You can also use https://www.balena.io/etcher/[Etcher, window="_blank"] to write the image, or follow the normal flashing procedure for your device if applicable. + +TIP: You can also write the image using `dd`, but since the wrong kind of typo in a dd command is so dangerous, we don't recommend it. + +=== Run with QEMU + +You can now run the image in QEMU using the same method as described for a xref:{pageroot}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. include::partial$recommended-steps.adoc[tags=firstbuild-nextstep] diff --git a/docs/ota-client-guide/modules/ROOT/pages/generate-devicecert.adoc b/docs/ota-client-guide/modules/ROOT/pages/generate-devicecert.adoc index 4903994568..1ad347ca61 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/generate-devicecert.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/generate-devicecert.adoc @@ -50,7 +50,7 @@ You need this address to get the internal root CA certificate of the device gate + You should see a URL that resembles the following example: + -`https://946f68b8-13d2-4647-b335-5a48777b5657.tcpgw.prod01.advancedtelematic.com:443` +`\https://946f68b8-13d2-4647-b335-5a48777b5657.tcpgw.prod01.advancedtelematic.com:443` .. Make a note of this URL. . Get the device gateway's root certificate with the following openssl command: diff --git a/docs/ota-client-guide/modules/ROOT/pages/generatetest-devicecert.adoc b/docs/ota-client-guide/modules/ROOT/pages/generatetest-devicecert.adoc index e60b554103..84a439eab0 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/generatetest-devicecert.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/generatetest-devicecert.adoc @@ -48,7 +48,7 @@ You need this address to get the internal root CA certificate of the device gate + You should see a URL that resembles the following example: + -`https://946f68b8-13d2-4647-b335-5a48777b5657.tcpgw.prod01.advancedtelematic.com:443` +`\https://946f68b8-13d2-4647-b335-5a48777b5657.tcpgw.prod01.advancedtelematic.com:443` .. Make a note of this URL. . Get the device gateway's root certificate with the following openssl command: diff --git a/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc b/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc index 3f0228a79f..d166ac155a 100644 --- a/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc +++ b/docs/ota-client-guide/modules/ROOT/pages/supported-boards.adoc @@ -39,12 +39,12 @@ Your images will also need network connectivity to be able to reach an actual OT == 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 aktualizr binary is a lightweight {cpp} application between 2-5 MB in size. It uses around 20 MB RAM, although some of that comes from shared libraries. It uses a minimum amount of other 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. +* At a minimum, the board or device aktualizr is running on will need **64 MB of RAM** and **128 MB of storage**. +* We recommend using a board with slightly higher specs, however. **256 MB of RAM** and **512 MB storage** are reasonable targets, especially if you plan to process large, complex software updates. The aktualizr process itself won't consume significantly more RAM with larger updates, but the filesystem cache memory usage might increase. [NOTE] ====