There’s new ‘chromium‘ and ‘chromium-widevine-plugin‘ packages in my repository. And chromium-ungoogled packages will follow soon.
Chromium was upgraded to 90.0.4430.72 but unfortunately the 32bit package which I have built (twice) crashes immediately on startup. This happens both on Slackware 14.2 and on -current. The error message looks like it is something different than the glibc-2.3x related seccomp crash behavior in the previous Chromium 89.x releases.
Since I don’t have hardware that is running a 32bit Slackware OS and could only test on QEMU virtual machines so far, I can not confirm with 100% certainty that the new Chromium will or will not work on your 32bit Slackware OS, which is why I also kept the older 32bit chromium-89.0.4389.114 package in the repository.
Let me know about your experiences down here in the comments section! I am getting tired of begging Google developers not to break 32bit binaries every major release. I’d be grateful if people running 32bit Slackware who are affected by the 32bit Chromium crashes, would chime in. Else I will eventually have to drop 32bit support.
There’s also an updated Widevine plugin package, unfortunately Google only released this newer version for 64bit systems. The new 64bit package has version “4.10.2209.1” whereas the 32bit package remains at version “4.10.1582.2”.
Note that this Widevine plugin is meant for chromium-ungoogled only. The ‘real’ Chromium does not need or use it, since Chromium downloads this CDM library automatically for you.
Many thanks for persevering with 32-bit versions of Chromium.
The latest version 90.0.4430.72 runs on a 32-bit Slackware Current “based” system (Puppy Linux) but only with the –disable-seccomp-filter-sandbox switch. Without this switch it does crash but as you say with different error messages to previous versions.
There is also a 32-bit version available from Snap (https://snapcraft.io/chromium) and this behaves similarly – i.e. it needs the switch – but the error message is different.
Chromium 90.0.4430.72 (Developer Build) by AlienBob packaged for Puppy Linux Run-As-Spot (32-bit)
User Agent Mozilla/5.0 (X11; Linux i686 (x86_64)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.72 Safari/537.36
Command Line /usr/lib/chromium/chromium –disable-seccomp-filter-sandbox -test-type –disk-cache-size=10000000 –media-cache-size=10000000 –allow-outdated-plugins –flag-switches-begin –flag-switches-end
Executable Path /usr/lib/chromium/chromium
Profile Path /home/spot/.config/chromium/Default
Hi PeeBee, can you share the exact error messages please?
Calling _exit(1). Core file will not be generated.
Received signal 11 SEGV_MAPERR 000000000000
#0 0x00005a97dbdf (/usr/lib/chromium/chromium+0x43a2bde)
#1 0x00005a8dee42 (/usr/lib/chromium/chromium+0x4303e41)
#2 0x00005a97d836 (/usr/lib/chromium/chromium+0x43a2835)
#3 0x0000f7ed1570 ([vdso]+0x56f)
#4 0x00005c657638 (/usr/lib/chromium/chromium+0x607c637)
#5 0x00005c65df1e (/usr/lib/chromium/chromium+0x6082f1d)
#6 0x00005c65dca2 (/usr/lib/chromium/chromium+0x6082ca1)
#7 0x00005c65dc11 (/usr/lib/chromium/chromium+0x6082c10)
#8 0x00005c64cb86 (/usr/lib/chromium/chromium+0x6071b85)
#9 0x00005c64b13b (/usr/lib/chromium/chromium+0x607013a)
#10 0x00005c64b9b9 (/usr/lib/chromium/chromium+0x60709b8)
#11 0x00005c649759 (/usr/lib/chromium/chromium+0x606e758)
#12 0x00005a4a3a55 (/usr/lib/chromium/chromium+0x3ec8a54)
#13 0x00005a882844 (/usr/lib/chromium/chromium+0x42a7843)
#14 0x00005a882e39 (/usr/lib/chromium/chromium+0x42a7e38)
#15 0x00005a883b36 (/usr/lib/chromium/chromium+0x42a8b35)
#16 0x00005a881113 (/usr/lib/chromium/chromium+0x42a6112)
#17 0x00005a881b1b (/usr/lib/chromium/chromium+0x42a6b1a)
#18 0x0000578f5f19 ChromeMain
#19 0x0000578f5e1f (/usr/lib/chromium/chromium+0x131ae1e)
#20 0x0000f6761889 __libc_start_main
gs: 00000063 fs: 00000000 es: 0000002b ds: 0000002b
edi: ffb382a0 esi: 62a7831c ebp: ffb38278 esp: ffb38260
ebx: 608040b0 edx: 00000002 ecx: 605dc948 eax: 00000000
trp: 0000000e err: 00000004 ip: 5c65745a cs: 00000023
efl: 00210212 usp: ffb38260 ss: 0000002b
[end of stack trace]
[7220:7252:0419/072357.571226:ERROR:zygote_host_impl_linux.cc(263)] Failed to adjust OOM score of renderer with pid 10200: Permission denied (13)
Thanks for all your work on Chromium and your other packages. Here is a log file of my error when running Chromium 90.0.4430.72 on a up to date install of Slackware 14.2 x86. See link, hope it helps.
Pingback: Links 19/4/2021: LibreSSL 3.3.2, OpenSSH 8.6, Firefox 88 | Techrights
Thanks for all your work on Chromium and your other packages. Here is a log file of my error when running chromium-ungoogled 90.0.4430.72 on a up to date install of Slackware 14.2 x86. See link, hope it helps.
The 32-bit Chromium 90 (regular and ungoogled versions) run fine if you add the commandline parameter “–disable-seccomp-filter-sandbox” which means it is again a 32bit incompatibility; several others I had already fixed with patches to Chromium 89 but this one is new enough that I can not find a proper recent reference online.
I noticed it has been almost a year since the last calibre update. Have you stopped using calibre? Or do you think Calibre’s provided binary works well enough with Slackware?
I still use Calibre, but I stuck with Calibre 4.15. I lack the time to look into the new requirements that are part of the switch to Python3 and incorporate those into the calibre.SlackBuild
In my experience, calibre’s own script for installing and upgrading binaries works fine on Slackware. But of course one loses the convenient handling that comes with a proper slackware package.
Thanks for your reply. I asked because if your Kindle got a recent firmware update, then all versions prior to Calibre 4.17 (I think) likely lost the cover art thumbnails for side-loaded books.
I have been using the Calibre single directory install, and just install Calibre in my home directory.
Thank you very much for keep providing update for Slackware packages.
My question might not be related to your post, so please pardon me. But, I was checking your new package repositories and I believe is pretty different from the previous one. May I know what tools that you’re used to hosting all the Slackware packages file? I was planning to do something like yours but lost on how to do that. Will really appreciate it if you write a post about how you set up your repositories package website or if there is already an existing one, please kindly share the URL so I could read it.
My package repositories are unchanged for many many years. What difference are you referring to?
The script that I use to generate the repository metadata is http://slackware.com/~alien/tools/gen_repos_files.sh
But perhaps you are referring to the visual aspect of my web sites? I changed the layout a bit for index pages of my web server, that’s correct. It’s a modification of Apache’s httpd-autoindex.conf file. I may document this if I have time. It’s fairly trivial.
Yes, I’m referring to the web sites visual aspect.
I was planning to create something similar to yours, but don’t have an idea where to start. If there is a chance for you to document it I will really appreciate it. But, of course only if you have free time, your well being is far more important of course 🙂
I noticed that you are rather “silent” lately.
I hope you and yours are still well.
I am close to a burn-out and don’t do much more but work during the day (double job, single pay until August), tend to my ill mother and sleep long hours. I don’t seem to recover but at least I have had my first Pfizer shot last week.
Thanks for caring Dick.
We bisected this at Vivaldi. The first commit where it goes wrong is 342591b64f6b81d84ed1a0e4b1c56309e1a5ed41 which updates third_party/libc++. We also realised that Debian Chromium is unaffected. Interestingly they use the GN override use_custom_libcxx=false
“syscall 0422” errors for me without “–disable-seccomp-filter-sandbox”
I know about Vivaldi. That is why we were looking at these issues.
Run Chromium 90 on Debian stable and it launches and works. I still have a Debian 10 and Sid installs in VMs, from when I last tested this.
Hmm. I need to use “use_custom_libcxx=true” or else Chromium will not compile on Slackware 14.2. I should check why this is not a problem for Debian.
At least many thanks for finding the commit that caused this regression.
I report that your
package runs on 32bit slackware-14.2 just fine. There are several small drawbacks that I’ve noticed, but they are negligible, namely:
– videos on ‘https://expres.cz/’ show just a black screen during playback, but audio works (this has probably something to do with mesa r300 drivers bugs for the radeon RV380 chips – I use old ‘Radeon X550 ADVANTAGE’ PCIe card as a compromise solution to have few SVGAlib apps working). It also means that the ‘Adjust Video Brightness’ extension I’ve installed does not work well: when I attempt to regulate any params such as brightness/contrast/etc., any video just goes & stays black. Other than that, Youtube, FB and other videos seem to work fine.
– when I attempt to save any file (using f.e. ‘Save link as’), I dont see the icons, as well as the icon in the ‘Create folder’ square in the top right corner
– on the console where I start the chromium, among other things, I spotted occasional ‘r300_fragprog_emit.c::emit_alu(): Too many ALU instructions’, which is again probably the mismatch between how the chromium GL drivers expect to work with the r300 driver, and its confined capabilities with respect to the HW
I just might add – please keep the 32bit releases of chromium rolling, it means a world to me. I dont like closed source chrome blob too (used to build Firefox myself), and plan to stay with 32bit arch for the forseeable future (deployment of slackware on various embedded PCs and the need for having the same base OS everywhere for maintenance purposes).
Do you have to use “–disable-seccomp-filter-sandbox” argument to make it work? I don’t run 32bit Slackware on real hardware so I test in Virtual Machines where that parameter is needed to make Chromium start at all.
If I attempt to start chromium as root without any parameters, it (by default) refuses to with complaint:
[15610:15610:0812/200526.920628:ERROR:zygote_host_impl_linux.cc(90)] Running as root without –no-sandbox is not supported. See https://crbug.com/638180.
Adding ‘–disable-seccomp-filter-sandbox’ has no effect in this case. The chromium will start (and run fine) only if I throw in ‘–no-sandbox’.
If I try to run chromium as an unprivileged user, without any parameters, then it starts, shows the window for about a second, and then crashes with quite long debug log (can provide if you want me to). In this case, if I throw in either ‘–no-sandbox’ or ‘–disable-seccomp-filter-sandbox’, it starts and runs fine, just with a warning about hampered security (that message appears also if I run it as root).
That is indeed still the behaviour I see in my Virtual Machine.
The ‘–no-sandbox’ reduces the security of your browser to a greater degree than by using ‘–disable-seccomp-filter-sandbox’ which disables less of the sandboxing functionality and leaves some of it intact.
I might just add that adding the unprivileged user to group ‘video’, as well as creating a symlink from /etc/machine-id to /var/lib/dbus/machine-id solves two top issues reported in the debug log (I really dont like an idea to present a unique machine id to google, so I live without that symlink in the end), but the problem with ‘Received signal 11 SEGV_MAPERR 000000000000’ when no ‘–disable-seccomp-filter-sandbox’ used, persists…
FYI, adding the unpriv. user to group ‘video’ makes ‘chrome’ start, but with complaint:
Something went wrong while displaying this webpage.
Error code: 11
and the debug log in the terminal rolls and rolls… (while I’m unable to open any page).
That being said, I’ve noticed https://crbug.com/1204012 – did you try to compile the 32bit version with the commit that vivaldi guys report reverted? I’d be eager to test for you.
I’m curious. I remember you saying a few years ago that Chromium was taking 24 hours to build. Is it getting worse or better nowadays?
In a sense it got worse. That statement was from before I had to compile a custom llvm before compiling chromium (yes that happens every time as part of chromium.SlackBuild). It was the only way to be able to provide a Slackware 14.2 package.
A few years back I upgraded my build server so that the average compile time was reduced with roughly a factor 10.
Considering that a Chromium build today costs roughly 10 hours, that would translate to 100 hours per chromium package on that hardware I used until a few years ago…
Gosh, that’s mad! I wonder if CPUs are going to evolve faster than browsers take to build. In other words, do you think in 5 years Chromium will take less or more time to build on machines of 5 years in the future?
Hope you are keeping well……..
Just a “heads up” to let you know that the 32-bit version of chromium-96.0.4664.45 as built by Void Linux does not seem to have the seccomp problems…….
Download: https://alpha.de.repo.voidlinux.org/current/chromium-96.0.4664.45_1.i686.xbps (actually tar.zst archive)
It does have a nag about Chrome api’s but this can be suppressed with the -test-type switch.
It is accepted as “secure” by Google services.
Just for your interest.
The Void Linux chromium patches are on github:
Well PeeBee, I know about Void Chromium which supposedly does not crash, but I do not run Void (and that will stay that way) so I can not verify that claim myself.
I looked at their git repository a while ago when I read this info in a Chromium bug report, but I don’t understand how Void packages are built. I see a ‘template’ and a great many patches. None of these patches are mentioned in that template file.
If you need a non-crashing Slackware 32-bit package, I politely request that you do your part of the legwork. I do not have the time for a wild goose chase at this point unfortunately, even though I would like to see this fixed too.
Note that Void compiles Chromium quite differently than I do, from what I see in that ‘template’ file. I need to do all kinds of tweaks to make it compile on Slackware 14.2 and it looks like Void are not affected by old libraries. So perhaps it is not even the patches that make the difference.