When you curl nixos you get the “Location” it was forwarded too:
curl -vIL https://images.linuxcontainers.org/images/nixos/unstable/amd64/default/20260911_01:02/incus.tar.xz
This is how you get the date above:
curl -fsSL https://images.linuxcontainers.org/streams/v1/images.json | jq '.products | to_entries[] | select(.key |
startswith("nixos")) | {key: .key, versions: (.value.versions | keys)}'
Thank you.
It looks like za.images.linuxcontainers.org is broken:
% curl https://za.images.linuxcontainers.org/images/nixos/unstable/amd64/default/20260911_01:02/disk.qcow2 -o foo2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 651M 0 5903k 0 0 1463k 0 0:07:35 0:00:04 0:07:31 1463k
curl: (18) transfer closed with 676989745 bytes remaining to read
% ls -l foo2
-rw-r--r-- 1 brian staff 6045391 11 Sep 12:04 foo2
Compared with:
% curl https://fra1mirror01.do.images.linuxcontainers.org/images/nixos/unstable/amd64/default/20260911_01:02/disk.qcow2 -o foo1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651M 100 651M 0 0 35.4M 0 0:00:18 0:00:18 --:--:-- 36.1M
% ls -l foo1
-rw-r--r-- 1 brian staff 683035136 11 Sep 12:04 foo1
Should be happier again.
Confirmed, thank you. I’d be interested to know what was wrong (e.g. was that file truncated in the mirror? But how did it know the correct size?)
Cache out of space as it wasn’t correctly expiring entries, normally the mirrors keep 2GiB of data, this one was at over 15GiB for some reason.
Interesting: 2GiB doesn’t sound very much. With a single container image typically 100-150MiB (Ubuntu/Debian) and VM images significantly larger, that means only a handful are being actively used and cached.
Quick check: from incus image list images: -fcsv there are 1981 images, totalling 519.8 GiB.
Yeah, but the “hot set” tends to be extremely small, especially for a mirror as regional as the South African one.