Failed to invoke skopeo proxy method GetLayerInfo

[bitbyt3r]

When trying to install a bootc image with many layers the payload coming back from skopeo is 104kB, however it looks like the buffer it is read into is only 32kiB, and I'm getting an EoF error from ostree as a result. I think the value on this line should be increased: https://github.com/containers/containers-image-proxy-rs/blob/main/src/imageproxy.rs#L83

I will see if I can compile with that increased and test ostree within anaconda that way.

[bitbyt3r]

FWIW, it looks like I have 677 layers. I could probably trim that down, but I'm testing different ways to encapsulate container images. Currently I'm just including the layers individually (though each is tar'd with a path in /usr/lib/<project name>/blobs/sha256). Ultimately my goal is just to have differential updates that can pull only what is needed, but I want to keep the images that ship with the OS readonly since downstream users tend to mangle anything within reach 😆

I'm considering logically encapsulating them instead, but it looks like that won't make them readonly.

[cgwalters]

FWIW, it looks like I have 677 layers. I could probably trim that down,

As far as I know, there is no strictly defined limit in the spec, but...in practice for container runtimes that use a single lowerdir per layer, until recent Linux kernels there were relatively hard limits around ~120 based on the mount options. While the new mount API allows going beyond that on newer kernels (I think after 6.12) there's still some scaling issues there as far as I know.

I would recommend staying below something around ~120 - which I know is not satisfying, but it is the status quo.

That said, the ostree-container flow also doesn't have a strictly defined limit...in theory indeed we could increase the maximum size of metadata here, but because we're using SOCK_SEQPACKET we'd likely need to ensure buffer sizes are increased on both ends.

I'm considering logically encapsulating them instead, but it looks like that won't make them readonly.

(Now we're talking bootc specifics, but...why do you say that? They will appear readonly by default to the rest of the OS processes - you can't podman rmi them for example)