Ubuntu-image command crashed

Sorry, I replaced some strings in the assertion, something like:

type: model
authority-id: xxx
series: 16
brand-id: xxx
model: xxx
architecture: amd64
base: core18
classic: false

  • default-channel: latest/edge
    id: xxx
    name: xxx
    type: gadget
  • default-channel: 18/stable
    id: pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza
    name: pc-kernel
    type: kernel
  • default-channel: latest/edge
    id: xxx
    name: xxx
    type: app
  • default-channel: latest/stable
    id: sLCsFAO8PKM5Z0fAKNszUOX0YASjQfeZ
    name: docker
    type: app
    store: xxx
    timestamp: 2021-03-09T10:10:10Z
    sign-key-sha3-384: xxx

are you trying to build a uc18 or uc20 image?

I’m going to build uc18 for now and uc20 in near future :slight_smile:

unfortunately the model assertion for uc18 is different than for uc20, see https://ubuntu.com/core/docs/reference/assertions/model for uc18 style model assertions and see the “Model definition” header at https://ubuntu.com/core/docs/uc20/release-notes for uc20

oops, it may be a feature to verify if an assertion follow the correct syntax. :slight_smile:

Thanks @ijohnson, this issue came from the other question here, Build image with OS/snapd/kernel snaps from stable channel. Bringing the same question from there, is it possible to build image with kernel snaps from stable channel but gadget from edge channel if using uc18? Thanks. :slight_smile:

For UC18, I am not sure, but that’s precisely why we allowed it for UC20

1 Like

Quick questions, I guess I can use --extra-snaps to use snap files to work around the issue for uc18? Can I use --cloud-init parameter for core20 with ubuntu-image command? The error is:

ubuntu-image: error: base: core20 model assertion detected, the following features are unsupported: --cloud-init


nope … you can not … i know the cloud.cfg file needs to be somewhere inside your gadget snap now but i do not know the details where exactly it has to be or if there is a specific name required … ian might know though …

Got it, great to know before preparing the upgrade to uc20, thanks @ogra!

For cloud-init with UC20, you have the following options:

  1. Put it in the root of your gadget snap as cloud.conf
  2. Put it in the ubuntu-seed partition at <ubuntu-seed>/data/etc/cloud/cloud.cfg.d/ with filenames ending with .cfg
  3. Provide through external filesystems that cloud-init will by default searches, for example the NoCloud datasource will search for drives labeled CIDATA with files in the root labeled meta-data and user-data
  4. Put it in ubuntu-seed, and let snapd filter out unsafe configuration from the config so only certain keys are allowed

Option 1 is always allowed with UC20, regardless of model assertion grade. Option 2 is only allowed with model assertion grade dangerous Option 3 is allowed only with model assertion grade dangerous and signed (so this does not work for secured). Option 4 is currently being worked on and will be allowed for model assertions grade signed and dangerous.

Here’s a table of allowed cloud-init methods vs the model assertion grade

Method Dangerous Signed Secured
Ubuntu-seed :white_check_mark: :x: :x:
NoCloud CIDATA :white_check_mark: :white_check_mark: :x:
Gadget cloud.conf :white_check_mark: :white_check_mark: :white_check_mark:
Ubuntu-seed filtered :construction: :white_check_mark: :white_check_mark: :x:

Amazing, thanks for the details @ijohnson :slight_smile:

I had a go at trying to implement the “cloud.conf in gadget snap” option, and am not having much luck. My model is set to grade: dangerous.

I can see that the cloud.conf from my gadget snap has been copied to /etc/cloud/cloud.cfg.d/80_device_gadget.cfg, but it isn’t obvious that any of the directives have been run (I tried using runcmd and write_files).

On the first boot (after the initial unpack/setup boot), the only reference to “cloud” I see in the journal is:

Mar 29 02:33:04 ubuntu snapd[1880]: devicemgr.go:891: System initialized, cloud-init reported to be in disabled state, disabled permanently

i cant find a referenc for this anymore (probably someone told it to me on IRC) but i happen to remember that the filename needs to be cloud.cfg in the gadget case and that you need a “nocloud” section in it (i could mis-remember or it might be outdated info tough) …

I’d originally tried with cloud.cfg, which doesn’t work. When I switched to cloud.conf (as documented in @ijohnson’s post), I could see that the config file was being copied out of my gadget snap. And the snapd code is definitely looking for that file name:

I’ll have to look more into the nocloud thing. From a brief read of the docs, that seemed to be about feeding cloud-init data into the system from some external source. Here, the config has already been copied to /etc/cloud by snapd.

1 Like

Can you share the cloud.conf you tried using? I think it’s a formatting issue in that it only works if you format the cloud.conf a certain way

This is the cloud.conf file I was using:

The write_files stanza is to a location that is made writable in the boot file system. The runcmd command references a script shipped inside one of the snaps required by the model definition.

The cloud-init config that we have confirmed to work is formatted like this:

datasource_list: [NoCloud]
  - name: ubuntu
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    lock_passwd: false
      - "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+5T1gxW1X4bzQs5a858MMMyOb8ZHKlA9EOoCJ1X0B9TdY+Dz37wiGIKQ0pSUJ39wq9gFsF5e/aG0FNcZxkzBwNwWKpZ9efeNHca/8ffKZH97l9MbQL0d+g0p+KVpP9waS3cbcyEmcTXkZZssyWAx7j8DtNI+qVp6ZZ4uPS4uRKRxhI/XwUvQYvtjHCqvZ31+cV1b0cWoRIEVjAyrlGYhAIoADs8lFEDmH1DXwgPtifj1ooPdiwcgYtZcnRuxSSNQFKXY79MhRRfcJCebCRewOPd6xjQGH8z7dbhx+kvJTO0qw7xMh6HOj20xezlEhTCTg3ykk2whodUb+sUjXkdLUULCJgma8v8r2cUKC5ec3iOfLx8esAQOxTgq/PvrUcnzPLSPrvupJV6JhXNoIa2+5XELmTV9CdFHjPiO4YHOQHxi0XayKGOODcT72zI1oc5rMOkU+7B1Lopozd9IrwmswPcZP4oSy4qm5ckHErE2IlL179fRChVEfCK9FBxNluNUZTZ0Nq4s3NDoc+JTotod8JHRTfbLnQBxzccSuJhM1oez6aYQySSpgQhcyItA0OlPdXIR9UhHDq1GFua5vu44OQX8ml4SOyCQlrXUowecptg+Qm12l1a8NspityR9uGgwdWHEkB0P2vvuJuV8ugwY2saqrZu/3eYICLuFsqMJm0w== ian.johnson@canonical.com"

Perhaps you need to include datasource_list: [NoCloud] in your config? I don’t know how cloud-init internally decides if it’s used or not, but all snapd does to decide if cloud-init should be disabled or not is by querying if there is a datasource being used or not.


It works for me. A new user got created by my cloud.conf file. :slight_smile: :+1:

1 Like

Yep. Adding datasource_list to my cloud.conf file seems to fix things. Both the write_files and runcmd directives seem to have been processed.

1 Like