could not unmarshal state entry "snap-type"

[Evan]

$ snap list ubuntu-core
Name Version Rev Developer Notes
ubuntu-core 16.04.1 216 canonical -

$ git clone https://github.com/evandandrea/jenkins-snap
$ cd jenkins-snap
$ snapcraft
$ snap install jenkins_2.8_amd64.snap

error: cannot perform the following tasks:
- Mount snap "jenkins" (unset) (internal error: could not unmarshal state entry "snap-type": invalid snap type: "")
- Setup snap "jenkins" (unset) security profiles (cannot find installed snap "jenkins" at revision x1)

[Michael Vogt (mvo)]

Given that jenkins is now in the store I assume this problem is fixed? Fwiw, I installed it with the latest snapd and got no error.

[Evan (ev)]

I haven't seen this since. Marking as invalid.

[Forrest Hopkins (forresthopkinsa)]

Running into this problem right now.

(trusty)forrest@localhost:~$ sudo snap install remmina
error: cannot perform the following tasks:
- Mount snap "core" (1689) (internal error: could not unmarshal state entry "snap-type": invalid snap type: "")
- Setup snap "core" (1689) security profiles (cannot find installed snap "core" at revision 1689)

And in snapd:

2017/06/14 10:05:10.045676 api.go:912: Installing snap "remmina" revision unset
2017/06/14 10:19:10.965122 handlers.go:204: Reported install problem for "core" as 94a9d992-5125-11e7-9afb-fa163eec78fa OOPSID

Note that my environment here is unique; I'm running this in a 14.04 chroot through Crouton, and systemctl doesn't work in chroots, so I have snapd running in the foreground.

[Gerhard Burger (burger.ga)]

Same in a 17.04 chroot through crouton

[Forrest Hopkins (forresthopkinsa)]

Still encountering this issue with a Xenial chroot. Anyone know if this has been investigated at all? It's a huge roadblock.

[ryeterrell (ryeterrell)]

I'm also seeing this, on arm64, under lxd, all xenial:

$ sudo snap install --channel=1.9/edge kube-apiserver
error: cannot perform the following tasks:
- Mount snap "kube-apiserver" (370) (internal error: could not unmarshal state entry "snap-type": invalid snap type: "")
- Setup snap "kube-apiserver" (370) security profiles (cannot find installed snap "kube-apiserver" at revision 370)

[John Lenton (chipaca)]

@ryeterrell, interesting. When did this start happening?

Could you upload the output of "curl --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all" please?

[ryeterrell (ryeterrell)]

@chipaca Not sure - this was my first attempt at this under arm64.

Here's the output you requested: https://gist.github.com/wwwtyro/7fc5fd617044d2d5da358dc51c86fc71

Thanks for taking a look.

[John Lenton (chipaca)]

Hmm, that wasn't as useful as I was hoping.

Could you do

sudo jq -r '.tasks | .[] | select(.data | .["snap-type"] == "" ) | .summary' /var/lib/snapd/state.json

? (that's one line)

[ryeterrell (ryeterrell)]

That was empty, but here's all of state.json with some possibly sensitive stuff redacted: https://gist.github.com/wwwtyro/baff17ad8f7450bc4ba54c4592166e85

[John Lenton (chipaca)]

Thank you for redacting that :-)

[John Lenton (chipaca)]

Could you repeat the command that fails complaining about snap-type?

[Zygmunt Krynicki (zyga)]

Can anyone affected explain the environment they are running in. Some of the errors mentioned here would also happen if the squashfs/snap was not mounted.

[Paul Gear (paulgear)]

@zyga: I'm seeing this when there was a previous failed attempt at refreshing and/or removing (not sure which). The mount table has been somehow corrupted, whereby mount thinks that the snap is mounted, but umount thinks that it is not, and refuses to unmount it: https://pastebin.ubuntu.com/p/NGsc2yp7Sr/

Interestingly, a reboot does not correct the problem with the mount table. Is snapd perhaps recreating this state on boot?

[Paul Gear (paulgear)]

@zyga: Private pastebin with some OOPS ids you might find helpful: https://pastebin.canonical.com/p/JB3PfZFssQ/

[Zygmunt Krynicki (zyga)]

I'm marking this as confirmed but not in progress anymore. I don't believe anyone is working on this anymore.