Development

This document serves the purpose of gathering all the useful information regarding the construction of and development of the ubuntu-core flavor.

Overview

Every ubuntu-core image is composed of a defined set of snaps. The following section gives a quick overview of what each snap is about and includes a handy list of links for the given project.

New images are composed using the ubuntu-image tool and so called model assertions. In our case, model assertions tell ubuntu-image what to compose the created image of. It is the model that defines the base snap to use, the gadget and kernel. There are different model assertions for 16 and 18, for each supported platform.

The base (core) snap

This is the base filesystem with all the bare-essential libraries and tools for any system to work. Like the core snap, this is required to be present on any 18 core-enabled system. Basically it has to offer any crucial functionality that is needed for a minimal system to function and cannot be easily installed through separate snaps.

The gadget snap

Each supported device has its own gadget snap. Gadget snaps are what defines the device, carrying binaries for the bootloader, declaring the partition layout etc. It is important to keep in mind that the gadget code repositories are also used by classic Ubuntu preinstalled images, although currently separate branches are used.

There following gadget snaps are only used for the 16 series. Even though some of those repositories have 18 branches and/or include some snaps in the 18 track, they do not participate in any of the core18 images and should only be used for core16 (core):

Signing of shim and grub for the pc gadget

The shim and grub binaries are signed with a private key specific for Ubuntu Core systems. By using a different key to the one for classic systems we ensure that it will be possible to have devices that can start UC but not classic. The procedure to obtain newly signed binaries is:

  1. Copy grub2, grub2-unsigned, and shim source packages from the archive to https://launchpad.net/~ucdev/+archive/ubuntu/uc-build-ppa, including the binary packages generated by them (these should not be rebuilt). Although this is not strictly needed, with this we make sure that the artifacts that need to be signed are stored in the PPA and not pulled from the archive, which might be problematic if we need to re-sign this specific version and the archive has rotated versions (it only stores the latest three) so it gets more difficult to access these assets.

  2. Upload the corresponding grub2-signed and shim-signed source packages, but with a changelog entry that uses epoch 2, that is, version should be 2:<archive_version>. Using a different epoch ensures that if the shim/grub version in the archive bumps we will still pull the package signed with the UC key. (Ideally make it fail the build so only binaries built from the signing PPA exist - this can be done by adding final checks on whether the signature is chained to Canonical certs with "sbverify --cert CanonicalMasterCA.crt <file>", see https://launchpadlibrarian.net/491880978/shim-signed_1.41_1.43+uc20.4.diff.gz).

  3. Create a bug in grub2-signed and shim-signed projects, see for instance https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1981997. Subscribe the ~canonical-signing and ~canonical-foundations teams to it.

  4. Wait or ask somebody with permissions to copy the packages to the signing PPA so they get built and signed with the UC key.

  5. Once the packages are signed, they should be copied (by somebody with permissions) to https://launchpad.net/~ucdev/+archive/ubuntu/uc-staging-ppa. This PPA is included when building the pc gadget so shim/grub are pulled from there.

The copy-package tool (git clone lp:ubuntu-archive-tools) is used to copy package from the archive to PPAs. For example:

$ ./copy-package -b -s focal-updates --to ppa:ucdev/ubuntu/uc-build-ppa --to-suite focal -e 2.04-1ubuntu26.15 grub2

See https://wiki.ubuntu.com/ArchiveAdministration for more details.

Historically the PPAs used for this process were https://launchpad.net/~canonical-foundations/+archive/ubuntu/uc20-build-ppa and https://launchpad.net/~canonical-foundations/+archive/ubuntu/uc20-staging-ppa.

The snapd snap

The snap offering snapd itself. This was once part of the core snap but it has been ripped out as a separate snap since recently.

The kernel snap

For core16 only (not used for core18), legacy snaps:

  • pi2-kernel - the generic Raspberry Pi kernel, now renamed to pi-kernel.

Model assertions

All available and officially supported model assertions are available on https://github.com/snapcore/models .

One can get the model assertions for the selected supported platform by using the following commands:

Core 24

Besides the default, signed ones below, we also provide -dangerous and -<channel> model assertions.

  • Generic Raspberry Pi (64-bit): snap known --remote model series=16 model="ubuntu-core-24-pi-arm64" brand-id=canonical

  • amd64: snap known --remote model series=16 model="ubuntu-core-24-amd64" brand-id=canonical

Core 22

Besides the default, signed ones below, we also provide -dangerous and -<channel> model assertions.

  • Generic Raspberry Pi (32-bit): snap known --remote model series=16 model="ubuntu-core-22-pi-armhf" brand-id=canonical

  • Generic Raspberry Pi (64-bit): snap known --remote model series=16 model="ubuntu-core-22-pi-arm64" brand-id=canonical

  • amd64: snap known --remote model series=16 model="ubuntu-core-22-amd64" brand-id=canonical

Core 20

Besides the default, signed ones below, we also provide -dangerous and -<channel> model assertions.

  • Generic Raspberry Pi (32-bit): snap known --remote model series=16 model="ubuntu-core-20-pi-armhf" brand-id=canonical

  • Generic Raspberry Pi (64-bit): snap known --remote model series=16 model="ubuntu-core-20-pi-arm64" brand-id=canonical

  • amd64: snap known --remote model series=16 model="ubuntu-core-20-amd64" brand-id=canonical

Core 18

  • Generic Raspberry Pi: snap known --remote model series=16 model="ubuntu-core-18-pi" brand-id=canonical

  • Generic Raspberry Pi (64-bit): snap known --remote model series=16 model="ubuntu-core-18-pi-arm64" brand-id=canonical

  • Dragonboard: snap known --remote model series=16 model="ubuntu-core-18-dragonboard" brand-id=canonical

  • amd64: snap known --remote model series=16 model="ubuntu-core-18-amd64" brand-id=canonical

  • i386: snap known --remote model series=16 model="ubuntu-core-18-i386" brand-id=canonical

  • Obsolete Raspberry Pi 2: snap known --remote model series=16 model="ubuntu-core-18-pi2" brand-id=canonical

  • Obsolete Raspberry Pi 3: snap known --remote model series=16 model="ubuntu-core-18-pi3" brand-id=canonical

  • Obsolete Raspberry Pi 3 (64-bit): snap known --remote model series=16 model="ubuntu-core-18-pi3-arm64" brand-id=canonical

  • Obsolete Raspberry Pi CM3: snap known --remote model series=16 model="ubuntu-core-18-cm3" brand-id=canonical

Core 16

  • Raspberry Pi 2: snap known --remote model series=16 model="pi2" brand-id=canonical

  • Raspberry Pi 3: snap known --remote model series=16 model="pi3" brand-id=canonical

  • Raspberry Pi CM3: snap known --remote model series=16 model="cm3" brand-id=canonical

  • Dragonboard: snap known --remote model series=16 model="dragonboard" brand-id=canonical

  • amd64: snap known --remote model series=16 model="pc-amd64" brand-id=canonical

  • i386: snap known --remote model series=16 model="pc-i386" brand-id=canonical

Build and promotion automation

See UbuntuCore/CoreSnapAutomation .

Promoting snaps to stable

For some cases, the 18 snaps use a special 18 track instead of the default one. This means that for those snaps, instead of channels like stable, candidate, beta, edge there's 18/stable, 18/candidate, 18/beta, 18/edge - especially for gadget snaps. Before attempting promotion from one channel to another, always make sure that you are specifying the right track and channel. Otherwise one might promote a core18-targeted snap to the stable channel used by core16 devices. Look at the list of revisions and available tracks/channels before promotion.

The edge, beta and candidate snap promotions are handled by our automation (see above section). Manual promotion is only required when moving a snap from candidate to stable, in which case the following instructions need to be followed. NOTE! For core18/core20/core20+ snaps, always coordinate first with the snapstore team before promoting to stable. Base snap releases always cause huge spikes in bandwidth consumption so we need to make sure there are no other releases/operations in progress that could cause infrastructure issues.

Another important thing to keep in mind is that all base snap releases are released using progressive releases (phased upgrades). So, in fact, only after approximately 36 hours (15% increment roughly every 6 hours) a new version is available for all users in the respective <track/>stable channel.

Releasing a new snap to stable:

  • Get the list of revisions that are supposed to be promoted for this snap (can be through the snapcraft dashboard).
    • Remember that there's a separate revision number for every architecture.

  • Run export SNAPCRAFT_EXPERIMENTAL_PROGRESSIVE_RELEASES=y to enable progressive releases (note: might be no longer needed after becoming non-experimental).

  • Run this command on the same terminal: snapcraft release <snap_name> <revision> <track/>stable --progressive 10

    • <track/> depends on whether the snap you are promoting has a specific track you want to use, like 18/.

    • Example #1 (core18 snap): snapcraft release core18 1234 18/stable,18/candidate --progressive 10

    • The progressive release value can be anything, but we tend to start from 10%.

Image automation

As with every Ubuntu flavor, Ubuntu Core has standard daily builds enabled for UC16, UC18 and UC20 on cdimage. Daily images are being produced for different stability levels and published to their respective directories. Those daily images are only meant to be used for testing and development purposes and are never actually advertised or 'promoted'. Note: the same infrastructure is used when officially releasing a new image, using the 'stable' channel images.

New image builds can be requested by contacting members of the ubuntu-cdimage Launchpad team. It is not possible to do it via the ISO tracker (as it is the case with most other Ubuntu flavors).

Releasing a new ubuntu-core image

See UbuntuCore/ReleaseProcess .

Adding new Ubuntu Core platforms/images

See UbuntuCore/AddingImages .

Adding new Ubuntu Core Appliances

Ubuntu Appliances are basically Ubuntu Core images with some special snaps preinstalled and preconfigured. Such images can be loaded on the given platform (Pi's mostly right now) to turn it into a home/office appliance. Currently those are built on ubuntu-cdimage and based on UC18.

See UbuntuCore/AddingAppliances .

Useful Documentation

UbuntuCore/Development (last edited 2024-03-18 13:14:35 by alfonsosanchezbeato)