Gadget snaps

Thanks for this. I’ve moved the warning and updated the text.

Hi: The example of the prepare-device hook above shows setting registration.body snap config var for the gadget. I am not familiar with this var, and I know authentication works without it. Should this be removed?

EDIT: I just found that if you set registration.body in the prepare-device hook as shown, it does put the result in the serial assertion. Is there a use case for this?

slot and plug is still work for core20 gadget ?

I tried this with a private snap installed as part of a model assertion, and couldn’t get the ID. These aren’t published to the store. It’s problematic for me, because I’m trying to connect the network-control interface on first boot and can’t seem to use the snap name in lieu of the snap-id which doesn’t exist. Am I missing a mechanism detail somewhere?

Hi! We’ve got a case where the system failed to boot because an extra partition was inserted between ubuntu-save and the ubuntu-data partitions. This is not supported at the moment as explained in the forum thread, so the solution is to place any extra partitions before the ubuntu-boot one.

This is probably something that should be mentioned in the documentation: in the volumes/structures map, ubuntu-data needs to be the last partition and no extra partitions can be inserted between the sequence ubuntu-boot - ubuntu-save - ubuntu-data: if extra partitions are required, they need to be declared before ubuntu-boot.

Thanks for clarifying this - I’ve updated the volumes mapping sub-section to include your text.

1 Like


Looks like we’ve got a contradiction here:

The volumes: section is initially listed as “required”

But later described as “optional”

It looks like none of the tooling objects if you leave the volume out, so this may be relevant to Classic use-cases, but in any case these should be consistent

I am trying to build a gadget snap so that I can install some drivers but I can’t get the sample version to create a snap. I was hoping to start with a working sample version and add my driver installation steps. I followed the steps here:

I modified the steps to use the pc-gadget instead of the pi-gadget. This is what I did:

$ git clone $ cd pc-gadget $ git checkout 20 $ snapcraft

It fails to build the snap. It fails with the following error:

the package grub-efi-amd64-signed has unmet dependencies: Run the same command again with --debug to shell into the environment if you wish to introspect this failure.

Why does this fail? How can I fix it? Am I doing something wrong?

I am trying to evaluate whether or not we can use Ubuntu Core. I have a snap for our firmware working and I am using ubuntu-frame to output to 2 monitors but now I need to install drivers for a special touch screen monitor that we use.

i’m working on a more generalized set of gadgets for customization that simply re-use the existing gadgets as stage-snap’s without re-building anything to avoid exactly these probs… feel free to be my guinea pig :wink: :

1 Like

Thanks for this. I am using Ubuntu Core 20 so I changed the stage-snaps: to pc/20/stable. I also changed the base from core22 to core20. When I change the base to 20 the snap no longer builds. I get this error message:

Issues while validating snapcraft.yaml: The ‘hooks/prepare-device/environment/MODEL_APIKEY’ property does not match the required schema: ‘’ is not of type ‘number’ or ‘’ is too short


oops, sorry, i have not done a core20 branch yet (and will not get to look into that today) … there might be a few more changes needed …

OK. Let me know when you have something.

I’m not sure how it’s supposed to be fixed because of the “this is a read-only copy” on the other side, but the “system options” link here is broken:

It points at the topic on this forum here:

But the docs page is rendered from Gadget snaps - Ubuntu Core docs - Ubuntu Community Hub I believe? That’s where the “Help improve…” link points… but then that says it’s a read-only copy! :confounded:

Thanks so much for letting us know. I’ve just fixed this. The problem is that these two pages are identical, apart from their relative links, and this is the canonical copy so that edits aren’t copied back-and-forth. This isn’t a great solution and it probably makes more sense to move this to Ubuntu Core docs only.

I don’t believe that size is optional in a gadget.yaml (anymore?) Attempting to pack a gadget snap with size omitted for some bare part in the gadget.yaml yields:

dilyn@Ares:~/work/canonical/iot-field/gadget-snaps -> snap pack squashfs-root/
error: cannot pack "squashfs-root/": invalid volume "nezha": invalid structure #0 ("spl"): missing size

Relevant snippet:

    schema: gpt
    bootloader: grub
      - name: spl
        type: bare
        offset: 131072
        # size: 65536
          - image: nezha-boot0_sdcard_sun20iw1p1.bin
      - name: ubuntu-seed
        role: system-seed
        filesystem: vfat
        type: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
        size: 800M
        offset: 40M
          - source: grubriscv64.efi
            target: EFI/boot/grubriscv64.efi
      - name: ubuntu-boot
        role: system-boot
        filesystem: ext4
        type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 800M
          - source: grubriscv64.efi
            target: EFI/boot/grubriscv64.efi
      - name: ubuntu-save
        role: system-save
        filesystem: ext4
        type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 16M
      - name: ubuntu-data
        role: system-data
        filesystem: ext4
        type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 1M

      runtime-timeout: 16s
      shutdown-timeout: 1m

@degville could you please mention that the cloud-init is only suggested for development and we strongly recommend not using it for production since it is essentially designed for cloud based systems and super powerful in a way that a developer can customize the underlying OS heavily. Also, it introduces some additional delays while booting the system which impacts overall boot time of the device which is an important topic for the embedded systems.

@dilyn Thanks for raising this. In the top-level of structure, it does say size is required, but you’re right that later for content is implies it’s optional (I’m guessing this is what you’re referencing?). I’ve now removed this.

@bugraaydogar Thanks for letting me know about cloud-init. I’ve updated the cloud-init entry to hopefully make it clear that its use is not recommended for production devices.


Hi we have just come across the volume “min-size” property and noticed its not mentioned / referenced in the documentation. But this has really helped us when trying to update a gadget in which we would like new devices to have a larger partition size but while also being compatible with the devices that already exist.

Thanks Kris

Hello! Thanks for letting us know. I’ve made a note to ask the team about the proper specific definition for min-size and make sure this is added to the doc. I’ll update this post when it’s done.