minikube fails to suggest rootless when sudo is missing

[ambasta]

What Happened?

On attempting to start minikube, if sudo is not installed, minikube exits with incorrect information and fails to suggest rootless.

💡  Suggestion: Add your user to the 'sudoers' file: 'ambasta ALL=(ALL) NOPASSWD: /usr/bin/podman' , or run 'minikube config set rootless true'

Attach the log file

$ minikube start --driver podman --container-runtime cri-o
😄  minikube v1.30.1 on Gentoo 2.14
✨  Using the podman driver based on user configuration

💣  Exiting due to PROVIDER_PODMAN_NOT_RUNNING: exec: "sudo": executable file not found in $PATH
📘  Documentation: https://minikube.sigs.k8s.io/docs/drivers/podman/

Operating System

Other

Driver

Podman

[rmsilva1973]

@ambasta The output message specifically says "or run 'minikube config set rootless true'". What's missing here?

[rmsilva1973]

/kind support

[ambasta]

@rmsilva1973 The actual output is

$ minikube start --driver podman --container-runtime cri-o
😄  minikube v1.30.1 on Gentoo 2.14
✨  Using the podman driver based on user configuration

💣  Exiting due to PROVIDER_PODMAN_NOT_RUNNING: exec: "sudo": executable file not found in $PATH
📘  Documentation: https://minikube.sigs.k8s.io/docs/drivers/podman/

which doesn't suggest setting rootless at all

[rmsilva1973]

I think it could suggest using rootless. But I don't think it's reasonable to instruct the user to change sudoers since the message says it couldn't even find sudo executable. It looks more reasonable a message like this

💡 Suggestion: Add "sudo" to your $PATH (and configure sudoers), or run 'minikube config set rootless true'

[ambasta]

That would be fine as well. I just started using minikube, and I believe as a beginner, the rootless sugesstion would have saved a ton of time, specially on bespoke distributions where sudo isn't necessarily installed

[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.