I have a Raspberry Pi 3b+. I wrote a .NET Core 5.0 program which uses Selenium to do some tasks on the browser. It all works 100% fine on my Windows PC. But it has errors when ran on the Raspberry Pi running 64 bit Ubuntu Server Focal version. I have the Gecko driver and Firefox installed. The program is able to complete its tasks, but throws many many errors about:
"Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: Unable to open a connection to the X server (t=4.70096) [GFX1-]: glxtest: Unable to open a connection to the X server"
"JavaScript warning: https://js.arcgis.com/3.38/esri/dijit/BasemapGallery.js, line 22: WebGL warning: : WebglAllowWindowsNativeGl:false restricts context creation on this system."
"* Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS)"
"JavaScript warning: https://js.arcgis.com/3.38/init.js, line 1171: Failed to create WebGL context: WebGL creation failed:"
I tried installing xvfb but that did nothing. I am running headless and the driver confirms that I am running headless, but seems to be expecting a display regardless????
How do I solve these errors? Note, I do not care if I have to use Firefox, Chromium, or some other browser. But it seemed like Firefox was the most straightforward to install.
I figured it out. I changed operating systems to Raspberry Pi OS 64-bit Lite beta, easily installed Chrome and Chrome Driver... no problems.
I guess the problem was when running Ubuntu, the package repositories had mis-matching versions for arm64 packages and some things installed via 'snap', which is a no-go for programs that have to work together. On the Raspberry OS repository, they had matching versions and no 'snap'. At least it all works now in case anyone else sees this.
Related
Hi.
I am using selenium to control chromium in order to do some low-effort scraping. I am also on linux, inside the crostini container for chromeOS, which complicates things a bit. I get this code running on windows just fine, but inside the linux container, I can't get it to work. It always opens a window (chromium presumably), which then quickly closes and the program fails with the message WebDriverException: Message: unknown error: unable to discover open window in chrome.
relevant code (w/o imports)
options = webdriver.ChromeOptions()
options.add_argument('--mute-audio')
options.add_argument('--log-level=3')
driver = webdriver.Chrome(options=options)
installed packages
chromium
chromium --version: Chromium 102.0.5005.61 built on Debian 11.3, running on Debian 11.3
chromium-driver
chromium-driver --version: ChromeDriver 102.0.5005.61 (0e59bcc00cc4985ce39ad31c150065f159d95ad3-refs/branch-heads/5005#{#819})
Does anybody know how to fix this? I can't seem to find any solution to that by googling...
I have a Windows 10 laptop running a Windows 7 Virtual Machine. Inside the Virtual Machine, when i start the WebDriver, it gives the error gpu_process_transport_factory.cc<1009> Lost UI shared context when it is started:
IWebDriver driver = new ChromeDriver() //This causes the 1009 Error
Also then varies for Failed to query stereo recording and Failed to send GpuChannelMsg_CreateCommandBuffer and command_buffer_proxy_impll.cc<115> Shared memory handle is not valid.
This has been working for months and no changes were made (this WebDriver is the sole purpose of the Virtual Machine), the laptop running it is running fine (ie. no GPU problems). The WebDriver still navigates through pages, but giving further errors and 10x slower.
EDIT: Updated to ChromeDriver to 2.35 and still the same behavior.
Headless Chrome was shipped in Chrome 59 by Google Team which introduced a way to run the Chrome Browser in a Headless Environment.
A note was added as :
Headless mode has been available on Mac and Linux since Chrome 59. Windows support came in Chrome 60.
The article Getting Started with Headless Chrome mentioned that :
--disable-gpu \ # Temporarily needed if running on Windows.
A note was added as :
Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.
As per the discussion Headless: make --disable-gpu flag unnecessary it was clear that :
The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.
What happened under the hood?
As per the discussion headless: Switch from osmesa to SwiftShader as Google/Chromium team decided to ship SwiftShader with Chrome, the team thought to start using it to render GL content in Headless Mode. This required a couple of changes as follows :
Skip GPU data collection in Headless Mode since SwiftShader isn't considered a software implementation by that code which lead to a failure when we tried to retrieve information from the Window System.
Only skip GL initialization in InitializeStaticEGLInternal if we intend to use osmesa. SwiftShader requires initialization like the other non-software implementations.
SwiftShader is currently not supported on Mac OSX, so the team decided to continue to use the physical GPU in Headless Mode on that platform (unlike on other platforms where everything is software rendered).
So, to disable WebGL support in Headless Mode they decided to use --disable-gpu and --disable-software-rasterizer
The idea to Support WebGL in headless is still under discussion but SwiftShader fails an assert on Windows in headless mode with an error as :
[0117/125830.649194:ERROR:gpu_process_transport_factory.cc(1043)] Lost UI shared context.
DevTools listening on ws://127.0.0.1:37429/devtools/browser/1f0b2bf7-dfdd-44ac-9da7-f2659d352f0d
Conclusion
This error doesn't impact your #Test and you can ignore the error for the time being.
This appears to be an issue with the latest version of Chrome (65.0.3325.146). By rolling back to an earlier version of Chrome (64.0.3282.186) the issue disappeared for me.
Will investigate further and update here if I find any more info but as a temporary workaround you can uninstall chrome and install version 64.0.3282.186.
'Lost UI Shared Context' was mistaken for an error while it's actually a logging output.
This has been fixed since Chrome 72.0. no extraneous arguments needed.
Background
I am tasked with replacing our IE based printing logic with Chromium so that we can eventually support running our current server software on Windows Server Core or potentially other operating systems that support .Net Core. My current thought is to either use Chromium embedded framework or to make use of Puppeteer. I am leaning towards the later because I feel it would be easier to port between operating systems.
Issue
Originally it failed to start with an error about sandboxing so I added the no-sandbox flag. Now when I try to load Chromium it fails to start with the exception below stating that it cannot load chrome.dll
PS C:\Program Files (x86)\Google\Chrome\Application>> .\chrome --headless --enable-logging --disable-gpu --screenshot="C:\screen.png" "https://www.chromestatus.com/"
Which yields the following error in the debug.log file:
[0813/133208.016:ERROR:main_dll_loader_win.cc(134)] Failed to load Chrome DLL from c:\Program Files (x86)\Google\Chrome\Application\68.0.3440.106\chrome.dll: The specified module could not be found. (0x7E)
I have checked around the internet and found a few mentions of this error but the suggested fixes don't seem to fix the issue.
I was able to download Chromium 72.0.3592.0 via Chocolatey and the issue is resolved in that version. I tested using Server Core 2016 LTSB.
choco install chromium --pre -y
chrome --headless --disable-gpu --dump-dom --enable-logging https://www.chromestatus.com/ --no-first-run
Edit:
If you are attempting to run Selenium Tests using Docker windowsservercore and chromium: The command line tests of chromium chrome.exe appear to never work from the container command line.
However when you run dotnet test app.csproj or dotnet vstest app.dll inside the container the webdriver successfully starts and drives the browser
This has been reported to the Chromium team. It appears that Chromium 68+ might have issues with Windows Server 2016.
https://bugs.chromium.org/p/chromium/issues/detail?id=873097
I'm working on a debian 6.0 installed on virtualbox 4 hosted by Windows7, and I'm trying to get my STM32VL work using STLINK project that allows programming and debugging STM32 on Linux.
I followed their tutorial and installed all needed dependancies.
But when I run the program ./st-util -1, I get the following error:
tbarry#darkstar:~/stlink$ ./st-util -1
2014-03-20T10:18:48 WARN src/stlink-sg.c: Failed to find an stlink v1 by VID:PID
Error: could not open stlink device
Error: could not open stlink device
I underline that I have already installed Virtualbox extensions, and usb 2.0 is well handled.
Does anyone have an idea of what is blocking me?
I'd same problem. It was driver problem. Windows detected my st-link as mass storage device, so st-util didn't see it. I've used zadig utility in order to change the driver.
Not having found a solution to my problem, I tried with VMware player and it worked nice.
Conclusion: Whatever the problem I had, it was coming from VirtualBox.
I have a client who had a script working and now stopped working. I run it in my computer and it works (i runned it on Linux and Windows). My client runned it on Mac and Windows.
I am new to Selenium, but the part of the code that crashes is where Selenium takes place, it gets the Firefox to open but not load the page. I think it migth be a problem with the webDriver of Selenium that must be updated.
I told him to install pip in his Mac and uninstall Selenium and reinstall it, is this how it is done in OS machines? Is there any issue related to my problem?
Thanks
It would be helpful if you had specify Selenium version and also which browser are you using and it's version too. But the behavior you described seems to be caused by having newer version of browser which the Selenium version you using doesn't support. So upgrading to newest version of Selenium (2.35) will likely make this problem disappear.