Incorrect architecture check for kicbase images in download/image.go

[evanskinner]

What Happened?

When using a privately built image for kicbase, minikube fails to use it as it think it does not match the architecture of the host machine. The bug appears to be on this line https://github.com/kubernetes/minikube/blob/58e70920d9ab56e48be9cc2fceeee6b2ec4e1733/pkg/minikube/download/image.go#L118

it reads return cfg.Architecture == runtime.GOOS, nil but I think it should be return cfg.Architecture == runtime.GOARCH, nil

Attach the log file

image.go:95] image /minikube-kicbase/kicbase:main is of wrong architecture

Operating System

Redhat/Fedora

Driver

Docker

[medyagh]

thank you @evanskinner that does seem like you are on to something ! do you mind sharing the Output of minikube logs (start --alsologtostderr) for when you are using a privately built image, and also share whats your Arch is it x86

I assume you are building a custom kicbase and then use --base-image flag? and does it happen if you change the image name to something new and pre-existing? it would very helpful if you share the the commands you run to get there.

if indeed you can show me that changing that line fixes your issue, I would love you to make that PR and would be happy to merge it

my only concern is that why we dont see this issue on our CI machines, since we push Kic Images on PRs and they are technically Custom image (but they are hosted in GCR instead of locally)

[spowelljr]

Hi @evanskinner, we talked about this today and confirmed this is an issue. This doesn't impact most users since if the image if hosted in a repo it gets stored in a cache directory and even though the check you mentioned is returning false it will just load the image from the cache folder (~0.6 seconds) and continue on. But it seems in your case you're using a locally built image, which never makes its way into the cache folder and it hard fails for you. Since you've identified the issue we're more than open to you creating a PR to resolve the issue if you have the time, if not just let us know and we'll create the fix. Thanks for bringing this to our attention!

[evanskinner]

Thanks very much for the analysis and thanks for the pointer about the cache folder. Our base image is pulled from a remote registry, using docker pull before I start minikube as minikube does not have the creds necessary to pull it, so I guess as far as minikube is concerned it is effectively a local image. It sounds like if I can find it on diks and then copy it into the cache folder I might be able to bypass the check, I might give that a gom, than you. For now we are using minikube 1.33.1 and that works fine.

I would create the PR, but all the legal termas and conditions I have to accept to do so makes that difficult for me, sorry,

[evanskinner]

Thank you @medyagh and @spowelljr

[spowelljr]

@evanskinner Just a heads up that you can use the binary built in the PR for now until the next release that has the fix

https://storage.googleapis.com/minikube-builds/19664/minikube-linux-amd64