Closed znz closed 2 years ago
I have a similar issue on Ubuntu 20.04, though the symlink workaround doesn't quite seem to work for me (selenium decides to download a driver and overwrite the symlink anyway). I don't know if this is directly relevant, but https://github.com/bonigarcia/webdrivermanager/issues/403 seems remarkably similar...
It's also a problem on Debian Buster, which does not use Snap. This gem ignores the arm64 system chromedriver binary installed by the chromium-driver
package in favor of trying to download and run an amd64 binary.
I resolved this by deleting the ~/.webdrivers/chromedriver
binary this gem installed and removing webdrivers
from my Gemfile. If you're going to depend on a system binary, this gem is unnecessary. Although it'd be really nice if the gem would download a binary of the correct architecture!
Add this to your Selenium code and Selenium will ignore webdrivers gem.
service = Selenium::WebDriver::Service.chrome(path: "path/to/my/known/driver")
driver = Selenium::WebDriver.for :chrome, service: service
The OP said they were trying to get the right binary without having to modify their source code. I agree; my dev environment and my Travis build aren't the exact same flavor of Linux, and specifying the binary in my source will make one or the other of them break. I don't think this is a workable solution.
I'm not trying to be flippant, but I don't understand what isn't a workable situation.
service = Selenium::WebDriver::Service.chrome
service.path = ENV["KNOWN_CHROMEDRIVER"] if ENV["TRAVIS_CI"]
Using the webdrivers gem downloads the right driver and configures itself automatically. It Just Works, which is a really nice feature to have. Having the gem download the wrong driver seems like a layering violation, and requires the user of the gem to know enough to find the correct driver on their own (which updates versions all the dang time, whenever chromium updates). Since chromium-as-a-snap-package is now a common installation mechanism for chromium, it would be nice for webdrivers to support it as smoothly as it does the other packaging modes. The issue I linked above in webdrivermanager seems to me the right sort of solution.
Personally, I'm no longer blocked on this issue; I have a workaround in place (that's a bit more cumbersome than the one above) for now. But I'd like to take that hack out of my code eventually...
Duplicate of #217 will track there.
Summary
I want to use
chromedriver
in snap package instead of x86-64'schromedriver
without modifying source codes. I want to use environment variables or detect automatically.Debug Info
Please provide the following information for bug reports:
x86_64-binfmt-P: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [aarch64-linux]
installed: 98.0.4758.102 (1911) 146MB -
Expected Behavior
Use
chromedriver
in PATH (created bysudo snap alias chromium.chromedriver chromedriver
) or/snap/bin/chromium.chromedriver
aschromedriver
.Actual Behavior
~/.webdrivers/chromedriver
is a foreign architecture binary, and it does not work normally.It works with
qemu-x86_64-static
andQEMU_LD_PREFIX
, but it hangs in rspec.My current workaround is