Moving lxd container to a new partition

I just can’t get lxd working again after moving my storage pool from dedicated dev/sda2 to dev/sdb1. ( in fact, the partition simply got renamed after reshuffling sata connectors)

The problem is that the LXD daemon now fails to start with

DBUG[10-14|10:05:51] Initializing and checking storage pool "pool1" 
DBUG[10-14|10:05:51] Mount started                            pool=pool1 driver=btrfs
DBUG[10-14|10:05:51] Mount finished                           pool=pool1 driver=btrfs
EROR[10-14|10:05:51] Failed to start the daemon: Failed initializing storage pool "pool1": Source path '/dev/sda2' isn't btrfs 
INFO[10-14|10:05:51] Starting shutdown sequence 

So lxc is of little use to change configuration, as it requires a running daemon.
There must be a config setting somewhere for the storage pool location for lxd , I just can’t seem to find it.

I’ve been stuck with this problem for a while now and I hope that somebody can point me towards a solution.


Indeed, it is a valid issue that you cannot start LXD so as to make the change since LXD cannot start due to not having made that change already.

I do not know whether there is a smart workaround for this issue, i.e. using some parameter when you run lxd. When you run lxd init --dump, it dumps the server config. But could it is possible to re-import the slightly changed LXD server config?

In any case, you can edit by hand (i.e. sqlitebrowser) the SQLite database for LXD and edit in place the block device. The location is /var/snap/lxd/common/lxd/database/.

Thanks, I was able to open and edit the database, but the setting magically keeps getting back to the old `/dev/sda2’ value :confused:

This is what’s happening:

  • change values in db to dev/sdb1, write changes, close&reopen db, verify that changes are still there … :ballot_box_with_check:
  • run lxd --debug , get same complaints about `/dev/sda2’
  • open db, the old /dev/sda2 setting is there again. :negative_squared_cross_mark:

a full system restart did not help either. :frowning:

I was also able to reproduce the same behavior with sqlite3 client:

  1. Change db in sqlitebrowser
  2. verify

sqlite> select * from storage_pools_config;

  1. Run sudo lxd --debug

EROR[10-25|13:26:57] Failed to start the daemon: Failed initializing storage pool “pool1”: Source path ‘/dev/sda2’ isn’t btrfs

  1. Check db values again:

sqlite> select * from storage_pools_config;

The database subdirectory has several copies of the database files. It used to be one, but now it is more complicated. It is likely that the global subdirectory has the master database.
As a way to figure out whether your change is indeed from the master database, you can verify after the change with lxd init --dump. If you see the change there, then you changed the correct database file.

lxd init --dump does not work …

Error: Failed to connect to local LXD: Get “http://unix.socket/1.0”: dial unix /var/snap/lxd/common/lxd/unix.socket: connect: no such file or directory

The changes I’ve made were in global database /var/snap/lxd/common/lxd/database/global/db.bin
The local db /var/snap/lxd/common/lxd/database/local.db does not contain much configuration in my case.

There is one more database main.bak, which I’ve also changed just to be sure. That (unsurprisingly) did not help either …

Thanks for the update. First, I should stop suggesting people to run lxd init --dump if the LXD service is not running already, and second, I do not know the exact file that has to be edited to change the LXD configuration. There should be a hint at (or get the source and grep). I vaguely remember a recent discussion here that discussed which file to change. I cannot locate it though.

The sqlite file (/var/snap/lxd/common/lxd/database/global/db.bin) you are editing is just a read-only copy of the actual dqlite data set, which is why you are not seeing your modifications take effect.

What you need is a patch sql file which is run by LXD on startup before the storage is initialised. However using the read-only sqlite file is useful for preparing and testing the SQL statement to use for the patch file.

See where @stgraber shows how to create a patch to fix an unrelated DB issue.

1 Like

:tada: :partying_face: Thank you Thomas!
I was finally able to fix it! The patch did it.