It looks like Slackware 14.2 is starting to show its age when it comes to supporting Chromium. The packages that I uploaded earlier this week for Chromium (also -ungoogled) version 109.0.5414.74 failed to run on Slackware 14.2 despite the fact that they were successfully compiled on Slackware 14.2. The packages ran without complaint on Slackware 15.0 and -current however.
The cause was a run-time dependency on libdrm for which the minimum version requirement was increased in Chromium 109 and Slackware 14.2 contains a libdrm library that is now too old.
After finding that root cause, I have rebuilt the chromium (also -ungoogled) packages, this time using an internal copy of libdrm instead of relying on the system libraries. The BUILD=2 version of these packages is now available for download from my repository and its mirrors, they are working correctly on Slackware 14.2 again.
Have fun! Eric
Many thanks Eric – much appreciated.
Pingback: Links 19/01/2023: Release of DietPi 8.13 and Ubuntu Delays Due to Microsoft’s Restricted Boot | Techrights
Thank you, Eric! 🙂
Thanks for Chromium 109.0.5414.119 update!
Hum, Chromium 109.0.5414.119 fails on my machine (Slackware 15.0, up to date) with
[minigbm:drv_helpers.c(364)] DRM_IOCTL_MODE_CREATE_DUMB failed (31, 13)
Should I try the 14.2 version? 🙂
Is this 64bit or 32bit?
Is your account allowed to write to “/dev/dri/renderD*” (i.e. is your user in the “video” group)?
If these questions are not relevant for your case, there’s simply no information in your post. Please open a Chromium bug report: https://bugs.chromium.org/p/chromium/issues/list
It’s the 32 bits Slackware. On another, 64 bits machine it “just works”.
To be sure I’ve checked both the ungoogled and normal version, and the two versions fail (display a sad folder with “error -11”) for all user accounts. The interface works, the history is full, but no page loads. After checking the accounts are in the video group and can write to /dev/dri/renderD* . I’ve been misguided by the error messages, obviously the problem lies elsewhere. Even through remote display (X11 or VNC) it fails, but with entirely different errors:
Through X11:
[30384:30408:0203/173525.280184:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30408:0203/173525.280253:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30408:0203/173525.390569:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30408:0203/173525.390614:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30408:0203/173526.874587:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30408:0203/173526.874622:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are “tcp” and on UNIX “unix”)
[30384:30401:0203/173536.968614:ERROR:nss_util.cc(357)] After loading Root Certs, loaded==false: NSS error code: -8018
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[30421:30421:0203/173538.300955:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
Through a VNC session, no dbus error, but fails all the same in the end:
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[25267:25267:0203/173213.659565:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[25309:25309:0203/173214.269796:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[25330:25330:0203/173214.696022:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[25347:25347:0203/173214.845600:ERROR:gpu_memory_buffer_support_x11.cc(49)] dri3 extension not supported.
[25234:25254:0203/173214.969877:ERROR:nss_util.cc(357)] After loading Root Certs, loaded==false: NSS error code: -8018
Weird…
To be clear I forgot to mention, on my 64 bit slackware system, Chromium spits
[minigbm:drv_helpers.c(364)] DRM_IOCTL_MODE_CREATE_DUMB failed (40, 13)
in the console but work perfectly well, so that’s definitely not the problem…
On 32bit Slackware you do realize that Chromium usually fails to render content into its window unless you add the commandline parameter “–disable-seccomp-filter-sandbox”?
No, I didn’t know; it used to work fine “as is”, and I rarely use Chromium, only on websites incompatible with Firefox which are fortunately not that many.
It seems to solve the problem, thank you.
I assume you do not follow my blog or read my package repository’s ChangeLog.txt. Otherwise you would have known for a long time.
Good to hear that once more, this parameter fixes Chromium issues on 32bit OS for someone.
Could you upload the handbrake 1.6.0 SlackBuild to SBo, please?
No. I am not the handbrake script maintainer on SBo.
Thanks for the Chromium 110.0.5481.77 update!