Can anybody explain this error? (incus 0.6-202403181629-ubuntu22.04 on Ubuntu 22.04, migrated from lxd 5.20)
$ incus image copy images:ubuntu/22.04/cloud local: --alias ubuntu/22.04/cloud --public
Image copied successfully!
Error: Failed to create alias ubuntu/22.04/cloud: Image not found
$ incus image copy images:ubuntu/22.04/cloud local: --vm --alias ubuntu/22.04/cloud/vm --public
Image copied successfully!
Error: Failed to create alias ubuntu/22.04/cloud/vm: Image not found
There are no existing conflicting aliases:
$ incus image alias list | grep ubuntu/22.04/cloud
$
Checking the image fingerprints on the remote server:
$ incus image list images: ubuntu/22.04/cloud architecture=x86_64
+-----------------------------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+-----------------------------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
| ubuntu/jammy/cloud (3 more) | 3c377d12c765 | yes | Ubuntu jammy amd64 (20240324_07:42) | x86_64 | CONTAINER | 137.26MiB | 2024/03/24 00:00 UTC |
+-----------------------------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
| ubuntu/jammy/cloud (3 more) | 48fc5ae44f53 | yes | Ubuntu jammy amd64 (20240324_07:42) | x86_64 | VIRTUAL-MACHINE | 293.86MiB | 2024/03/24 00:00 UTC |
+-----------------------------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
These haven’t been copied:
$ incus image list | egrep '3c377d12c765|48fc5ae44f53'
$
But I have different ones:
$ incus image list | grep 2024/03/24
| | 80b8d928b38c | yes | Ubuntu jammy amd64 (20240323_07:42) | x86_64 | CONTAINER | 137.26MiB | 2024/03/24 11:43 UTC |
| | 489f55a8ece8 | yes | Ubuntu jammy amd64 (20240323_07:42) | x86_64 | VIRTUAL-MACHINE | 293.63MiB | 2024/03/24 11:07 UTC |
$ sudo ls /var/lib/incus/images | egrep '80b8d928b38c|489f55a8ece8'
489f55a8ece8334e9e8759f64a231769c10084050720faf09507a7bba7428429
489f55a8ece8334e9e8759f64a231769c10084050720faf09507a7bba7428429.rootfs
80b8d928b38c19d16141b8d96fdbb8fa26824138603eb68395168d723185691f
80b8d928b38c19d16141b8d96fdbb8fa26824138603eb68395168d723185691f.rootfs
and it works to create an alias manually to these using the fingerprint:
$ incus image alias create foobar 80b8d928b38c
$ incus image alias delete foobar
$
However, if I first copy the image without setting an alias, then repeat the command, it works:
$ incus image copy images:ubuntu/22.04/cloud local:
<< I see the download briefly >>
Image copied successfully!
$ incus image copy images:ubuntu/22.04/cloud local: --alias ubuntu/22.04/cloud --public
Image copied successfully!
$ incus image alias list | grep ubuntu/22.04/cloud
| ubuntu/22.04/cloud | 3c377d12c765 | CONTAINER |
$ incus image list | grep 2024/03/24
| ubuntu/22.04/cloud | 3c377d12c765 | yes | Ubuntu jammy amd64 (20240324_07:42) | x86_64 | CONTAINER | 137.26MiB | 2024/03/24 12:14 UTC |
| | 80b8d928b38c | yes | Ubuntu jammy amd64 (20240323_07:42) | x86_64 | CONTAINER | 137.26MiB | 2024/03/24 11:43 UTC |
| | 489f55a8ece8 | yes | Ubuntu jammy amd64 (20240323_07:42) | x86_64 | VIRTUAL-MACHINE | 293.63MiB | 2024/03/24 11:07 UTC |
and then I can’t reproduce the problem:
$ incus image delete 3c377d12c765
$ incus image alias list | grep ubuntu/22.04/cloud
$ incus image copy images:ubuntu/22.04/cloud local: --alias ubuntu/22.04/cloud --public
Image copied successfully!
$ incus image alias list | grep ubuntu/22.04/cloud
| ubuntu/22.04/cloud | 3c377d12c765 | CONTAINER | |
$
EDIT: the images differ by one day in their “serial” but at the same HH:MM time.
$ incus image info 3c377d12c765
Fingerprint: 3c377d12c7652ac2ecedf53c852533c3bb7a17f22a0386fd4c5befde61572f91
Size: 137.26MiB
Architecture: x86_64
Type: container
Public: yes
Timestamps:
Created: 2024/03/24 00:00 UTC
Uploaded: 2024/03/24 12:14 UTC
Expires: 1970/01/01 00:00 UTC
Last used: never
Properties:
os: Ubuntu
release: jammy
serial: 20240324_07:42
type: squashfs
variant: cloud
architecture: amd64
description: Ubuntu jammy amd64 (20240324_07:42)
Aliases:
- ubuntu/22.04/cloud
Cached: no
Auto update: disabled
Source:
Server: https://images.linuxcontainers.org
Protocol: simplestreams
Alias: ubuntu/22.04/cloud
Profiles:
- default
$ incus image info 80b8d928b38c
Fingerprint: 80b8d928b38c19d16141b8d96fdbb8fa26824138603eb68395168d723185691f
Size: 137.26MiB
Architecture: x86_64
Type: container
Public: yes
Timestamps:
Created: 2024/03/23 00:00 UTC
Uploaded: 2024/03/24 11:43 UTC
Expires: 1970/01/01 00:00 UTC
Last used: 2024/03/24 11:44 UTC
Properties:
os: Ubuntu
release: jammy
serial: 20240323_07:42
type: squashfs
variant: cloud
architecture: amd64
description: Ubuntu jammy amd64 (20240323_07:42)
Aliases:
Cached: yes
Auto update: disabled
Source:
Server: https://images.linuxcontainers.org
Protocol: simplestreams
Alias: ubuntu/22.04/cloud
Profiles:
- default
Any ideas? Could this be to do with lxd to incus migration? I vaguely remember reading something about storage cleanup after lxd to incus migration, but I can’t find it now, and it’s not mentioned in the official documentation AFAICS.
In any case, the incus migration was a few days ago, and both of these images would have been fetched via incus, not lxd.
Thanks,
Brian.