I’m attempting to install a gadget snap onto a fresh Ubuntu Core 16 image. However, during the installation, the following error message continues to cause the installation to fail.
- Mount snap "picocell-gateway" (unset) (cannot replace signed gadget snap with an unasserted one)
Additionally, when looking at the log files,
sudo journalctl -u snapd
, no additional information is give.
Feb 22 18:23:35 H3RPB02 /usr/lib/snapd/snapd[1323]: daemon.go:176: DEBUG: uid=0;@ POST /v2/snaps 150.42349ms 202
Feb 22 18:23:35 H3RPB02 /usr/lib/snapd/snapd[1323]: taskrunner.go:353: DEBUG: Running task 552 on Do: Prepare snap "/tmp/snapd-sideload-pkg-233963271" (unset)
Feb 22 18:23:35 H3RPB02 /usr/lib/snapd/snapd[1323]: taskrunner.go:353: DEBUG: Running task 553 on Do: Mount snap "picocell-gateway" (unset)
Feb 22 18:23:35 H3RPB02 /usr/lib/snapd/snapd[1323]: task.go:303: DEBUG: 2018-02-22T18:23:35Z ERROR cannot replace signed gadget snap with an unasserted one
Feb 22 18:23:36 H3RPB02 /usr/lib/snapd/snapd[1323]: taskrunner.go:353: DEBUG: Running task 552 on Undo: Prepare snap "/tmp/snapd-sideload-pkg-233963271" (unset)
Feb 22 18:23:36 H3RPB02 /usr/lib/snapd/snapd[1323]: snapmgr.go:807: Reported install problem for "picocell-gateway" as 7f600242-17fd-11e8-b87e-fa163e839e11 OOPSID
Feb 22 18:23:36 H3RPB02 snapd[1323]: 2018/02/22 18:23:36.885293 snapmgr.go:807: Reported install problem for "picocell-gateway" as 7f600242-17fd-11e8-b87e-fa163e839e11
It should be noted that I’m attempting to install this from a mounted USB drive as the snap hasn’t been initially approved by the Snapcraft administration. Please reference below for my snap version
snap 2.23.6
snapd 2.23.6
series 16
kernel 4.4.0-112-generic
I’ve investigated other posts on the forum that have similar symptons however I don’t believe that the problems are similar.
An image is defined in its model assertion (signature of the creator, list of snap packages to include) and by the gadget.yaml (partitioning, bootloader setup, default configuration). In that design replacing the gadget.yaml with a random one can not work. If you want to use your own gadget snap you need to create your own image, the gadget can not be replaced at runtime on a signed image.
My current understanding of gadget snaps is that developers can upload them
to the canonical store and then install them on other systems. It seems
like the method above implies that the only way for developers to integrate
their gadget snaps are by creating their own images even though we can
upload gadget snaps to the canonical store and then download them in other
images. Is there a difference between installing a gadget snap from a local
snap versus installing a gadget snap from the store in regards to the
gadget.yaml? I have no problem generating a custom image however I’d like
to add my gadget snap to an already installed Ubuntu Core 16 image.
The first half of this assumption is correct, the second half sadly is not. If you upload the gadget to the store it gets signed with the uploader key. This key needs to match the key that signed the model assertion to have a fully validated image. The combination of model assertion and gadget makes up the actual image definition (the model describes what snaps are included in the image. The gadget defines defaults, partitioning and bootloader of the image).
While you can randomly combine model and gadget in a local build using the --extra-snaps option of ubuntu-image (as long as the gadget name matches what is in the model assertion) for development and testing, such an image would not validate on first boot.
It is still functional for local (developer) operations but would not be able to do any verified actions with the store.
This is a security feature, so you can not just create an image with a malicious snap included that is called “validated-pi3-canonical.img” or “dell-secure-pc.img” and pretend it is the real thing.
If you want to run with your own gadget building your own image is the only way here, there is no way to cheat snapd into using an unsigned or wrongly signed (with a key not matchng the model one) gadget on a runnng system. Though if you find such a way somehow, that would be a serious flaw in Ubuntu Cores security model that you should definitely report as a bug
