image server appears to be broken?

I’ve tested this on two machines: one is 4.0.5 LTS and one is 4.13:

$ lxc launch images:ubuntu/focal/cloud testcontainer
Creating testcontainer
Error: Failed instance creation: invalid character '\x00' after top-level value

It occurs with any image on that server, but I can create a container from the ubuntu-minimal image server without issues.

I tried issuing lxc image refresh images:ubuntu/focal/cloud but it seems that is only for private remotes.

I haven’t dug into the code yet to see what might actually be failing but I suspect there’s a metadata issue somewhere on the image server?

1 Like

Update: this appears to be resolved? I never worked out what the cause was.

I am still affected by this:

$ lxc image list images:
Error: invalid character '\x00' after top-level value

I am running lxd 4.13 on archlinux fully up to date. The ‘images’ remote is the only one that is broken for me i.e.:

$ lxc image list ubuntu:

works as expected. I can ‘launch’ or ‘init’ images from the ‘ubuntu:’ remote, but not from the ‘images:’ remote.

Please let me know if there is anything I can do to help resolve the issue.


1 Like

I have just tried again.

Now, this works (I get a list of images):

$ lxc image list images:

However, this still fails:

$ lxc launch images:archlinux blah
Creating blah
Error: Failed instance creation: invalid character '\x00' after top-level value

I also tried with another image than arch, just in case. Same thing:

$ lxc launch images:alpine/3.13 blah
Creating blah
Error: Failed instance creation: invalid character '\x00' after top-level value


1 Like

Are you accessing over IPv6?

CC @stgraber

1 Like

Also, where abouts are you located, are you nearer US or UK?

I’m also getting this same error. Same version. Multiple host machines. Started some time within the last 15 hours. Located in Australia.

Tested working OK on a fresh LXD 4.13 install here in the UK using:

lxc launch images:ubuntu/focal c1
lxc launch images:archlinux blah

Perhaps the US is mirror playing up.

One of my machines is now working. Came good about 08:38 UTC. The other one located in a different location (but still in Aus) still has the error. Perhaps it will come good soon also.

Both machines seem to use

Yeah, so redirects clients to either or, and seems to be down ATM.

It connects, but just hangs:

telnet 80
Trying 2001:67c:1562::41...
Connected to
Escape character is '^]'.
GET / HTTP/1.1


But its ok over IPv4:

telnet 80
Connected to
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 14 Apr 2021 08:50:15 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Wed, 14 Apr 2021 07:27:09 GMT
ETag: "e36c-5bfe9acbb05ba"
Accept-Ranges: bytes
Content-Length: 58220
Vary: Accept-Encoding
Content-Type: text/html

<!DOCTYPE html>
<html lang="en">
1 Like

If you add an /etc/hosts entry for pointing to it should fix it temporarily.

Just checked the internal Canonical IS team and there are known IPv6 issues at the US data center currently.

I added the /etc/hosts entry and it has not resolved the issue.

Check that has taken effect using tcpdump, also can you replicate the telnet tests I did above and confirm the issue is only affecting IPv6. Thanks

sudo tcpdump -nn -i any host

It was using IPv4 confirmed using tcpdump. However on my second machine the issue has been resolved at about 9:09 UTC.

1 Like

No, I am not accessing over IPv6

I am in London, UK

Can you provide output of:

curl -v -I
$ curl -v -I
*   Trying
* Connected to ( port 80 (#0)
> HEAD / HTTP/1.1
> Host:
> User-Agent: curl/7.76.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
HTTP/1.1 302 Moved Temporarily
< server: nginx/1.18.0 (Ubuntu)
server: nginx/1.18.0 (Ubuntu)
< date: Wed, 14 Apr 2021 09:35:34 GMT
date: Wed, 14 Apr 2021 09:35:34 GMT
< content-type: text/html
content-type: text/html
< content-length: 154
content-length: 154
< location:
< access-control-allow-origin: *
access-control-allow-origin: *

* Connection #0 to host left intact

It is now working for me. Location: London (UK), using IPv4:

I didn’t have to apply the /etc/hosts workaround.

Many thanks for solving this.