onionshare-gui does not start in VirtualBox (with VBoxVGA and 3D acceration enabled)
Name of the affected software
Exact steps to reproduce the error
Type onionshare-gui + ENTER
Actual result and description of the error
Traceback (most recent call last):
File “/usr/bin/onionshare-gui”, line 21, in
File “/usr/lib/python3/dist-packages/onionshare_gui/init.py”, line 20, in
from .onionshare_gui import *
File “/usr/lib/python3/dist-packages/onionshare_gui/onionshare_gui.py”, line 22, in
from PyQt5 import QtCore, QtWidgets, QtGui
ImportError: libGL.so.1: failed to map segment from shared object
Show OnionShare window.
Works with VBoxSVGA and VMSVGA when 3D acceration is enabled but for some reason not VBoxVGA.
Tested with tails-amd64-3.12.iso in VirtualBox 6.0.
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#2 Updated by scootergrisen 2019-02-03 22:12:30
OnionShare in the application menu runs onionshare-gui.
The .desktop file says:
If i select OnionShare in the application menu i see this with “sudo dmesg”:
> [ 879.075447] audit: type=1400 audit(1549231684.431:39): apparmor=“DENIED” operation=“file_mmap” profile=“/usr/bin/onionshare-gui” name=“/usr/lib/VBoxOGL.so” pid=11415 comm=“onionshare-gui” requested_mask=“m” denied_mask=“m” fsuid=1000 ouid=0
#5 Updated by intrigeri 2019-02-05 11:59:07
- Subject changed from onionshare-gui dont want to start in VirtualBox (with VBoxVGA and 3D acceration enabled) to onionshare-gui does not start in VirtualBox (with VBoxVGA and 3D acceration enabled)
- Status changed from New to Confirmed
- Assignee changed from scootergrisen to intrigeri
- Target version set to Tails_3.13
This seems to be a bug in the AppArmor profile we ship. It seems it’s been upstreamed but is not shipped in the Debian package yet (see
Feature #11929#note-15) so let’s fix it on our side for now. I’ll check if the problem is in an abstraction.
#11 Updated by intrigeri 2019-02-24 17:12:10
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
Asked on https://gitlab.com/apparmor/apparmor/merge_requests/345 why the policy is the way it is.
#15 Updated by intrigeri 2019-03-24 06:18:41
- % Done changed from 10 to 20
It seems that consensus was reached upstream. I’d rather resolve the conflicts of the proposed fix with our
config/chroot_local-patches/apparmor-aliases.diff only once, so my plan is:
- get this merged upstream
- apply the fix in Debian, batch this with other bugfixes and get this unblocked for migration to Debian testing; I’ll try to do this at the BSP at the end of March
- once it’s in Debian testing, feature/buster will FTBFS and I’ll have to resolve the merge conflict
#16 Updated by CyrilBrulebois 2019-04-02 10:49:49
I think I now understand what the current (in
feature/buster) patch does, but I’m not sure how to forward these changes with the new apparmor code (as of 2.13.2-10).
I’d be happy to get from you an updated hunk for the
#17 Updated by intrigeri 2019-04-02 12:56:06
> I’d be happy to get from you an updated hunk for the
I’ve done one of the possible conflict resolutions and will push once I confirm it at least fixes the FTBFS. Then our test suite should tell us if my conflict resolution breaks stuff.
#20 Updated by intrigeri 2019-04-03 13:28:39
- Status changed from In Progress to Resolved
- Assignee deleted (
- % Done changed from 20 to 100
- QA Check changed from Ready for QA to Pass
What this ticket was about has been fixed on feature/buster. Please file a new, dedicated ticket if I got the merge conflict resolution wrong :)