Ubuntu Core vs Yocto (and ResinOS)?

Hi there,

I’m trying to choose a platform for an IoT Hub. We have thousands of IoT hubs currently running Ubuntu Server on Gigabyte Brix and Raspberry Pi. We occasionally get root filesystem corruption and need to send out a new hard drive or SD card which is a serious problem that needs to be addressed.

I’m looking at Ubuntu Core and Yocto (and ResinOS also looks great). What would you say are the advantages/differences of Ubuntu Core over Yocto (and ResinOS)?

I’m currently leaning towards Yocto as we maintain the units through OpenVPN, Ansible and Docker and it seems like Ubuntu Core would add an entirely independent cloud service to manage devices, which we don’t need. Or is this service optional?

From what I understand the key differences are:

  • ubuntu-core is more of a higher level package, trying to tie you into the cloud services and container type but easier to get started if you don’t need to build your own solution. It can be harder to customise if you need to build a custom one that will only connect to your own OpenVPN and device management, bypassing the Ubuntu cloud services.
  • Yocto is more low level, providing the tools that allow you to build exactly the image file you need. It is supported by a number of companies offering Yocto based distributions so you can still get off the ground relatively quickly.
  • ResinOS is an example of one of those Yocto based distributions, it is with a few modifications/additions, with their own optional cloud services.

Is that a fair comparison? - What are your thoughts?

UbuntuCore has builtin update/rollback functionality (it will even automatically roll back to the former version if a kernel or rootfs update failed)

In UbuntuCore apps are delivered as snap packages to the system which also offers you the same upgrade/rollback features along with secure app separation (apps can only see parts of the system (or content of other snaps) through interfaces you control)

UbuntuCore gets 5 years of security support for all bits delivered in the rootfs (and if you use an official kernel snap also for the kernel), like the normal Ubuntu LTS releases.

AFAIK yocto does not have any of this (while there are upgrade solutions you can implement, there is no “standard” way of doing upgrades, nor is there any standard way for roll back etc, you’d have to pick your poison and hope for the best here), you have to bake your applications into the rootfs at build time and can not atomically update single bits of it. Apps will not be confined or separated from each other at runtime and a bug or mis-configuration in your app can allow an attacker to take over the system (this is not possible with Ubuntu Core due to the app/service confinement)

There are probably a million more differences that didnt come to my mind while typing this :slight_smile:

Note though, that getting an unbiased opinion on the snap/UbuntuCore forum for such a question is indeed rather unlikely :wink:

That sounds really great, thank you for that.

I’m wondering about the dependence on a Ubuntu SSO account, etc. If I am building 2,000 systems using Ubuntu Core, are there any limits I should be aware of? - are there any license costs involved?

Also, is there any way to use Ubuntu Core without a reliance on an SSO account? - maybe some build tool where I can add a custom OpenVPN setup and my own SSH keys during the image build process?

@hackeron did you end up getting any answers to your questions? i am in a similar situation as you

it really depends what you do with the image, you do not need an account at all to run the image.

if you get along with using the existing gadget snap and existing kernel snap from the store for your device, you can add any additional snap to it you want … if in turn you create a snap that offers a REST api to i.e. set network cofiguration etc you can get along with whats there without any cost …

if you need your own gadget snap, kernel snap or want to make use of the snapd interface (to install snaps at runtime or manage config options of snaps on the fly etc) you will need to buy a brand store.

the SSO accounts on-device are only needed for interactive logins, which you most likely dont need for i.e. an appliance image.

if you build your own images you need exactly one SSO account for signing the model assertion (image description, and list of pre-installed snaps) but nothing else.

Thank you for the info Ogra

One clarification, you said

if you need your own gadget snap, kernel snap or want to make use of the snapd interface (to install snaps at runtime or manage config options of snaps on the fly etc) you will need to buy a brand store.

Isn’t it a possibility to create a custom gadget or kernel snap and deploy it to the public store and that way you don’t need a brand store? or as soon as you need a custom image you need the brand store?

the review tools would block any kernel or gadget uploads to the public store as long as they do not come from a canonical employee (this is a security/store policy atm).

there is work being done to losen this policy a bit for non-
commercial images for developer boards (i.e. beaglebone, raspberrypi, rockpi etc), but this is not final (it could be that there will actually be a public brand store for such gadgets/kernels and a community team similar to snapcrafters can do uploads there, but it could also be a completely different solution)


As a summary for others:
For commercial products you have to either use an official ubuntu-core image or pay for a brand store for a custom image and (if i’m not mistaken) for a Canonical trademark license. Something to keep in mind for anyone else like me considering Ubuntu Core vs Yocto in a commercial setting

That was exactly what i was trying to find out

Thank you Ogra

well, technically you can build the whole image from local snaps (except core/core18) but lose any upgradeability for kernel or gadget … (and the device wont securely register a serial to be signed)

else we wouldnt be able to do any development (or at least development would be dog slow :slight_smile: )

makes total sense. i’m not complaining, just documenting it :slight_smile:

Why would you lose the ability to upgrade the kernel and gadget? The image I use is built using local snaps and the kernel has been updated multiple times.

you can indeed manually snap install --dangerous ... if your kernel was originally installed from a local snap … what i meant is automatic updates, security fixes from the store etc.

Sorry for pulling this up again.

As a hardcore Yocto user I have a few questions related to OpenSource compliance and Ubuntu Core. One of the benefits I see in Yocto is the fact that it pulls all sources from the internet and perform a local build. In this case as a vendor I can provide a written offer and if a customer asks for the source code this can be provided to the customer.

In a second step I can easily process the complete source code with tools like scancode, fossology or SW360 to get both licensing and copyright information.

The result of processing all the source must go into the image to provide the user of the image with the possibility to check all licenses in his device and the corresponding copyright information.

Are there any ready to use workflows in snapcraft/Ubuntu Core?

Ubuntu Core is completely built from deb packages from the Ubuntu archive (well, for core16 there was a PPA in use but the debs all had proper copyright files nontheless) … debian packages ship their copyright files in /usr/share/doc/<packagename>/copyright.gz … these are untouched in a core build and you should be able to just parse them.

Hey @ogra, thanks for the reply, I agree the copyright information is something Debian and therefore Ubuntu are doing a really good job in. I am not aware of a system which is comparable.

I am not yet very familiar with snaps and snapcraft. I love the concepts and ideas behind them. I just try to get an idea how to apply my current workflows to them. I tried to extract the copyright information from my chromium snap I recently installed:

sudo cp /var/lib/snapd/snaps/chromium_937.snap /tmp/
cd /tmp
sudo chown deegech chromium_937.snap
mkdir chromium
cd chromium
unsquashfs …/chromium_937.snap
cd squashfs-root
find . -name “copy

Which is in this case seems to be a hen egg problem because for chromium not an deb package is used for deployment AFAIK.

How would you deal with requirement to distribute the source code and the required scripts which are used to create them. Do you have anything like this for the Raspberry PI Ubuntu Core image?

well, i was answering in context of ubuntu core itself.

if you install random snaps on top of it, this is up to the packager, the store does not enforce any license info simply because it allows proprietary software as well as opensource. as a packager you can pick the license in the store UI and it is up to you to also include it in your binary to fulfill any copyright/license requirements but we do not enforce anything here …

for anything included via the stage-packages or build-packages directives in snapcraft.yaml the same thing as for the core snap applies, their copyright files get automatically shipped from the .deb packages…
but since snapcraft gives you all possible freedom, there is no requirement to use a dependency as a deb package, you can build any bit of your snap from upstream sources if wanted/required. so it is again up to you as a packager to take care to include the matching license files.

now, if you require full control over what is ending up on your devices (to fulfill corporate requirements or whatnot) you can buy a brand store that your devices will use. this gives you full control over what goes on which device and what is visible to them in your store.

Thanks @ogra for this explanation.