One more thing to try:
sudo cat /var/lib/snapd/state.json | jq '.data.auth.device.serial'
➜ ~ 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 /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?
Yes, I’d like to, but I don’t know what “the generic model assertion” is…
Try:
$ 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
2 Likes
That solved the problem for me! Thanks a lot!
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”
}
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
this solved it for me too, I had the exact same error as the original poster
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
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
1 Like
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