### What happened?

I think the private container registry had some intermittent errors and did return wrong data for some layers.

The problem I think is that kubelet or containerd is in a state were it assumes that a given OCI image is already downloaded locally, but then some parsing of this layer fails and the loop starts again.

### What did you expect to happen?

kubelet and or containerd should detect the wrong layer/manifest state and delete the incomplete/erroneous download and pull again from container registry.

### How can we reproduce it (as minimally and precisely as possible)?

Not sure, probably container registry needs to return media type octet-stream for some layer/manifest instead of correct media type.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
Kubelet 1.28.7-gke.1026000
Containerd 1.7.10
Linux 6.1.58+
</details>


### Cloud provider

<details>
GCP
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>
Will provide 
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

kubelet and containerd in endless loop for CreateContainer with unexpected media type octet-stream
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : kubelet and containerd in endless loop for CreateContainer with unexpected media type octet-stream
Issue date:

--- start body ---
### What happened?

I think the private container registry had some intermittent errors and did return wrong data for some layers.

The problem I think is that kubelet or containerd is in a state were it assumes that a given OCI image is already downloaded locally, but then some parsing of this layer fails and the loop starts again.

### What did you expect to happen?

kubelet and or containerd should detect the wrong layer/manifest state and delete the incomplete/erroneous download and pull again from container registry.

### How can we reproduce it (as minimally and precisely as possible)?

Not sure, probably container registry needs to return media type octet-stream for some layer/manifest instead of correct media type.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
Kubelet 1.28.7-gke.1026000
Containerd 1.7.10
Linux 6.1.58+
</details>


### Cloud provider

<details>
GCP
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>
Will provide 
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---
