LXD stuck after aborted update: "cannot read current revision of snap lxd: No such file or directory"


I tried to install a new container with "lxc launch images:debian/buster " which seems to have triggered an update. Unfortunately internet access vanished during this process and even after the internet access recovered “lxc launch” kept being stuck. So I had to abort it with multiple “Ctrl+C” even though I got a warning on the console for doing so.

Now I’m getting the following error in journalctl when trying to start lxd.daemon:

lxd.daemon[11851]: cannot read current revision of snap lxd: No such file or directory

And lxc list says this, too:

$ lxc list
cannot read current revision of snap lxd: No such file or directory

snap changes says:

$ snap changes
ID   Status  Spawn                     Ready  Summary
52   Abort   9 days ago, at 09:52 UTC  -      Auto-refresh snaps "core", "core20", "lxd"

And /snap/lxd looks as follows:

$ ls -lah /snap/lxd/
total 8.0K
drwxr-xr-x  4 root root 4.0K Aug  9 20:12 .
drwxr-xr-x  7 root root 4.0K Jun 21 22:58 ..
drwxr-xr-x 20 root root  288 Jul  7 06:27 20951
drwxr-xr-x 20 root root  288 Jul 10 00:56 20981
lrwxrwxrwx  1 root root    5 Jul 31 09:47 current -> 20981

snap refresh lxd does not work either, it complains as follows:

$ snap refresh lxd
error: snap "lxd" has "auto-refresh" change in progress

snap info says the following:

$ snap info lxd
name:      lxd
summary:   System container and virtual machine manager
publisher: Canonical✓
contact:   https://github.com/lxc/lxd/issues
license:   unset  
description: |
  **LXD is a system container and virtual machine manager**

  With LXD you can run hundreds of containers of a variety of Linux
  distributions, apply resource limits, pass in directories, USB devices
  or GPUs and setup any network and storage you want.

  LXD containers are lightweight, secure by default and a great
  alternative to running Linux virtual machines.

  If you want to run other Operating Systems or special Linux workloads,
  you can use LXD virtual machines instead

  **Run any Linux distribution you want**

  Pre-made images are available for Ubuntu, Alpine Linux, ArchLinux,
  CentOS, Debian, Fedora, Gentoo, OpenSUSE and more.

  A full list of available images can be found here: https://images.linuxcontainers.org

  Can't find the distribution you want? It's easy to make your own images too, either using our
  `distrobuilder` tool or by assembling your own image tarball by hand.

  **Containers and VMs at scale**

  LXD is network aware and all interactions go through a simple REST API,
  making it possible to remotely interact with instances on remote
  systems, copying and moving them as you wish.

  Want to go big? LXD also has built-in clustering support,
  letting you turn dozens of servers into one big LXD server.

  **Configuration options**

  Supported options for the LXD snap (`snap set lxd KEY=VALUE`):
     - ceph.builtin: Use snap-specific Ceph configuration [default=false]
     - ceph.external: Use the system's ceph tools (ignores ceph.builtin) [default=false]
     - criu.enable: Enable experimental live-migration support [default=false]
     - daemon.debug: Increase logging to debug level [default=false]
     - lxcfs.cfs: Consider CPU shares for CPU usage [default=false]
     - openvswitch.builtin: Run a snap-specific OVS daemon [default=false]
     - shiftfs.enable: Enable shiftfs support [default=auto]

  Documentation: https://linuxcontainers.org/lxd/docs/master/
  - lxd.benchmark
  - lxd.buginfo
  - lxd.check-kernel
  - lxd.lxc
  - lxd.lxc-to-lxd
  - lxd
  - lxd.migrate
  lxd.activate: oneshot, enabled, inactive
  lxd.daemon:   simple, enabled, inactive
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     latest/stable
refresh-date: 9 days ago, at 09:47 UTC
  stable:         4.16        2021-07-19 (21042) 63MB -
  candidate:      4.17        2021-08-09 (21258) 64MB -
  beta:           ↑
  edge:           git-57e83eb 2021-08-09 (21253) 64MB -
  4.17/stable:    –
  4.17/candidate: 4.17        2021-08-09 (21258) 64MB -
  4.17/beta:      ↑
  4.17/edge:      ↑
  4.16/stable:    4.16        2021-07-19 (21042) 63MB -
  4.16/candidate: 4.16        2021-08-02 (21201) 63MB -
  4.16/beta:      ↑
  4.16/edge:      ↑
  4.15/stable:    4.15        2021-07-09 (20951) 63MB -
  4.15/candidate: 4.15        2021-07-07 (20951) 63MB -
  4.15/beta:      ↑
  4.15/edge:      ↑
  4.14/stable:    4.14        2021-05-18 (20454) 64MB -
  4.14/candidate: 4.14        2021-05-18 (20454) 64MB -
  4.14/beta:      ↑
  4.14/edge:      ↑
  4.13/stable:    4.13        2021-05-05 (20319) 63MB -
  4.13/candidate: 4.13        2021-05-04 (20319) 63MB -
  4.13/beta:      ↑
  4.13/edge:      ↑
  4.0/stable:     4.0.7       2021-07-20 (21032) 64MB -
  4.0/candidate:  4.0.7       2021-07-23 (21124) 64MB -
  4.0/beta:       ↑
  4.0/edge:       git-a19c6e5 2021-08-03 (21211) 62MB -
  3.0/stable:     3.0.4       2019-10-10 (11376) 49MB -
  3.0/candidate:  3.0.4       2019-10-10 (11376) 49MB -
  3.0/beta:       ↑
  3.0/edge:       git-81b81b9 2019-10-10 (11378) 49MB -
  2.0/stable:     2.0.12      2020-08-18 (16884) 34MB -
  2.0/candidate:  2.0.12      2021-03-22 (19874) 34MB -
  2.0/beta:       ↑
  2.0/edge:       git-82c7d62 2021-03-22 (19869) 35MB -
installed:        4.16                   (20981) 63MB -

The installation is on a Raspberry Pi 4 with Debian 10 Buster (stable), Linux kernel 5.9, lxc 1:3.1.0+really3.0.3-8, snapd 2.37.4-1+b1.

What should I do to recover from this broken state?

I’d start by running dmesg to see if there’s anything wrong with the system itself.
If not, then run snap changes again and use snap abort <ID> for anything on there.
If that doesn’t work, then restart snapd (systemctl restart snapd) to see if that unsticks it.

Hi @stgraber : Thanks for your reply, that was indeed the issue, a storage device that got stuck… After a complete reboot the issue solved itself…

Damn, I thought I had checked that before :smiley: .