Gadget snaps

doc
8

note that we should obsolete the old style meta/snap.yaml stuff and actually move the document over to use a proper snapcraft.yaml and snapcraft to create the snap.

i started documenting this with a prototype setup for the beaglebone gadget here

1 Like
9

This is not an old style or obsolete. This is what goes inside every snap and that you can find at /snap/current/*/meta/snap.yaml, so when we detail how the gadget snap looks like internally or the snap format more generally, that seems appropriate and good to document.

What we need to do is explain properly how that’s not the same as snapcraft.yaml, and document snapcraft portions of the process when that’s relevant.

10

but we use snapcraft.yaml for all official snaps since a while …
the meta/snap.yaml file comes from a time where we manually called mksquashfs … (and later just switched to “snapcraft snap”) we use a proper snapcraft.yaml with the gadget.yaml in the toplevel of the tree and no meta/ dir at all since quite a while for all official snaps.

effectively since we started auto-builds in august 2016 …

i dont think a user or developer needs to know about the internal meta/ structure specifically in the gadget documentation (this should live in some global “what is a snap” doc instead)

2 Likes
11

Like the kernel snap docu this should be a reference for the whole snap directory layout (e.g. firmware, dtbs, modules?, …).

12

The layout is also listed for this one already, under Setup files. We have plans for handling of dtbs, etc inside the gadget, but right now there’s no special handling of those if I remember correctly, so we don’t yet define their organization as it would mislead into thinking that those would be used somehow.

13

Added documentation about the connections stanza and mentioned that the system nick can be used in the defaults one.

1 Like
14

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 ?

15

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

2 Likes
16
  • 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)”
17

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
18

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
19

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

20

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?

21

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?

22

slot and plug is still work for core20 gadget ?

23

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?

24

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.

25

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

1 Like
26

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

27

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.