Vivaldi not starting anymore after huge tumbleweed update

English Applications
#1

This the messages I have from vivaldi. I just cut some messages that were repeating many times.

bt@linux-0rk5:~> vivaldi
[31229:31243:0923/212837.951903:ERROR:service_manager_context.cc(277)] Attempting to run unsupported native service:
bt@linux-0rk5:~> [31303:31319:0923/212839.464503:ERROR:service_manager_context.cc(277)] Attempting to run unsupported native service: /usr/lib64/vivaldi/chrome_renderer.service
[31629:31629:0923/212845.736350:ERROR:sandbox_linux.cc(379)] InitializeSandbox() called with multiple threads in process gpu-process.

I’m on Tumbleweed (updated today 2021-09-23)

**Kernel:** 5.14.5-1-default x86_64 **bits:** 64 
**Desktop:** KDE Plasma 5.22.5  
**Distro:** openSUSE Tumbleweed 20210921

My version of vivaldi is from :

Dépôt                     : packman
Nom                       : vivaldi
Version                   : 2.1.1337.51-1.2
Architecture              : x86_64

Any suggestions ?

Regards,
BT

#2

Opera also has page crashes but Brave works well.

#3

Use Vivaldi from Vivaldi’s repo: https://help.vivaldi.com/desktop/install-update/manual-setup-vivaldi-linux-repositories/

Packman version is outdated - 2.1 vs. 4.2.

#4

Not sure if it is relevant but also the Portable Linux 64-bit of ungoogled-chromium does not longer work. Same executable as before so some OS change must have caused this.

The problem for ungoogled-chromium is that the GUI comes up but it immediately comes with “Aw, Snap!” something went wrong displaying this webpage, Error code: 159. Also the extensions crash.

What works for me is running without sandbox:

$ ungoogled-chromium_91.0.4472.77-1.1_linux/chrome --no-sandbox

So my take is something changed in the sandboxing. Can you try also vivaldi/opera with --no-sandbox?

When starting I see also:

8357:18357:0926/091640.469095:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.

But I saw that before when things were still working and I see it also running with --no-sandbox so I do think it is not the root cause although it could be related.

#5

glibc was updated and it apparently broke quite a lot of binary applications. Applications need to be fixed and recompiled with new glibc. I do not know if it is possible to create binary that works with both old and new versions.

#6

I see the standard chromium from repo-oss is working and I see it has been last changed 5 days ago so that could indeed well be the issue. Bit weird that with --no-sandbox things are working though.

#7

Yes, it’s a crash, journalctl -b shows:

Sep 26 12:17:29 linux-d7n9 systemd-coredump[7259]: ] **Process 7257 (chrome) of user 1000 dumped core.**
                               **Found module .../ungoogled-chromium_91.0.4472.77-1.1_linux/chrome with build-id: a6ca6f4b0faf350d5d6f233161eda396beb1d144**
                               **Found module .../ungoogled-chromium_91.0.4472.77-1.1_linux/libminigbm.so with build-id: a7bd1debb9a897a8a4a4d6b6e3eab3cfdf9a236b**
                               **Found module linux-vdso.so.1 with build-id: c2766a83ee37eab9aaed82319445e3f4a9120444**
                               **Found module libbrotlicommon.so.1 with build-id: 6686aa325d4afdb805e780ca00c6c1ee8355c0ec**
                               **Found module libgpg-error.so.0 with build-id: 4db4852a0ac95da57005de7e92fb7f99eccca826**
                               **Found module libcrypto.so.1.1 with build-id: 8df7bfdbc7d685a910cccf1ec6cef8a703bf1cec**
                               **Found module libresolv.so.2 with build-id: c8f67a9200f45a73ba4062698aa2357dab13c520**
...

Strange I did not see anything like that on the console but that is likely because it is running in a sandbox…

#8

LD_PRELOAD or LD_LIBRARY_PATH may help with it.
I was needed it to run new software with old glibc.

#9

Can you please share some more details on how to run software with the old glibc on Tumbleweed.
As far as I know only one version of glibc is installed…

#10

Download package(s) with older glibc into some folder. Uncompress files from package into folder with Ark, J7Z or other tool.
Use commands that I mentioned previously to override default system settings and use needed libraries instead of system ones.

To use Blender benchmark on Leap 15.2 or older I needed:

LD_PRELOAD=/path1/glibc-2.31-6.1.x86_64/lib64/libm.so.6 /path2/Blender/benchmark-launcher

Otherwise I got message:

… /lib64/libm.so.6: version `GLIBC_2.27’ not found …

I tried to install glibc 2.27 on Leap 15.2, but failed with that.

Glibc creators prefer to break compatibility. It is possible to achieve smooth upgrade, but it needs more efforts from developers.

#11

The issue is your app used clone3() call and it is not supported in the sandbox.

From the OpenSUSE Factory mailing list:

The problem is more: too many people did not take it serious enough that
glibc will use clone3() in the future. Some projects were sitting for
about 6 month on fixes but did not include them or release fixed packages…

The main problem is, that most projects using seccomp for sandboxing don’t
really think about the future, but only the past. So they look at what
is currently in use and forbid everything else with “ENOPERM”. And are
surprised if suddenly new syscalls are added and their code breaks
applications.
It would always be better to block unknown syscalls with “ENOSYS”, so
letting the application think the new syscall still does not exist. This
gives the application (or in this case better glibc) the chance to use the
old code as fallback.

As long as the sandbox developers don’t make their code future proof, we
will have this problem again and again with every new syscall.

#12

Thank you so much! I installed the more recent version and it works without any problem.
Next time I’ll check that the packman version is not outdated.

Regards,
BT :slight_smile: