Yocto slides: add an OTA updates section

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

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)
+<runtime-package-management-annex>
+
+=== 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
+<VirtualHost *:80>
+    ServerName packages.example.net
+
+    DocumentRoot /path/to/build/tmp/deploy/ipk
+    <Directory /path/to/build/tmp/deploy/ipk>
+        Options +Indexes
+        Options Indexes FollowSymLinks
+        Order allow,deny
+        allow from all
+        AllowOverride None
+        Require all granted
+    </Directory>
+</VirtualHost>
+```
+
+=== 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 <package>`: upgrade one package explicitly.
+
+- `opkg install <package>`: 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
+  ```]

slides/yocto-ota-updates/yocto-ota-updates.typ

@@ -0,0 +1,72 @@
+#import "@local/bootlin:0.1.0": *
+
+#import "/typst/local/common.typ": *
+
+#show: bootlin-theme
+
+= OTA updates
+
+== Runtime Package Management
+<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(<runtime-package-management-annex>)[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 2 copies of the system, in two *slots*
+  - minimum is 2 rootFS
+  - usually also includes the kernel
+  - can involve the bootloader, depending on the bootROM
+
+=== A/B updates: Yocto support
+
+- Three main solutions:
+
+  - #link("https://sbabic.github.io/swupdate/swupdate.html")[SWUpdate]:
+    - DIY approach, very flexible
+    - Open-source
+    - Yocto layer: #link("https://github.com/sbabic/meta-swupdate")[meta-swupdate]
+
+  - #link("https://mender.io/")[Mender]:
+    - Fully-integrated solution, requires `systemd`
+    - Open-source, but server side is commercial
+    - Yocto layer: #link("https://github.com/mendersoftware/meta-mender")[meta-mender]
+
+  - #link("https://rauc.io/")[RAUC]:
+    - Good middleground
+    - Open-source
+    - 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.