Ubuntu Core components

Ubuntu Core is built from the same components as the corresponding Ubuntu LTS release, such as Ubuntu 22.04 LTS (Jammy Jellyfish) and Ubuntu 20.04 LTS (Focal Fossa) for core22 and core20 respectively.

The kernel, boot assets, runtime environment, applications and device enablement capabilities are all delivered as snaps that are controlled by snapd (the snap daemon), which is itself packaged as a snap.

See below for how these elements combine in Ubuntu Core:

Volume layouts

The storage layout of the generated image used to install Ubuntu Core (as shown above), and the resultant storage on the device after installation (shown below), is described by the gadget snap and its associated gadget.yaml file.

Ubuntu Core 2x typically uses the following storage partitions:

  • ubuntu-seed (role: system-seed; read-only, vfat-formatted): contains the configuration for the first-stage/recovery boot loader and at least one recovery system. This is a set of snaps (base, kernel, gadget and application snaps), together with a model assertion and snap assertions, that define the device and from which the device can be recovered or reinstalled.
  • ubuntu-boot (role: system-boot; read-only, ext4 or vfat): contains the second-state/run bootloader and unpacked kernel(s) to boot and with initramfs which decrypts the ubuntu-data and ubuntu-save partition.
  • ubuntu-save (role: system-save; writable, ext4): stores device identity backup data and data to facilitate recovery or re-install. This partition is mandatory on encrypted systems where it should have a minimum size of approximately 20+MB to handle volume and file system creation.
  • ubuntu-data (role: system-data; writable, ext4): stores user and system data. This partition is often minimally sized in the image but extended during device initialisation to use all the space available.

core-partition-layout (1)

Boot process

The system boot process:

  • verifies the bootloaders and kernel signatures
  • measures the above and the kernel command line with the TPM
  • on top of the above trusted set the snapd initrd code measures the snap device model
  • snapd then separately verifies other snaps with their assertions as needed

snap-bootstrap is the main executable that is run during the early initramfs booting stage of UC2x. It has the following responsibilities:

  1. Mounting selected partitions from the disk that UC2x is on. Partitions include data, system-boot, seed, and if present, save (optional on unencrypted devices).
  2. As part of mounting those partitions, snap-bootstrap may perform the necessary steps to unlock any encrypted partitions such as ubuntu-data and ubuntu-save (see Full disk encryption).
  3. After unlocking and mounting all such partitions, snap-bootstrap then chooses which base snap is to be used for the root filesystem of userspace (the root filesystem of the initramfs is just a static set of files built into the initramfs and is not the final root filesystem), and mounts this base snap file.
  4. snap-bootstrap then chooses which kernel snap is to be used to mount and find additional kernel modules that are not compiled into the kernel or shipped as modules inside the initramfs or otherwise loaded as DTBs, etc.
  5. snap-bootstrap will then mount the ubuntu-data partition such that either the writable components of the root filesystem come from this actual partition, or if the mode the system is booting into is an ephemeral system such as install or recover, will mount a temporary filesystem for this.
  6. snap-bootstrap on kernel and base snap upgrades will also handle updating bootloader environment variables to implement A/B or try-boot functionality.
  7. snap-bootstrap then finally may do some additional setup of the root filesystem such as copying some default files for ephemeral system modes such as recover.


There are several layers of isolation that make snaps strictly confined.

The first layer of isolation is logical: a snap is a self-contained file system mounted on a Linux system. Snaps are immutable with least privileges by default, which make it easy to build tamper-proof devices.

Isolation mechanisms rooted in the Linux kernel add an additional layer of isolation through Cgroups and Namespaces:

Cgroups Limit the amount of resources the process confined to a snap can consume (CPU, memory, network bandwidth, and so on). Namespaces Make sure processes in a snap see their own personal view of the system (files, processes, network interfaces, hostname, and so on).
AppArmor Allows system administrators to restrict snap capabilities with default security profiles that can be extended. Seccomp Isolates processes running in a snap by limiting the system calls they are allowed to make.

See Security and sandboxing for further details on how confinement is implemented.

Ubuntu Core snaps

uc2x block diagram

The following components make up Ubuntu Core:

  • snapd is the system daemon that supervises all other snaps on Ubuntu Core. It exposes a REST API that makes Ubuntu Core appliances IP-addressable by default. This API facilitates device management.

  • application snaps define the functionality of an embedded device and are confined with all their dependencies to their own sandbox. Interfaces to other applications or to the system must be explicitly defined.

  • system snaps are considered critical to the function of the system, and include the snaps for network-manager, modem-manager and bluez.

    Related to system snaps, but in a less critical category, are snaps that enable device capabilities like audio, power and disk storage, alongside Docker container orchestration and virtualisation capabilities, including Microk8s and LXD.

  • boot assets come from the gadget snap and include board-specific binaries and data, such as bootloader, device tree, configuration files, and cloud-init configuration for edge virtualisation use cases. The gadget snap is typically issued and signed by board OEM/ODMs.

  • base snap holds the execution environment inside which applications run. It also serves as the root file system for Ubuntu Core images. Core snaps include basic Ubuntu 2x.04 LTS packages.

  • kernel snap holds the kernel image and associated modules. It will also contain an initial ramdisk image for system initialisation. Firmware and device tree files can optionally be packaged here. The kernel snap can be updated but it cannot be swapped.

The above snaps are combined using the ubuntu-image tool to create the Ubuntu Core installation image.



Ubuntu Core exposes a built-in REST API for secure device command and control. Authenticated and authorised clients can perform software management and configuration tasks on their Ubuntu Core devices remotely. Devices running Ubuntu Core can be configured remotely via the REST API.

See Snaps in Ubuntu Core for a general overview, and see below for details on the UC2x specific configuration.


I think the partitions are named a little bit differently now. For example on the uc20 pi gadget we have ubuntu-save, ubuntu-data, ubuntu-seed and ubuntu-boot. https://github.com/snapcore/pi-gadget/blob/20-arm64/gadget.yaml#L31

Thanks! And yes, you’re right. As with the snap reboot command, these things have changed recently. I’ve updated the partition names. They’re also referenced (and now updated) in Full disk encryption. It might be worth extracting a separate page on partitions rather than the current duplication but I wasn’t sure what more than page could include.

1 Like

Why does the RPi partition layout not show the gadget snap in there along with the other three snaps in that first partition?

In talking about components, one reads:

" boot assets include board specific binaries and data, such as bootloader, device tree, configuration files, and cloud-init configuration for edge virtualisation use cases. This is also held within the gadget snap, which is typically issued and signed by board OEM/ODMs."

The word “also” (as in, “This is also held within the gadget snap”) is confusing as it suggests you’ve already described the gadget snap, and are now discussing additional content, but that doesn’t seem to be the case, so that sentence is definitely a little puzzling. Why not just have a bullet point describing what is in the gadget snap?

Thanks. I’ve tweaked that paragraph. Our gadget snap documentation in general could do with an overhaul.

1 Like

This page claims that FDE is “x86-only, with ARM to follow”, while this page, https://ubuntu.com/core/features/full-disk-encryption, insists FDE is for both x86 and ARM.

This page distinguishes between “application snaps” and “system snaps” in the bullet list, but it’s not clear the fundamental difference between the two, unless it’s just philosophical.

it is legacy … we used to have things like pulseaudio, bluez, NM, udisks2 as “system snaps” to bring you some extra system integration … most of these have been dropped …

1 Like

In that case, is anything technically a “system snap” anymore? If so, which ones?

It still seems awkward that the list of things that make up UC20 does not explicitly include the gadget snap, particularly in the graphics. Are those simply old graphics that were never updated to show the gadget snap along with the other three?

There is some disagreement in the Field IoT group as to whether there is an official definition for “system snap.” If you mention it here (and I think you should), I would specifically mention that that category includes network-manager, modem-manager and bluez.

That’s a good point. Thanks for mentioning it - I’ve updated the doc.

I think the diagram showing the installer image partition should also show the gadget snap. Is there some reason it’s not included in that picture?

Reminder that the category of “system snaps” currently includes only modem-manager, network-manager and bluez. THings like microk8s and LXD are not considered system snaps.

1 Like

For clarity, I might re-do that first graphic so it has the same structure as the second one and they match up visually. That is, have the first partition layout just be the same as the second one, but everything past ubuntu-seed be “empty/zeroes”. If you do that, then it is instantly obvious how the pre-install layout turns into the post-install layout.

I think the “Ubuntu Core Snaps” and “Volume Layout” headings should be swapped.
Also the hyperlink name “System snaps” should probably be changed to “Ubuntu Core Snaps”; I’d do it the other way around but System snaps is already a term of art in the lingua franca of Core.

1 Like

Thanks for your suggestions. I’ve moved the sections around to try and follow the boot sequence.

1 Like