(Fixed) Image (or alias) already exists error, but 'lxc image list' shows empty list

UPDATE: My issue was due to a corrupted DB caused by a box crash previously and possibly running out of disk space, but I haven’t confirmed the later for sure. It’s working correctly now.


I’m using the LXD REST API to download an image from https://images.linuxcontainers.org to my local image store and and give it a custom alias.

I’m downloading ubuntu 18.04 with fingerprint 9a71a8cd25cb.

If I set the alias to ‘ac-ubuntu-18.04’ it fails with Error 2, if I change the alias to, ‘ac-ubuntu-18.04-v2’ it fails with Error 1.

I’ve used both the 18.04 image and the ‘ac-ubuntu-18.04’ alias before, but I have deleted that image from my local setup via lxc image delete ac-ubuntu-18.04. I’ve tried it with an ubuntu 16.04 and 14.04 image and also get Error 1. I’ve used those images in the past also, but have also deleted them from local image store.

Is there another image store or something locally that’s causing the collisions?

I’m probably missing something very simple here :man_facepalming:Thanks in advance for any help!

Running LXD 3.19 on Ubuntu 18.04. The previous images were created on LXD 3.18.

Error 1:

DBUG[01-23|20:28:26] Using SimpleStreams cache entry server=https://images.linuxcontainers.org expiry=2020-01-23T21:02:51+0000
DBUG[01-23|20:28:26] Connecting to a remote simplestreams server
DBUG[01-23|20:28:26] Image already exists in the db image=9a71a8cd25cbf432e188bb0ce1b2532addce35bacf82b3f2ab74edd37d21e4f5
DBUG[01-23|20:28:26] Updated metadata for task Operation: 3b7496aa-ea72-4daf-b0ef-92f9374214d7
DBUG[01-23|20:28:26] Database error: &errors.errorString{s:“sql: no rows in result set”}
DBUG[01-23|20:28:26] Success for task operation: 3b7496aa-ea72-4daf-b0ef-92f9374214d7

However lxc image list shows no images:

±------±------------±-------±------------±-------------±-----±-----±------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
±------±------------±-------±------------±-------------±-----±-----±------------+

Error 2:

DBUG[01-23|20:27:30] Updated metadata for task Operation: ef48465a-7261-49b0-b384-cfd38c33b9aa
DBUG[01-23|20:27:31] Database error: &errors.errorString{s:“sql: no rows in result set”}
INFO[01-23|20:27:31] Image downloaded image=9a71a8cd25cbf432e188bb0ce1b2532addce35bacf82b3f2ab74edd37d21e4f5 operation=ef48465a-7261-49b0-b384-cfd38c33b9aa alias=9a71a8cd25cb server=https://images.linuxcontainers.org trigger=/1.0/operations/ef48465a-7261-49b0-b384-cfd38c33b9aa
DBUG[01-23|20:27:31] Updated metadata for task Operation: ef48465a-7261-49b0-b384-cfd38c33b9aa
DBUG[01-23|20:27:31] Failure for task operation: ef48465a-7261-49b0-b384-cfd38c33b9aa: Alias already exists: ac-ubuntu-18.04

Ok, so that’s 3.19.
Can you show lxc storage list and lxc storage show NAME for those entries?

We’ll also need to figure out what’s on disk vs what LXD thinks is on disk and try to get things to line up again. If it’s a bug in LXD, we’ll fix the bug, if it was a bug in a previous release we may be able to put a patch in place to fix on upgrades.

@stgraber I was just in the process of replying and it looks like I had a corrupted DB due to a box crash from yesterday. It wasn’t until I restarted LXD daemon again that it wouldn’t restart again and showed:

DBUG[01-23|21:14:47] Initializing database gateway
DBUG[01-23|21:14:47] Start database node id=1 address=
EROR[01-23|21:14:47] Failed to start the daemon: Failed to start dqlite server: raft_start(): io: closed segment 0000000000004788-0000000000004794 is past last snapshot snapshot-68-4096-18973507

I cleared out some of the DB entries until let me start back up.

Somehow LXD booted just fine this morning (I don’t know how to be honest) and my containers were running / able to run commands via API, but anything DB related I believe was failing and (I think) causing the error messages above.

I’m able to download images correctly now with the API.

My fault, I’ll be sure to debug even more next time and restart LXD multiple times.

Sorry for the alarm!

Ah, okay, so database and disk likely got out of sync.