New containers not getting ipv4 address (broken base images)

1

Hi,

Today after 2pm none of our lxd containers are getting ipv4 addresses. I tried to create also a generic centos / rocky / fedora / ubuntu container and none of them getting ipv4 addresses either:

lxc launch images:centos/8-Stream

However if I use old image, everything works fine:

lxc launch podman_base zz

lxc list   
+-------------------+---------+----------------------+------+-----------+-----------+
|       NAME        |  STATE  |         IPV4         | IPV6 |   TYPE    | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
| outgoing-duckling | RUNNING |                      |      | CONTAINER | 0         |
+-------------------+---------+----------------------+------+-----------+-----------+
| zz                | RUNNING | 192.168.2.106 (eth0) |      | CONTAINER | 0         |
+-------------------+---------+----------------------+------+-----------+-----------+

The issue is happening in lxd versions 4.0.9 - 5.0.0 and on fedora 35, centos 8 stream hosts

2

Hi,

Sorry about this, we are aware, please see

https://github.com/lxc/lxd/issues/10309

3

Thanks for the explanation! Is there a way to use the image from the day before? It looks like all our base images were automatically updated!

4

@stgraber @monstermunchkin are older images stored on the image server do you know?

5

No, unfortunately we don’t keep older images.

6

I found a way to access older images:

  • Navigate to https://uk.lxd.images.canonical.com/streams/v1/images.json
  • find you image, expand versions key (the last 3 days are available), select the date
  • expand items -> lxd.tar.xz, copy combined_sha256 value
  • you can start a new container from this image like this lxc launch images:f32c4d30aad15b2ea5a97edb2691d31d7fcaa567d8fc700f0cfef3eb4f714e00 ww

I wonder if there is a way to override existing image in cache… :thinking:

1 Like
7

We keep 3 days of images, so it is possible to launch from an older image.

8

Out of curiosity, is there an easy way to refer to an old image? Or is New containers not getting ipv4 address (broken base images) - #6 by jsnjack the only way?

9

You need to refer to it by fingerprint

10

I guess the question is where can we easily get the fingerprint?

Using the sha256 fingerprint of disk.qcow2 from https://us.lxd.images.canonical.com/images/ubuntu/bionic/amd64/default/20220420_07:42/SHA256SUMS doesn’t work:

 lxc launch images:b662acb0a517a96c08a3c3c7aac7f4e365f31e8201d298191cb639531e816572 --vm
Creating the instance
Error: Failed instance creation: Failed getting image: The requested image couldn't be found
11

lxc image list images: os=Ubuntu arch=amd64 release=focal variant=default

2 Likes
12

lxc image list images: os=Ubuntu arch=amd64 release=bionic variant=default type=disk-kvm.img worked thanks.

Not easily discovered though. I suspect many would point a browser to the images server and look for a fingerprint. Would it make sense to add a list of fingerprints to the artifacts uploaded along with other files?

13

It’s technically there, just not super visible :slight_smile:

stgraber@dakara:~$ curl https://us.lxd.images.canonical.com/images/ubuntu/bionic/amd64/default/20220420_07:42/.lxd_fingerprint
762b6c4e19fbba970c2c22710ba6d410de178b5ac8b26ebfd2bd853b57622261
14

Yeah, not super visible and I couldn’t guess the one for the VM. It’s also confusing that it doesn’t match what’s in the SHA256SUMS file. The lxc image list with filters you provided is super handy though. If we have a list of tips and tricks, it should be in there.