Add an example for skopeo inspect --override-os

[jedahan]

tl;dr - Is there a supported way to tell skopeo inspect to use a specific architecture and os? I don't see anything in skopeo inspect --help that points towards it.

---

I am not calling skopeo manually, but through terraform via incus provider. It runs skopeo --insecure-policy inspect docker://docker.io/linuxserver/jellyfin and errors out. Indeed running skopeo --insecure-policy inspect docker://docker.io/linuxserver/jellyfin manually gives the same error:

FATA[0000] Error parsing manifest for image: choosing image instance: no image found in image index for architecture "arm64", variant "v8", OS "darwin"

Thing is, my default_remote is set to an x86_64 machine, I am not sure if

• the inspect command is not set to the remote machine (os: incus-os, architecture: x86_64), and if it can be set
  or
• the inspect command should work on macOS at all, and if not, should it be hidden
  or
• the incus provider is not setting the architecture to the remote correctly

So I am asking here and in incus to figure out where the source of the problem lies and how to solve it.

(separately, is there any way to have skopeo inspect on macOS just work out of the box instead of having to learn that these things need to be overridden?)

Thanks

[jedahan]

ok, it was in the man page, not in the --help output. I'd appreciate it being in --help as well, and off to incus to figure out why its not filtered by the remote architecture when calling skopeo

[jedahan]

related to lxc/terraform-provider-incus#248

[mtrmac]

Thanks for your report. --override-os is visible in skopeo --help, but not in skopeo inspect --help. I don’t think we’d want to list all options in the inspect-specific page, but it might be worth adding a note — I don’t know whether users looking at the table of options would notice a separate text.

Changing the behavior (… to do what? always assume linux? somewhat plausible; always assume amd64? historically reasonable but increasingly problematic) would break scripts, so we can’t very well do that any more.

[jedahan]

I wouldn't suggest changing behavior without knowing how many darwin+arm64 images exist. If it was zero, I might argue for falling back to another architecture by default though that just kicks the can down the line to whatever the person tries to do next with a non matching image.

I guess the weird part is that on macOS, I am using client-side tools that speak to a linux/amd64 remote, so working with metadata for non-local architecture is normal. Since lxc/podman(/docker?) use a virtual machine on macOS to run containers, maybe it is safe for skopeo to show remote machine architectures?

For immediate improvements, I think theres some more verbose error logging that could be nice for folks:
a. list hat architectures were found in the manifest
b. show how to pick one of those architectures with an example using --override-os etc

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mtrmac]

a. list hat architectures were found in the manifest

There are frequently quite a few, and it doesn’t solve the “how do I do this” question

b. show how to pick one of those architectures with an example using --override-os etc

The error message comes from a library, and that library doesn’t directly know the CLI flag names.

---

I think a reasonable path forward would be to add the option to one of the examples in inspect --help.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.