How to use `/snap/bin/chromium.chromedriver` instead of foreign arch's chromedriver on arm64 ubuntu?

znz commented 2 years ago

Summary

I want to use chromedriver in snap package instead of x86-64's chromedriver without modifying source codes. I want to use environment variables or detect automatically.

Debug Info

Please provide the following information for bug reports:

Webdrivers version: x86_64-binfmt-P: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
Ruby version: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [aarch64-linux]
Operating system / CI Environment: Ubuntu 21.10 (aarch64)
Browser and version: chromium snap installed: 98.0.4758.102 (1911) 146MB -

Expected Behavior

Use chromedriver in PATH (created by sudo snap alias chromium.chromedriver chromedriver) or /snap/bin/chromium.chromedriver as chromedriver.

Actual Behavior

~/.webdrivers/chromedriver is a foreign architecture binary, and it does not work normally.

$ ~/.webdrivers/chromedriver --version
x86_64-binfmt-P: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

It works with qemu-x86_64-static and QEMU_LD_PREFIX, but it hangs in rspec.

$ mmdebstrap --arch=amd64 --include=dbus --customize-hook='echo amd64-bullseye > "$1/etc/hostname"' --customize-hook='echo "127.0.1.1 amd64-bullseye" >> "$1/etc/hosts"' --customize-hook='printf "auto host0\niface host0 inet dhcp\n" > "$1"/etc/network/interfaces.d/host0' bullseye /tmp/amd64-bullseye.tar
$ sudo machinectl import-tar /tmp/amd64-bullseye.tar
$ sudo systemctl start systemd-nspawn@amd64-bullseye
$ sudo systemctl shell systemd-nspawn@amd64-bullseye
# apt update
# apt install libglib2.0-0 libnss3
# exit
$ env QEMU_LD_PREFIX=/var/lib/machines/amd64-bullseye ~/.webdrivers/chromedriver --version
ChromeDriver 98.0.4758.102 (273bf7ac8c909cde36982d27f66f3c70846a3718-refs/branch-heads/4758@{#1151})

My current workaround is

$ ln -sfn /snap/bin/chromium.chromedriver ~/.webdrivers/chromedriver
$ ~/.webdrivers/chromedriver --version
ChromeDriver 98.0.4758.102 (273bf7ac8c909cde36982d27f66f3c70846a3718-refs/branch-heads/4758@{#1151})

blerner commented 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...

jamesgecko commented 2 years ago

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!

titusfortner commented 2 years ago

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

blerner commented 2 years ago

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.

titusfortner commented 2 years ago

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"]

blerner commented 2 years ago

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

titusfortner commented 2 years ago

Duplicate of #217 will track there.

titusfortner / webdrivers