Element-web: Release and Nightly fail to start on Debian

[uhoreg]

Running Riot nightly on Debian results in Trace/breakpoint trap. This seems to be caused by some sort of issue with the sandbox, as running riot-desktop-nightly --no-sandbox works properly. Alternatively, doing sudo sysctl kernel.unprivileged_userns_clone=1 and then running riot-desktop-nightly works properly.

This looks like it may be https://github.com/electron/electron/issues/21309 Maybe we can try renaming the directory to /opt/Riot-Nightly rather than /opt/Riot Nightly.

[uhoreg]

@dbkr how hard is it to change the path?

[dbkr]

Well, it's trivial to change the app name - unsure about just changing the path, but might be possible to override it separately.

[dbkr]

A cursory look suggests that no, it's hardcoded to be the name of the app :(

[jryans]

For other platforms, it would be unfortunate to use a non-space separator in the app name itself...

Maybe macOS and Windows builds allow customising their app name, even though Linux build don't support it for this directory...?

Why does this only affect Debian...?

[uhoreg]

It only affects Debian because Debian has a kernel patch to, AIUI, improve security and that collides with something electron is trying to do, ironically, to improve security. Ubuntu also has the same security patch, but seems to disable it by default.

[er0k]

I have the same issue on Debian sid, but when I use --no-sandbox riot is an unresponsive white screen

$ riot-desktop-nightly 
Trace/breakpoint trap

$ riot-desktop-nightly --no-sandbox
(node:402913) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Starting auto update with base URL: https://packages.riot.im/nightly/update/
Auto update not supported on this platform
[402962:0628/143730.401957:FATAL:platform_shared_memory_region_posix.cc(254)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

permissions on /dev/shm seem correct:

$ stat -c '%A %a %n' /dev/shm
drwxrwxrwt 1777 /dev/shm

my system info:

$ uname -svmo
Linux #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux

$ apt policy riot-nightly 
riot-nightly:
  Installed: 2020062801
  Candidate: 2020062801
  Version table:
 *** 2020062801 500
        500 https://packages.riot.im/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status

[t3chguy]

This applies to Element (Riot) Desktop too

[rupi-lol]

I can confirm that enabling usernamespaces fixes that.

[jryans]

Today's element-nightly should contain a fix for this issue. (element-desktop is separately affected, but will have a similar fix later today.) Could @uhoreg or someone who can reproduce test element-nightly to verify the fix?

[uhoreg]

Using the latest element-nightly (2020071602), it's still using /opt/Element Nightly, so the issue is still there.

[jryans]

Bluh, I forgot to update the build machine with the fix... 😓 Okay, still hopeful that release (and tomorrow's nightly) will work.

[jryans]

Okay, just tested here, and indeed element-desktop 1.7.1 uses a directory without a space, so I believe that covers release.

[jryans]

I think that's enough evidence that this is believed fixed. Nightly should also be fixed in tomorrow's build.

[uhoreg]

element-desktop 1.7.1 is working fine here :+1:

[kortewegdevries]

Hi, this doesn't seem to be fixed on 1.7.4 on Ubuntu groovy proposed ?

$ element-desktop --no-sandbox
(node:402913) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Starting auto update with base URL: https://packages.riot.im/nightly/update/
Auto update not supported on this platform
[402962:0628/143730.401957:FATAL:platform_shared_memory_region_posix.cc(254)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

[jryans]

@kortewegdevries I suspect it could something unrelated. What directory is element-desktop installed in?

[kortewegdevries]

@kortewegdevries I suspect it could something unrelated. What directory is element-desktop installed in?

Do you mean where the sandbox and executable is? It's in /opt/Element Do you have a way of providing debug logs?

[jryans]

Do you mean where the sandbox and executable is? It's in /opt/Element

Okay, so that's correct as far as this issue. Please start a new issue for your experience, it sounds specific to Ubuntu Groovy perhaps, as 1.7.4 works fine here on Bionic.

Do you have a way of providing debug logs?

Unfortunately not really until the app starts up, but let's discuss further on the new issue.