diff --git a/mk/yocto.mk b/mk/yocto.mk index 834762132f..f44113371c 100644 --- a/mk/yocto.mk +++ b/mk/yocto.mk @@ -31,7 +31,7 @@ YOCTO_SLIDES = \ yocto-devtool \ yocto-devtool-lab \ yocto-layer-management \ - yocto-runtime-package-management \ + yocto-ota-updates \ yocto-resources \ last-slides \ yocto-extra-slides diff --git a/slides/yocto-extra-slides/yocto-extra-slides.typ b/slides/yocto-extra-slides/yocto-extra-slides.typ index e673673c76..d682b8a3e0 100644 --- a/slides/yocto-extra-slides/yocto-extra-slides.typ +++ b/slides/yocto-extra-slides/yocto-extra-slides.typ @@ -31,3 +31,147 @@ + Test the modifications: `$ bitbake -c compile -f recipe` + Generate the patch file: `$ quilt refresh` + Move the generated patch into the recipe's directory. + +== Runtime Package Management (IPK Setup) + + +=== Requirements + +- First of all, you need a server to serve the packages to a private + subnet or over the Internet. Packages are typically served over + `https` or `http`. + +- Specific tools are also required on the target, and must be shipped on + the product. They should be included into the images generated by the + build system. + +- These tools will be specific to the package type used. + + - This is similar to Linux distributions: Debian is using `.deb` + related tools (dpkg, apt…) while Fedora uses `.rpm` related ones + (rpm, dnf). + +=== Build configuration 1/2 + +- The #yoctovar("PACKAGE_CLASSES") variable controls which package + format to use. More than one can be used. + +- Valid values are `package_rpm`, `package_deb`, `package_ipk`. + +- By default Poky uses the RPM format, while OpenEmbedded-Core uses the + IPK one. + +- Example: + + - `PACKAGE_CLASSES = "package_ipk"` + + - `PACKAGE_CLASSES = "package_rpm package_deb"` + +=== Build configuration 2/2 + +To install the required tools on the target, there are two possible solutions: + +- By adding `package-management` to the images features. + + - The required tool will be installed on the target. + + - The package database corresponding to the build will be installed as + well. + +- Or by manually adding the required tools in + #yoctovar("IMAGE_INSTALL"). For example, to use the IPK format we + need `opkg`. + +=== Build considerations + +- The Runtime Package Management uses package databases to store + information about available packages and their version. + +- Whenever a build generates a new package or modifies an existing one, + the package database must be updated. + +- `$ bitbake package-index` + +- Be careful: BitBake does not properly schedule the `package-index` + target. You must use this target alone to have a consistent package + database. + + - `$ bitbake ninvaders package-index` won't necessarily generate an + updated package database. + +=== Package server configuration: Apache2 example setup + +Apache2 HTTP setup for IPK packages. This +should go in `/etc/apache2/sites-enabled/package-server.conf`. + +#v(0.5em) + +```sh + + ServerName packages.example.net + + DocumentRoot /path/to/build/tmp/deploy/ipk + + Options +Indexes + Options Indexes FollowSymLinks + Order allow,deny + allow from all + AllowOverride None + Require all granted + + +``` + +=== Target configuration: configuring `opkg` + +- The IPK runtime management software is `opkg`. + +- It can be configured using configurations files ending in `.conf` in + `/etc/opkg/`. + +- This configuration helps `opkg` to find the package databases you want + to use. + +- For example, with our previously configured package server: + + ```sh + src/gz all http://packages.example.net/all + src/gz armv7a http://packages.example.net/armv7a + src/gz beaglebone http://packages.example.net/beaglebone + ``` + +- This can be automatically generated by defining the + #yoctovar("PACKAGE_FEED_URIS"), + #yoctovar("PACKAGE_FEED_BASE_PATHS") and + #yoctovar("PACKAGE_FEED_ARCHS") variables + +=== `opkg usage` + +- `opkg update`: fetch and update the package databases, from the remote + package servers. + +- `opkg list`: list available packages. + +- `opkg upgrade`: upgrade all installed packages. + +- `opkg upgrade `: upgrade one package explicitly. + +- `opkg install `: install a specific package. + +=== `opkg` upgrade over an unstable network + +- To avoid upgrade issues when downloading packages from a remote + package server using an unstable connection, you can first download + the packages and then proceed with the upgrade. + +- To do this we must use a cache, which can be defined in the `opkg` + configuration with: `option cache /tmp/opkg-cache`. + +#v(0.5em) + +#[ #show raw.where(lang: "console", block: true): set text(size: 17pt) + ```console + # opkg update + # opkg --download-only upgrade + # opkg upgrade + ```] diff --git a/slides/yocto-ota-updates/yocto-ota-updates.typ b/slides/yocto-ota-updates/yocto-ota-updates.typ new file mode 100644 index 0000000000..3f0399dc18 --- /dev/null +++ b/slides/yocto-ota-updates/yocto-ota-updates.typ @@ -0,0 +1,70 @@ +#import "@local/bootlin:0.1.0": * + +#import "/typst/local/common.typ": * + +#show: bootlin-theme + += OTA updates + +== Runtime Package Management + + +=== Runtime Package Management + +- BitBake always builds packages selected in + #yoctovar("IMAGE_INSTALL"). + +- The binary packages are used to generate the root filesystem. + +- It is also possible to update the system at runtime using these + packages, for many use cases: + + - In-field security updates. + + - System updates over the wire. + + - System, packages or configuration customization at runtime. + + - Remote debugging. + +- Using the Runtime Package Management is an optional feature. + +- Can be useful for local development, but rarely used in production. + +- See the #link()[extra slides] for details on + how to set it up. + +== A/B updates + +=== A/B updates: principle + +- Mechanism for Over-The-Air (OTA) _image_ updates + +- Key idea: avoid one update bricking the device + - Even if tested, one update might prevent the system from booting + - Enable the device to recover from a bad update automatically + +- The key idea is to maintain at least two copies, in separate partitions + (slots) of your storage device + - minimum is 2 rootFS + - usually also includes the kernel + - can involve the bootloader, depending on the ROM code + +=== A/B updates: Yocto support + +- Three main open-source solutions: + + - #link("https://sbabic.github.io/swupdate/swupdate.html")[SWUpdate]: + - DIY approach, very flexible + - Yocto layer: #link("https://github.com/sbabic/meta-swupdate")[meta-swupdate] + + - #link("https://mender.io/")[Mender]: + - Fully-integrated solution, requires `systemd` + - Yocto layer: #link("https://github.com/mendersoftware/meta-mender")[meta-mender] + + - #link("https://rauc.io/")[RAUC]: + - Good middleground + - Yocto layer: #link("https://github.com/rauc/meta-rauc")[meta-rauc] + +- See our #link("https://bootlin.com/training/security/")[Security training] + for in-depth details on A/B updates. diff --git a/slides/yocto-runtime-package-management/yocto-runtime-package-management.typ b/slides/yocto-runtime-package-management/yocto-runtime-package-management.typ deleted file mode 100644 index a7b344d9f8..0000000000 --- a/slides/yocto-runtime-package-management/yocto-runtime-package-management.typ +++ /dev/null @@ -1,180 +0,0 @@ -#import "@local/bootlin:0.1.0": * - -#import "/typst/local/common.typ": * - -#show: bootlin-theme - -= Runtime Package Management - -=== Introduction - -- BitBake always builds packages selected in - #yoctovar("IMAGE_INSTALL"). - -- The packages are used to generate the root filesystem. - -- It is also possible to update the system at runtime using these - packages, for many use cases: - - - In-field security updates. - - - System updates over the wire. - - - System, packages or configuration customization at runtime. - - - Remote debugging. - -- Using the Runtime Package Management is an optional feature. - -- We'll use the IPK package format as an example in the following - slides. - -=== Requirements - -- First of all, you need a server to serve the packages to a private - subnet or over the Internet. Packages are typically served over - `https` or `http`. - -- Specific tools are also required on the target, and must be shipped on - the product. They should be included into the images generated by the - build system. - -- These tools will be specific to the package type used. - - - This is similar to Linux distributions: Debian is using `.deb` - related tools (dpkg, apt…) while Fedora uses `.rpm` related ones - (rpm, dnf). - -== Build configuration - - -=== Build configuration 1/2 - -- The #yoctovar("PACKAGE_CLASSES") variable controls which package - format to use. More than one can be used. - -- Valid values are `package_rpm`, `package_deb`, `package_ipk`. - -- By default Poky uses the RPM format, while OpenEmbedded-Core uses the - IPK one. - -- Example: - - - `PACKAGE_CLASSES = "package_ipk"` - - - `PACKAGE_CLASSES = "package_rpm package_deb"` - -=== Build configuration 2/2 - -To install the required tools on the target, there are two possible solutions: - -- By adding `package-management` to the images features. - - - The required tool will be installed on the target. - - - The package database corresponding to the build will be installed as - well. - -- Or by manually adding the required tools in - #yoctovar("IMAGE_INSTALL"). For example, to use the IPK format we - need `opkg`. - -=== Build considerations - -- The Runtime Package Management uses package databases to store - information about available packages and their version. - -- Whenever a build generates a new package or modifies an existing one, - the package database must be updated. - -- `$ bitbake package-index` - -- Be careful: BitBake does not properly schedule the `package-index` - target. You must use this target alone to have a consistent package - database. - - - `$ bitbake ninvaders package-index` won't necessarily generate an - updated package database. - -== Package server configuration - - -=== Apache2 example setup - -Apache2 HTTP setup for IPK packages. This -should go in `/etc/apache2/sites-enabled/package-server.conf`. - -#v(0.5em) - -```sh - - ServerName packages.example.net - - DocumentRoot /path/to/build/tmp/deploy/ipk - - Options +Indexes - Options Indexes FollowSymLinks - Order allow,deny - allow from all - AllowOverride None - Require all granted - - -``` - -== Target configuration - - -=== The IPK runtime management software - -- The IPK runtime management software is `opkg`. - -- It can be configured using configurations files ending in `.conf` in - `/etc/opkg/`. - -- This configuration helps `opkg` to find the package databases you want - to use. - -- For example, with our previously configured package server: - - ```sh - src/gz all http://packages.example.net/all - src/gz armv7a http://packages.example.net/armv7a - src/gz beaglebone http://packages.example.net/beaglebone - ``` - -- This can be automatically generated by defining the - #yoctovar("PACKAGE_FEED_URIS"), - #yoctovar("PACKAGE_FEED_BASE_PATHS") and - #yoctovar("PACKAGE_FEED_ARCHS") variables - -=== `opkg usage` - -- `opkg update`: fetch and update the package databases, from the remote - package servers. - -- `opkg list`: list available packages. - -- `opkg upgrade`: upgrade all installed packages. - -- `opkg upgrade `: upgrade one package explicitly. - -- `opkg install `: install a specific package. - -=== `opkg` upgrade over an unstable network - -- To avoid upgrade issues when downloading packages from a remote - package server using an unstable connection, you can first download - the packages and then proceed with the upgrade. - -- To do this we must use a cache, which can be defined in the `opkg` - configuration with: `option cache /tmp/opkg-cache`. - -#v(0.5em) - -#[ #show raw.where(lang: "console", block: true): set text(size: 17pt) - ```console - # opkg update - # opkg --download-only upgrade - # opkg upgrade - ```]