Failed to load network “lxdbr0”: Duplicate config row found for key “dns.mode” for network ID 1

Hi,
Since yesterday my LXD installation seems to have crashed. I have tried uninstalling and reinstalling LXD, but I am still getting the same errors. I have seen some posts with similar problems (https://github.com/lxc/lxd/issues/8260) however it is not clear to me how to apply any suggested changes. Here is what I am getting:

lxd init
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

snap changes
ID Status Spawn Ready Summary
558 Done yesterday at 18:36 CET yesterday at 18:36 CET Snap “lxd” automatisch verversen

sudo lxd --debug --group lxd
Failed to start the daemon: Failed to load network “lxdbr0”: Duplicate config row found for key “dns.mode” for network ID 1

Any help is greatly appreciated.
Thanks in advance,
Gary

Take a look at:

It has a suggested approach to fix this in there.

Which part of the instructions in https://github.com/lxc/lxd/issues/8260 do you struggle to follow?

Please show output from:

sudo sqlite3 /var/snap/lxd/common/lxd/database/global/db.bin
sqlite> SELECT * FROM networks;
sqlite> SELECT * FROM networks_config;

Thanks, I wasn’t so sure of the sqlite3 bit as I didn’t have that package installed:

sqlite> SELECT * FROM networks;
1|lxdbr0||1
sqlite> SELECT * FROM networks_config;
1|1||ipv4.address|none
2|1||ipv6.address|none
3|1||dns.mode|dynamic
4|1||ipv4.address|10.11.12.1/24
5|1||ipv6.address|none
6|1||dns.mode|dynamic
7|1||ipv6.address|none
8|1||dns.mode|dynamic
9|1||ipv4.address|10.11.12.1/24
10|1||ipv4.dhcp.ranges|10.11.12.10-10.11.12.254
11|1||dns.mode|dynamic
12|1||ipv4.address|10.11.12.1/24
13|1||ipv4.dhcp.ranges|10.11.12.10-10.11.12.254
14|1||ipv4.nat|true
15|1||ipv6.address|none
16|1||dns.mode|dynamic
17|1||ipv4.address|10.11.12.1/24
18|1||ipv4.dhcp.ranges|10.11.12.10-10.11.12.254
19|1||ipv4.nat|true
20|1||ipv6.address|fd84:4262:fb71:9b5f::1/64
21|1||ipv4.nat|true
22|1||ipv6.address|fd84:4262:fb71:9b5f::1/64
23|1||ipv6.nat|true
24|1||dns.mode|dynamic
25|1||ipv4.address|10.11.12.1/24
26|1||ipv4.dhcp.ranges|10.11.12.10-10.11.12.254

My containers are in the range 10.11.12.x

OK so you have quite a few duplicate rows in there (newer releases of LXD prevent this happening in the future).

You need to create a file called /var/snap/lxd/common/lxd/database/patch.global.sql and inside put lines to delete the duplicate rows by ID (leaving just the ones you want).

e.g.

DELETE FROM networks_config WHERE id = n

Where n is from the first number column on the SELECT * FROM networks_config; output.

So in this case I can see you have multiple rows for ipv4.address:

1|1||ipv4.address|none
4|1||ipv4.address|10.11.12.1/24
9|1||ipv4.address|10.11.12.1/24
12|1||ipv4.address|10.11.12.1/24
17|1||ipv4.address|10.11.12.1/24

So I would add:

DELETE FROM networks_config WHERE id = 1;
DELETE FROM networks_config WHERE id = 4;
DELETE FROM networks_config WHERE id = 9;
DELETE FROM networks_config WHERE id = 12;

Leaving just the row Id 17.

Then repeat that, adding additional rows, for the other duplicated config fields.

Then restart LXD and that should fix it.

Another approach would be to delete all rows except the ones that look most recent.

For example row IDs 20 and above look like they represent the most recent whole config for lxdbr0.

So you could add to /var/snap/lxd/common/lxd/database/patch.global.sql just:

DELETE FROM networks_config WHERE id < 20;

Thank you so much Thomas! I would never have figured this out myself. All seems to be up and working again :slight_smile:

1 Like

Excellent. In recent versions of LXD we’ve added a unique index that should prevent that being able to reoccur, as well as fixing the scenarios where it was previously possible to add duplicate config.

I have no idea how it got like this, I have been using LXD for a few years now, but (since I have had so few problems with it) I haven’t dug so deep into some of these more technical aspects. Just yesterday after some updates I think, it suddenly stopped working. Glad to hear there are steps being taken to prevent this happening again in the future!

It appears that in the past in certain scenarios the new config was inserted, but the old config wasn’t removed. Because the function that loaded the config from the database just iterated through the rows replacing any earlier values for a field, and so only returned the most recent value for each config field, it seems to have gone undetected for a long time.

In recent versions we added an explicit check when loading the config to detect duplicate rows (the one you’ve seen triggering) so that affected users can manually correct their database (as we’re not able to automatically select which rows are the ‘correct’ ones).

Ok, that would explain it. Thanks again!