Can't install or refresh snaps on Arch Linux

snapd
21

Perhaps that’s a case of buggy package purge in older version of the package. I think there was such a bug at some point, snap-mgmt --purge would remove stuff under /var/lib/snapd/ but state.json was left behind. That was a bunch of releases back though.

Would manually clearing device-serial in state.json unblock it?

22

@mborzecki I think the easiest workaround would be:

snap ack “the generic model assertion”

23

@_tim Can you try that?

24

Yes, I’d like to, but I don’t know what “the generic model assertion” is…

25

Try:

$ snap known --remote model model=generic-classic series=16 brand-id=generic > assertion
$ sudo snap ack assertion
26

Ok, did that.
Now I get:

➜  ~ sudo snap refresh 
error: cannot perform the following tasks:
- Download snap "core" (5897) from channel "stable" (no device serial yet)
27

Seems like there is no easy way out. Please see the output of snap changes to snap changes to check if Initialize device change appears.

If it does not then, try this:

$ systemctl stop snapd
$ sudo cat /var/lib/snapd/state.json | \
    jq 'delpaths([["data", "auth", "device"]])' > state.json-new
$ sudo cp state.json-new /var/lib/snapd/state.json
$ sudo systemctl start snapd

After a while you should see this:

$ snap changes
ID   Status  Spawn               Ready               Summary
19   Done    today at 18:29 CET  today at 18:29 CET  Initialize device
2 Likes
28

That solved the problem for me! Thanks a lot!

29

I see this for RPi ubuntu-core core18

{
“type”: “model”,
“authority-id”: “xxx”,
“brand-id”: “xxx”,
“series”: “16”,
“model”: “my-pi3”,
“architecture”: “armhf”,
“base”: “core18”,
“gadget”: “pi=18-pi3”,
“kernel”: “pi-kernel=18-pi3”,
“timestamp”: “2019-01-19T00:32:25+00:00”
}

30

Had same error in initial post. After rebooting, I ran these two commands:

$ sudo systemctl enable --now snapd.socket

$ sudo ln -s /var/lib/snapd/snap /snap

My error went away after that.

1 Like
31

this solved it for me too, I had the exact same error as the original poster

33

I just had this error in an Ubuntu lxc container which I launched and then immediately tried to snap install something in, via a script. I could insert an artificial delay between the container starting and me doing snap install but that feels rather kludgey. Shouldn’t snap install wait until the system is ready for snaps to be installed, rather than error out when the system isn’t quite ready? I thought the idea of a dependency based init system was that these kinds of issues didn’t happen?

1 Like
34

The dependency based init doesn’t capture the fact that snapd is up but not really responding to most requests yet. It’s a particular design decision that snapd.service is the same thing that sets up the system for being operational.

35

What we’ve recommended to folks in similar situations is to use snap wait system seed.loaded as the first thing in all your scripts that try to use snap install, etc. Although that was always on core, but I imagine it should still be applicable to classic too

1 Like
36

I solved it like this:

sudo pacman -S snapd

sudo systemctl enable --now snapd.socket

sudo ln -s /var/lib/snapd/snap /snap

sudo systemctl start --now snapd.socket

After that I no longer throw an error, which in fact was the same one that shot you.

37

On ubuntu 18.04 I solved this by fully removing snap and installing this again.

Please notice that snap command is installed by installing the snapd package.

apt autoremove --purge snapd
apt install snapd