➜ ~ sudo cat /var/lib/snapd/state.json | jq '.data.auth.device.serial' "9f73ba7e-d243-461a-af04-d192ca16a1ed"
This is strange, a device with a set model in the state, but the model assertion is not there…
@mborzecki what could delete the model assertion? there is no code in snapd itself afaik that would delete it, unless I’m missing something, is there something that could in the snapd packaging for arch?
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
state.json was left behind. That was a bunch of releases back though.
Would manually clearing
state.json unblock it?
@mborzecki I think the easiest workaround would be:
snap ack “the generic model assertion”
Yes, I’d like to, but I don’t know what “the generic model assertion” is…
$ snap known --remote model model=generic-classic series=16 brand-id=generic > assertion $ sudo snap ack assertion
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)
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
That solved the problem for me! Thanks a lot!
I see this for RPi ubuntu-core core18
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.
this solved it for me too, I had the exact same error as the original poster
Thanks for sharing it. It really helpful for me.
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?
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.
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
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.
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