One more thing to try:
sudo cat /var/lib/snapd/state.json | jq '.data.auth.device.serial'
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
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.
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?
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:
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