I had to upgrade my OS to Ubuntu 24.04 LTS. Unfortunately, Luban 4.13 (which had been working well under 22.04 LTS) crashes with a memory error.
I then installed the Luban (edit:) 4.15 version - same result.
All my other 3rd party applications run nicely.
My initial guess is a problem of Luban with the GPU driver.
Hardware is Lenovo Thinkpad P17 with NVIDIA RTX A5000 Laptop GPU
Has anybody else experienced such a thing?
Is there any solution known?
Regards
pah
TK4132
January 15, 2025, 9:44pm
2
Luban 4.15 was just released. Are you experiencing the same issues with that version?
Sorry, I had the wrong version number in my original post: Yes, the problem persists after upgrading from 4.13 to 4.15.
My only clue so far is the following message in the system log:
[ 1587.666278] traps: snapmaker-luban[6353] trap int3 ip:5c5ae9ef7763 sp:7ffdd60b8a20 error:0 in snapmaker-luban[5c5ae70a1000+6878000]
Regards
pah
OK, after doing some search a clear message:
Ubuntu 24.04 LTS requires a proper AppArmor profile for any application running on top of chromium/electron. Details for another application where this happened are given here:
opened 02:04PM - 05 Jun 24 UTC
GNU/Linux
## Description
An AppArmor profile is required for chromium (and therefore elec… tron) based applications to start up on Ubuntu 24.04 in its default configuration.
## Current behavior
Without the presence of an apparmor profile, jitsi-meet crashes on startup with the following output:
```
$ jitsi-meet
LaunchProcess: failed to execvp:
/opt/Jitsi
[1050993:0605/154157.982275:FATAL:zygote_host_impl_linux.cc(201)] Check failed: . : Invalid argument (22)
Trace/breakpoint trap (core dumped)
```
Unsurprisingly, the core dump doesn't give much useful information at all:
```
# coredumpctl info 1039661
PID: 1039661 (jitsi-meet)
UID: 1000 (koniiiik)
GID: 1000 (koniiiik)
Signal: 5 (TRAP)
Timestamp: Wed 2024-06-05 15:05:22 CEST (43min ago)
Command Line: $'/opt/Jitsi Meet/jitsi-meet'
Executable: /opt/Jitsi Meet/jitsi-meet
Control Group: /user.slice/user-1000.slice/user@1000.service/tmux-spawn-a8945128-a26f-4fa6-a931-4d6d4b176eca.scope
Unit: user@1000.service
User Unit: tmux-spawn-a8945128-a26f-4fa6-a931-4d6d4b176eca.scope
Slice: user-1000.slice
Owner UID: 1000 (koniiiik)
Boot ID: d7d6bc23fc4444ed867a6ac6b95c9f31
Machine ID: f119a149e96043a0a8d0bb71b3e08050
Hostname: parahippus
Storage: /var/lib/systemd/coredump/core.jitsi-meet.1000.d7d6bc23fc4444ed867a6ac6b95c9f31.1039661.1717592722000000.zst (present)
Size on Disk: 1.6M
Message: Process 1039661 (jitsi-meet) of user 1000 dumped core.
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.amd64
Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.amd64
Stack trace of thread 1039661:
#0 0x000056bf74d5c04a n/a (jitsi-meet + 0x5ce004a)
#1 0x000056bf74d5b832 n/a (jitsi-meet + 0x5cdf832)
#2 0x000056bf74d5b2dd n/a (jitsi-meet + 0x5cdf2dd)
#3 0x000056bf74d5c2f0 n/a (jitsi-meet + 0x5ce02f0)
#4 0x000056bf74d453d3 n/a (jitsi-meet + 0x5cc93d3)
#5 0x000056bf7442f4e1 n/a (jitsi-meet + 0x53b34e1)
#6 0x000056bf717ec749 n/a (jitsi-meet + 0x2770749)
#7 0x000056bf738b2d96 n/a (jitsi-meet + 0x4836d96)
#8 0x000056bf7284f83b n/a (jitsi-meet + 0x37d383b)
#9 0x000056bf717eb79d n/a (jitsi-meet + 0x276f79d)
#10 0x000056bf717e94d3 n/a (jitsi-meet + 0x276d4d3)
#11 0x000056bf717e9980 n/a (jitsi-meet + 0x276d980)
#12 0x000056bf714cf928 n/a (jitsi-meet + 0x2453928)
#13 0x00007c049562a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#14 0x00007c049562a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#15 0x000056bf710c402a _start (jitsi-meet + 0x204802a)
Stack trace of thread 1039662:
#0 0x00007c049571b4cd __GI___poll (libc.so.6 + 0x11b4cd)
#1 0x000056bf7442e0c0 n/a (jitsi-meet + 0x53b20c0)
#2 0x000056bf74dfb505 n/a (jitsi-meet + 0x5d7f505)
#3 0x00007c049569ca94 start_thread (libc.so.6 + 0x9ca94)
#4 0x00007c0495729c3c __clone3 (libc.so.6 + 0x129c3c)
ELF object binary architecture: AMD x86-64
```
The syslog contains a hint about this being related to apparmor:
```
Jun 05 15:05:22 parahippus kernel: audit: type=1400 audit(1717592722.495:328): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=1039661 comm="jitsi-meet" requested="userns_create" target="unprivileged_userns"
Jun 05 15:05:22 parahippus kernel: audit: type=1400 audit(1717592722.496:329): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=1039663 comm="jitsi-meet" capability=21 capname="sys_admin"
Jun 05 15:05:22 parahippus kernel: traps: jitsi-meet[1039661] trap int3 ip:56bf74d5c04a sp:7fffd038f590 error:0 in jitsi-meet[56bf710c4000+837d000]
Jun 05 15:05:22 parahippus systemd[1]: Started systemd-coredump@5-1039666-0.service - Process Core Dump (PID 1039666/UID 0).
Jun 05 15:05:22 parahippus systemd[1]: systemd-coredump@5-1039666-0.service: Deactivated successfully.
Jun 05 15:05:22 parahippus systemd[1]: systemd-coredump@5-1039666-0.service: Triggering OnSuccess= dependencies.
Jun 05 15:05:22 parahippus systemd[1]: Starting apport-coredump-hook@5-1039666-0.service...
Jun 05 15:05:25 parahippus systemd[1]: apport-coredump-hook@5-1039666-0.service: Deactivated successfully.
Jun 05 15:05:25 parahippus systemd[1]: Finished apport-coredump-hook@5-1039666-0.service.
Jun 05 15:05:25 parahippus systemd[1]: apport-coredump-hook@5-1039666-0.service: Consumed 2.117s CPU time.
```
For some reason, the `DENIED` message only shows up the first time on a given boot, but otherwise, the behavior is the same.
## Expected Behavior
It should just start up.
## Possible Solution
Adding a standard chromium boilerplate apparmor profile to `/etc/apparmor.d/jitsi-meet`, such as the following one, and loading it into the kernel (for example with `systemctl reload apparmor`) makes jitsi-meet start up fine:
```
abi <abi/4.0>,
include <tunables/global>
profile jitsi-meet /opt/Jitsi\ Meet/jitsi-meet flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/jitsi-meet>
}
```
## Steps to reproduce
Install the 2024.5.0 version of jitsi-meet-amd64.deb on Ubuntu 24.04 with its default AppArmor configuration.
I was able to start Luban with the option --no-sandbox
However, this workaround is clumsy. Snapmaker should provide the proper AppArmor profile as part of the distribution, if they are making use of chromium/electron.
Regards
pah
spucky
January 20, 2025, 6:11am
5
This AppArmor thing is one of the reasons, why i am not using Ubuntu or any of it’s flavors.
My devices are running with either Debian or Manjaro (Arch Linux) and i do not have issues get Luban running.
You are free to select your Linux flavor.
But please refrain from handing out such unqualified advice on well-documented security features.