refreshing with --stable on core18 image tries to switch tracks and fails

[Paul Larson]

I've tested this on dragonboard, and on pi3 with the recent core18 images, but I have no reason to believe it's limited to those devices.

Here's an example:
$ sudo snap refresh --stable pi-kernel
error: cannot refresh "pi-kernel": cannot switch from kernel track "18-pi3" as specified for the
       (device) model to "stable"

$ sudo snap refresh --stable pi
error: cannot refresh "pi": cannot switch from gadget track "18-pi3" as specified for the (device)
       model to "stable"

In this case, I just want to ensure that it's on the current stable. Note that I never actually told it to change to a different track. I want it to remain on the current track, just switch channels.
It's not limited to --stable either. Using another channel name has the same effect:
$ sudo snap refresh --beta pi-kernel
error: cannot refresh "pi-kernel": cannot switch from kernel track "18-pi3" as specified for the
       (device) model to "beta"

Here are the current snaps installed:
Name Version Rev Tracking Publisher Notes
bluez 5.47-3 167 stable canonical✓ -
core 16-2.36.1 5898 stable canonical✓ core
core18 18 445 stable canonical✓ base
docker 18.06.1-ce 320 stable docker-inc -
network-manager 1.2.2-17 315 stable canonical✓ -
pi 18-0.1 2 18-pi3 canonical✓ gadget
pi-kernel 4.15.0-1028.30 15 18-pi3 canonical✓ kernel
snapd 2.36 1399 stable canonical✓ snapd
wifi-ap 18 210 stable canonical✓ -

It's also worth noting that the snaps above are in the 18-pi3 track.

[Samuele Pedroni (pedronis)]

A discussion of this with a solution is now here:

https://forum.snapcraft.io/t/risk-only-channel-requests-vs-pinned-default-tracks/9332

[Maciej Borzecki (maciek-borzecki)]

PR: https://github.com/snapcore/snapd/pull/6415

[Samuele Pedroni (pedronis)]

The behavior will be fixed in snapd 2.38.