Minikube v1.30.0+ (with Go 1.20) do not run on Alpine Linux

[Nuru]

What Happened?

Minikube v1.29.0 ran under Alpine Linux, but v1.30.0 and v1.30.1 do not. Please either fix the build so that it works under Alpine or state your intention to not support Alpine. See golang/go#59305 (comment) for more information.

$ curl -sSL -o minikube https://github.com/kubernetes/minikube/releases/download/v1.30.0/minikube-linux-amd64
$ ls -l minikube 
-rw-r--r--    1 root     root      83945324 Apr  3 23:01 minikube
$ chmod a+x minikube 
$ ls -l minikube 
-rwxr-xr-x    1 root     root      83945324 Apr  3 23:01 minikube
$ ./minikube version
/bin/sh: ./minikube: not found
$ # Note: under Alpine, running a command that exists and getting
$ # a "not found" error usually indicates a missing dynamic library.
$ ldd minikube 
	/lib64/ld-linux-x86-64.so.2 (0x7f2f482ec000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f2f482ec000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f2f482ec000)
Error loading shared library libresolv.so.2: No such file or directory (needed by minikube)
Error relocating minikube: __res_search: symbol not found

$ cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.16.3
PRETTY_NAME="Alpine Linux v3.16"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

References

• Error loading shared library libresolv.so.2 on Alpine in Go 1.20  golang/go#59305
• Error loading shared library libresolv.so.2 on Alpine in Go 1.20 golang/go#59304

Attach the log file

No log generated

Operating System

Other

Driver

None

[afbjorklund]

If you want to run on Alpine, I think you need to install the glibc compatibility package.

https://wiki.alpinelinux.org/wiki/Running_glibc_programs

Or better yet, use a version of minikube that has been built for it (and the musl library) ?

https://pkgs.alpinelinux.org/package/edge/testing/x86_64/minikube

[afbjorklund]

You can also resort to some hack like (with gcompat installed):

ln -sf ../../lib/libgcompat.so.0 /usr/lib/libresolv.so.2

It (alpine) is not unsupported, but it is also not explicitly supported...

• Trouble setting up minikube in Alpine Linux #10805

EDIT: need to use libgcompat.so explicitly

[Nuru]

If you want to run on Alpine, I think you need to install the glibc compatibility package.

https://wiki.alpinelinux.org/wiki/Running_glibc_programs

I have the glibc compatibility package installed.

Or better yet, use a version of minikube that has been built for it (and the musl library) ?

https://pkgs.alpinelinux.org/package/edge/testing/x86_64/minikube

There is no package there for v1.30.0, I expect because it takes its binaries from this repo's Release Assets, and this repo's release asset for v1.30.0 doesn't run on Alpine.

v1.30.1 also doesn't run on Alpine.

I am asking the maintainers of the build process to either fix their build so it works on Alpine (as did all the prior versions) or declare they are not going to support Alpine going forward, so we can have a clear answer to the question of are they going to continue to support Alpine.

[afbjorklund]

I expect because it takes its binaries from this repo's Release Assets, and this repo's release asset for v1.30.0 doesn't run on Alpine.

It is built from source, so I think you need to request a new version in Alpine using the normal (Alpine) channels ?

https://git.alpinelinux.org/aports/tree/testing/minikube/APKBUILD

You can also install the git and go packages, and build a newer version of minikube yourself. (with make) ?

https://minikube.sigs.k8s.io/docs/contrib/building/binaries/

I am asking the maintainers of the build process to either fix their build so it works on Alpine (as did all the prior versions) or declare they are not going to support Alpine going forward, so we can have a clear answer to the question of are they going to continue to support Alpine.

Once the glibc compatibility (in Alpine) is fixed to also include libresolv.so, then the glibc binaries will work again.

I don't think minikube will build or provide any binaries using musl for download, so they will continue to use glibc.

But if you want a "native" package, then apk add minikube is recommended.

It is in testing repo, while you can find docker in the community repository...

[afbjorklund]

This is the repository: https://git.adelielinux.org/adelie/gcompat

As per above, it needs at least __res_search from libgcompat

It adds libpthread.so.0

But not libresolv.so.2

[Nuru]

@afbjorklund I appreciate your effort at trying to solve the problem "how do I get minikube v1.30 to work on Apline?" However, that is not the problem I am interested in solving or the question I want answered.

Up until v1.30, I could install minikube on Alpine with

$ apk add libc6-compat
$ VERSION=1.29.0 # for example
$ curl -o /usr/local/bin/minikube -sSL https://github.com/kubernetes/minikube/releases/download/v${VERSION}/minikube-linux-amd64
$ chmod a+x /usr/local/bin/minikube

Starting with version v1.30.0 this no longer works. It also does not work if I substitute gcompat for libc6-compat. My question/request is will the build maintainers fix the build so that I can continue to install this way, or do I have to switch to finding some other way to install minikube on Alpine, such as building it myself or finding a prebuilt Alpine package in an Alpine package repository?

At the moment, the only Alpine package I can find for minikube is in testing/edge, and the latest is v1.29.0. So installing from Apline packages is not a solution for installing v1.30.1 right now. There is always a lag with packages, which is why I prefer to download assets directly where possible.

[afbjorklund]

It would be possible to also build musl binaries of minikube, but right now there are no release jobs to do it.

But I don't think the Go maintainers will revert the change of not providing resolv, that was introduced in 1.20...
So the glibc binaries of minikube, will now require both libpthread.so and libresolv.so in addition to libc.so.6 (glibc)

Thanks for mentioning libc6-compat, that is the package where the libresolv.so.2 should be added to make it work.
Then the symlink workaround above would not be needed anymore, for those 4 symbols provided by gcompat.

The v1.29.0 binary was not native to Alpine either, but then there was enough default compat support to make it run.

[afbjorklund]

There should be some documentation provided, about the minimum OS requirements of the binaries provided.

• Add some more "fine print" to the installation requirements #10808

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.