could not unmarshal state entry "snap-type"

Bug #1616629 reported by Evan
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
snapd
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)

Revision history for this message
Evan (ev) wrote :
Revision history for this message
Evan (ev) wrote :
description: updated
Revision history for this message
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
Revision history for this message
Evan (ev) wrote :

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

Changed in snappy:
status: Incomplete → Invalid
Revision history for this message
Forrest Hopkins (forresthopkinsa) wrote :

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.

Revision history for this message
Gerhard Burger (burger.ga) wrote :

Same in a 17.04 chroot through crouton

Changed in snappy:
status: Invalid → Confirmed
Revision history for this message
Forrest Hopkins (forresthopkinsa) wrote :

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

Revision history for this message
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)

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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)

Revision history for this message
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

Revision history for this message
John Lenton (chipaca) wrote :

Thank you for redacting that :-)

Revision history for this message
John Lenton (chipaca) wrote :

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

John Lenton (chipaca)
Changed in snappy:
status: Confirmed → Incomplete
Michael Vogt (mvo)
Changed in snappy:
status: Incomplete → In Progress
importance: Undecided → High
Revision history for this message
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)
tags: added: canonical-bootstack
Revision history for this message
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?

Revision history for this message
Paul Gear (paulgear) wrote :

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

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

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

affects: snappy → snapd
Changed in snapd:
status: In Progress → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers