Hello there,
Is it possible to “undo” an action like this:
snap refresh --ignore-validation $SNAP_NAME
I tried by rerunning
snap validate --enforce --refresh $VALIDATION_SET
And even by changing the validation-set to a different sequence. Both keep the refreshed snap at their last version.
I would like to “undo” the --ignore-validation flag.
Using snapd 2.63 on an Ubuntu Core 22 device
@ogra do you have an idea?
You just need to refresh back to the revision that’s specified in the validation set. If the channel your device is tracking still has the newer revision published, then you can use --revision to refresh to the older (valid) revision. Ex.
snap refresh --revision $VALID_REVISION $SNAP_NAME
This should bring your device back into compliance.
And actually, you don’t really need the --revision, if you re-run snap refresh $SNAP_NAME, then snapd will trigger a refresh to the revision specified in the validation-set.
Note – this currently only works for required snaps in validation sets. There’s a bug with optional snaps which is currently being worked on.
You are totally right.
I had tried to do a “general snap refresh” but not one for a specific snap. Indeed, this reverts the snap to the one listed in the validation-set. Thanks a lot!
Is there any way to undo installing snaps “dangerously”?
If I do snap refresh $SNAP_NAME it tells me the snap is not known to the store. It says I can use --amend to proceed anyway, but that doesn’t work.
The only way I figured out now is SCPing the snap + assertion that I downloaded from the store and doing
snap ack $SNAPNAME_$SNAPREVSISION.assert
snap install $SNAPNAME_$SNAPREVISION.snap
But this is not so pretty. Would be awesome to just have a single command that would throw away all dangerously/sideloaded snaps in one go and “reset” the device to being clean.
How exactly does it not work? Do you get an error message?
~$ sudo snap install ssi-outdoor_29.snap --dangerous
ssi-outdoor 5a94585 installed
~$ sudo snap refresh ssi-outdoor
error: local snap "ssi-outdoor" is unknown to the store, use --amend to proceed anyway
~$ sudo snap refresh --amend ssi-outdoor
error: snap "ssi-outdoor" not found
It seems like the dangerous install is breaking the link between the store. Maybe that’s expected? But how do I get it back?
I thought it worked to manually “properly” install the snap with acking it first:
~$ snap ack ssi-outdoor_35.assert
~$ snap install ssi-outdoor_35.snap
ssi-outdoor f5d161c from Clay Owner (clay-owner-saltosystems) installed
~$ snap refresh ssi-outdoor
error: snap "ssi-outdoor" not found
But no luck.
You might need to tell it explicitly what store to use (IIRC there is an environment var you can set in the command to force the correct store), perhaps --amend uses a separate code path here…
Ok, yes, that helps.
Now, how would I do the same over the snapd REST API?
Sure, uninstall the side-loaded snap and re-install from the Snap Store. You can’t refresh dangerous side-loaded snaps because they have no provenance, being effectively unasserted (i.e. they have no associated snap-revision). This is why the flag used to install unsigned snaps is named --dangerous. This was a purposeful design decision, and is not likely to change.
You can refresh dangerously side loaded snaps just fine using the --amend switch, like discussed above, but apparently you have to force the store via env variable for this (I assume snapd simply defaults to the global store for --amend) …
But I don’t think there’s any way to use the REST API like this since you can’t hand the env var to it…
Might be worth filling a feature request for that, but I’m not sure if the defaulting to the the global store isn’t actually on purpose by design…
So I have retried this and now the --amend works without specifying the store.
I cannot reproduce the --amend leading to application not found anymore.
Will update when I re-see the issue, but for now I will try to implement the API call with --amend and see if it serves my purpose.