webdrivers: Using under Docker, using Arm images, on M1 Mac causes error
Summary
Docker Desktop for Mac on M1, by default, where possible pulls Linux images to match the M1 architecture. When such an image uses the webdrivers gem, it downloads and attempts to use a Linux chromedriver built for x86 CPUs. This causes an error when the gem tries to launch the driver. Note that the repository of chromedrivers from which webdrivers pull the driver only has linux-x86 compiled drivers, so it’s not clear if this can be solved.
Debug Info
Please provide the following information for bug reports:
- Webdrivers version: Any latest version
- Ruby version: 2.6.6, but I’d imagine all versions would be affected
- Operating system / CI Environment: Docker Desktop 3.3.3 under Big Sur on an M1 Macbook Pro
- Browser and version: Chrome (any latest version)
Expected Behavior
webdrivers should use a chromedriver built for Linux on an arm CPU.
Actual Behavior
An error is thrown and execution is aborted:
/lib64/ld-linux-x86-64.so.2: No such file or directory
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 22 (6 by maintainers)
We are having this issue on M1 Macs, too
I’ll reopen while we check it out.
I’ve been working on how to get all of this functionality directly into Selenium. Ideally we won’t need a separate project to manage drivers in the near future.
Yeah, there’s some concern about how to manage drivers that aren’t provided by the browser vendor directly I think the requirement needs to be that Google support it — https://github.com/GoogleChromeLabs/chrome-for-testing#:~:text=the current list of supported platforms is
The alternative manually updating the known-good driver version as necessary and putting them in a location on PATH as you are doing. You can set the browser not to automatically update versions, or use Chrome for Testing binaries which won’t auto update.
Does anybody have any individual winning combination (chrome version + electron version) using the electron releases? Maybe at least as a semi-workable solution
webdriverscould contain a hardcoded hash of known working version couples?This looks like a valid use case that we could consider supporting in the future, but I, unfortunately, don’t have a M1 mac to investigate/troubleshoot or fix this. If the chromedriver downloads site starts providing arm binaries, then this could be easy to support. I know the electron project releases various arm binaries, but their versioning does not match the Chrome versioning, which is what
webdriversuses to determine which driver version to download.If anyone has any ideas or is interested in submitting a PR for this, I’d be happy to collaborate and/or review PR(s).