Gadget snaps

Just for completeness…

where we used to use 99T7MUlRhtI3U0QFgl5mXXESAiSwt776 for defaults (which is the core snap ID), we can now just use the system keyword, is that correct ?

yes, it’s also recommended because of the coming core18 changes

2 Likes
  • This appears to be in the wrong place in the sequence. It is after “volumes” section but it should probably after the “defaults” section.
  • It is slightly unclear because it says “Default options” but what I think it is referring to is the defaults section. Maybe reword to say: “Configuration values set in the defaults section are only realized when the specified snap is installed or its configure hook runs. (system values are set immediately)”

This important point could be more precisly stated. What for example is a “Device snap”? I think the intended meaning may be: “Interface connections configured in the connections section are executed on the device’s very first boot only. Later changes to this section, that is, changes added to the device at run time through gadget refreshes, are not applied.”

2 Likes

It might be useful to state whether it is valid to provide default configuration values for snaps that are not in the original image but that may be used later if the specified snap is actually installed.

1 Like

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

Hi,

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 https://github.com/snapcore/pc-gadget $ 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: :

https://github.com/ogra1/custom-pc-gadget/

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

Kevin

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:

https://ubuntu.com/core/docs/gadget-snaps#heading--kernel

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.