none driver doesn't start if /bin/bash doesn't exist.

[alunduil]

Command:

minikube --logtostderr start -p sentinel --vm-driver none

Output: https://gist.github.com/alunduil/1e78933095fc69402ec0dc2e0927724f
Minikube logs: https://gist.github.com/alunduil/a05cc1071bb0cf709f875817198d20f8
My os-release: https://gist.github.com/alunduil/f49e9aa43b826de82011eada8dc4cf75

In NixOS, there is no /bin/bash so starting the none driver fails to function. A simple fix for this error would be to use /usr/bin/env to invoke bash by following the path rather than assuming that it's hard coded, but I'm not sure what other assumptions that might break. This solution should work because NixOS ensures a symlink exists at /usr/bin/env that points at the executable and most distributions that I'm aware of ship with /usr/bin/env.

If that sounds like a reasonable solution, I can work on figuring out a pull request (unless someone can get to it faster).

[alunduil]

I found also, that I cannot delete the machine using minikube delete -p sentinel in this situation but deleting the entries from .minikube/{profiles,machines} seems to have worked.

I also forgot to mention that the following line (for quick reference) has the /bin/bash invocation:

minikube/pkg/minikube/bootstrapper/exec_runner.go

Line 40 in 27d8234

c := exec.Command("/bin/bash", "-c", cmd)

[tstromberg]

Thanks for the bug report! I don't love that minikube requires a shell at all, but this seems like reasonable workaround. My preference however is to call exec.LookPath() instead of double-forking. I'd be happy to review a PR which does so.

Thanks again!

[tstromberg]

Alternatively - perhaps this should just use /bin/sh. We shouldn't be doing anything bash specific.

[alunduil]

@tstromberg I thought about that but didn't know if minikube used any bash specific code in its commands. If that works then it will work on systems like NixOS as well. I'll look into what it will take for me to submit the pull request making that change, but if someone else is also interested in this issue they should feel free to not wait for me.

[afbjorklund]

Or maybe just continue to use /bin/bash where available, and do the LookPath thing otherwise ?

I haven't investigated how bashist the scripts are, but do recall having to install bash just for minikube...

Supporting NixOS for running the "VM" is probably strectching things.

Hopefully nothing else breaks, otherwise welcome to use Minikube OS.

[alunduil]

@afbjorklund is minikube no longer the recommended way to setup a development kubernetes cluster without any configuration? In this case, the issue is just the none driver's shell invocations which seem more portable by using sh anyway. I haven't seen minikube OS but I can look into that if it's the recommended replacement for minikube.

@tstromberg is the bash -c there just to lookup the command in the path? If so, then LookPath seems like the better solution in general.

Why would LookPath not be preferred over invoking bash?

[afbjorklund]

Currently minikube assumes and expects that you start in a VM dedicated for the purpose (of running Kubernetes). The "none" driver bypasses VM allocation and let's the user provide their own VM.

Using minikube to run directly on the laptop (or other developer machine) is not well defined, and assumes things - such as /bin/bash. We can make it better, but VirtualBox is still the supported mainstream.

[alunduil]

@afbjorklund that makes more sense. Yeah, I'm not looking to do this for the general case but I'm making a test harness that interacts with minikube and running through the motions with the none driver real quick makes the verification that my test harness is working correctly much faster.

I'll see about submitting a pull request for changing the shell used or using the path for the none driver.

Thanks for the caveats to the none driver!

[palnabarun]

@tstromberg I would like to work on the transition to using exec.LookPath. I am a new contributor to kubernetes community.

From the above conversation, I can infer that I have to find the full path of the command using exec.LookPath and then execute the command using the very same workflow.

[alunduil]

@palnabarun that's my understanding as well. You can do a quick test that this is working by creating a chroot or other isolated environment and ensure that bash can be found by looking the in the PATH when stored in a non-standard location.

Alternatively, if you want to setup a NixOS VM, testing should be direct in that environment since there isn't any /bin/bash.

[palnabarun]

Thanks @alunduil for the insights. :) I will test it out inside a NixOS VM.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[medyagh]

@alunduil I would love to see removing the depdendecy on bash, however some commands we have in bootstrapper, does use bash functions,

as part of this PR #5530
a lot of the commands were converted to exec.Cmd format in this PR but others need more work to do so.

I would review any PR that carefully converts the commands to exec.Cmd format ( with args as oppsed to /bin/bash/ -c

[alunduil]

Remember, that I'm fine with bash as long as the path is not assumed since different systems may place it elsewhere. Using /usr/bin/env seems to be the canonical way to invoke it without worrying about where it might live, but I'm sure this has problems on some systems as well (I don't know of any but didn't want to assume it was perfect).

[afbjorklund]

A quick LookPath should fix this.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.