-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[macOS] Cannot start VM with podman machine start because it tries to start gvproxy from /usr/libexec/podman/gvproxy
#11226
Comments
@ashley-cui Are we not shipping gvproxy? |
@rhatdan I'm currently working on shipping it via homebrew. Though the gvproxy is not shipped in our tarball that's downloaded from github artifacts. |
ill take this one ... |
@baude just FYI, homebrew doesn't automatically symlink libexec.install (it does for every other location but not libexec) got me tripped up on Thursday.. |
macos does not have /usr/libexec/ so we look in the executable paths first. Fixes: containers#11226 Signed-off-by: Brent Baude <bbaude@redhat.com>
macos does not have /usr/libexec/ so we look in the executable paths first. Fixes: containers#11226 [NO TESTS NEEDED] Signed-off-by: Brent Baude <bbaude@redhat.com>
I was able to podman machine start using the updated v3.3 branch.
|
macos does not have /usr/libexec/ so we look in the executable paths first. Fixes: containers#11226 [NO TESTS NEEDED] Signed-off-by: Brent Baude <bbaude@redhat.com>
Presented as an alternative to PR containers#11449 Rather than do backflips in the code to locate `gvproxy`, use a build-time variable to set the location. That variable can default to `/usr/libexec` but other build packages (_e.g._ Homebrew) can set it to something of their liking. I'll take no offense if the consensus is that we do not want to pollute the build, but we should likely add a runtime configuration parameter as an alternative in that case. Fixes: containers#11226 Signed-off-by: Jonathan Springer <jonpspri@gmail.com>
macos does not have /usr/libexec/ so we look in the executable paths first. Fixes: containers#11226 [NO TESTS NEEDED] Signed-off-by: Brent Baude <bbaude@redhat.com>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When I run
podman machine start
even though I have placed gvproxy in a valid execution path, I get an error that gvproxy is not found in the path and cannot start the VM.Steps to reproduce the issue:
On the Mac client:
Get the Podman 3.3.0-rc2 source code and build it
Get the gvproxy binary and place it in execution path
Describe the results you received:
I can't create directories under /usr/libexec/ even if I have root privileges.
The reason is that System Integrity Protection is currently enabled in macOS.
https://support.apple.com/en-us/HT204899
Describe the results you expected:
The VM will be successfully started.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: