could not unmarshal state entry "snap-type"

Bug #1616629 reported by Evan on 2016-08-24
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Snappy
High
Unassigned

Bug Description

$ 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)

Evan (ev) wrote :
Evan (ev) wrote :
description: updated
Michael Vogt (mvo) wrote :

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.

Changed in snappy:
status: New → Incomplete
Evan (ev) wrote :

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

Changed in snappy:
status: Incomplete → Invalid

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) wrote :

Same in a 17.04 chroot through crouton

Changed in snappy:
status: Invalid → Confirmed

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

ryeterrell (ryeterrell) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

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) wrote :

Thank you for redacting that :-)

John Lenton (chipaca) wrote :

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

John Lenton (chipaca) on 2018-03-26
Changed in snappy:
status: Confirmed → Incomplete
Michael Vogt (mvo) on 2018-04-11
Changed in snappy:
status: Incomplete → In Progress
importance: Undecided → High
Zygmunt Krynicki (zyga) wrote :

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) on 2018-08-10
tags: added: canonical-bootstack
Paul Gear (paulgear) wrote :

@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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers