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
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:
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.
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).
A quick late note on this topic to clarify how networks_config works and how to approach this table.
I had this same issue - for me, the problem showed up as being unable to start LXD after a migration. The error I had, clearly visible after running lxd --debug --group lxd and also lurking in syslog:
Error: Failed applying patch “network_clear_bridge_volatile_hwaddr”: Failed loading network “lxdbr0” for network_clear_bridge_volatile_hwaddr patch: Duplicate config row found for key “dns.mode” for network ID 1
Using sqlite3, I was able to see the duplicate data clearly in networks_config. I tried to find a definition of what to expect, but was unable to. In the end, I noticed, in this particular post, the suggestion of looking up the names and db numbers of the networks:
In my system, there’s only a single interface, designated as network_id 1.
And I recommend a glance at the .schema, using
.schema networks
.schema networks_config
Which gives us
sqlite> .schema networks
CREATE TABLE networks (
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
name TEXT NOT NULL,
description TEXT,
state INTEGER NOT NULL DEFAULT 0,
UNIQUE (name)
);
sqlite> .schema networks_config
CREATE TABLE networks_config (
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
network_id INTEGER NOT NULL,
node_id INTEGER,
key TEXT NOT NULL,
value TEXT,
UNIQUE (network_id, node_id, key),
FOREIGN KEY (network_id) REFERENCES networks (id) ON DELETE CASCADE,
FOREIGN KEY (node_id) REFERENCES nodes (id) ON DELETE CASCADE
);
What this means is that if all your network_config entries are marked “1” in the first column after the id, they all attempt to describe the same network, the network with id of “1” in the networks table . Duplicated lines in network_configs will mean you cannot restart after migration.
In my case I had about 5 different complete entries, each with its own “dns.mode” entry along with other replicated entries. After careful reading of the db contents (and of course) saving a copy of the db in my tmp directory), I created an sql file to delete the first 20 lines of my db, started up again in debug mode, and now my system is humming along.
I include this note because the jumble of multiple replicated entries in networks_config made it seem that they all belonged there in some odd fashion, and sent me on a search to find a description of the how the db was supposed to work – which I could not find. @tomp’s answer does a good job of that (thanks!), and I thought a tiny bit of additional clarification would be useful.
