Bug 966695 - virt-manager can not start guest because can not load libGL.so.1
virt-manager can not start guest because can not load libGL.so.1
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
: Reopened
: 1029328 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-23 13:17 EDT by Sergei LITVINENKO
Modified: 2016-01-18 14:29 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-02 15:47:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergei LITVINENKO 2013-05-23 13:17:47 EDT
Description of problem:

process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied


Version-Release number of selected component (if applicable):
virt-manager-0.10.0-0.4.gitb68faac8.fc18.noarch


How reproducible:
100%

Steps to Reproduce:
1. Start manager
2. Choice existing virtual machive (fedora18)
3. Try to run it

Actual results:

process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 123, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1174, in startup
    self._backend.create()
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 692, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: внутренняя ошибка process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied




Expected results:

Start guest


Additional info:

[sergeil@homedesk ~]$ rpm -qa | grep -E "(kernel|qemu|virt-)"
libvirt-glib-0.1.5-1.fc18.i686
kernel-PAE-3.9.2-200.fc18.i686
abrt-addon-kerneloops-2.1.2-2.fc18.i686
qemu-common-1.5.0-1.fc18.i686
libvirt-daemon-driver-nodedev-1.0.5.1-1.fc18.i686
qemu-user-1.5.0-1.fc18.i686
libvirt-daemon-driver-secret-1.0.5.1-1.fc18.i686
virt-install-0.10.0-0.4.gitb68faac8.fc18.noarch
kernel-headers-3.9.2-200.fc18.i686
libvirt-python-1.0.5.1-1.fc18.i686
libvirt-daemon-driver-interface-1.0.5.1-1.fc18.i686
kernel-PAE-devel-3.8.9-200.fc18.i686
libvirt-client-1.0.5.1-1.fc18.i686
libvirt-daemon-driver-storage-1.0.5.1-1.fc18.i686
kernel-PAE-devel-3.9.2-200.fc18.i686
libreport-plugin-kerneloops-2.1.2-2.fc18.i686
virt-manager-0.10.0-0.4.gitb68faac8.fc18.noarch
kernel-doc-3.9.2-200.fc18.noarch
kernel-PAE-3.8.11-200.fc18.i686
ipxe-roms-qemu-20130517-2.gitc4bce43.fc18.noarch
libvirt-daemon-driver-network-1.0.5.1-1.fc18.i686
libvirt-daemon-driver-nwfilter-1.0.5.1-1.fc18.i686
qemu-img-1.5.0-1.fc18.i686
libvirt-daemon-driver-qemu-1.0.5.1-1.fc18.i686
kernel-PAE-devel-3.8.11-200.fc18.i686
virt-manager-common-0.10.0-0.4.gitb68faac8.fc18.noarch
libvirt-daemon-1.0.5.1-1.fc18.i686
kernel-PAE-3.8.9-200.fc18.i686
qemu-system-x86-1.5.0-1.fc18.i686

[sergeil@homedesk ~]$ uname -r
3.9.2-200.fc18.i686.PAE
Comment 1 Cole Robinson 2013-06-12 15:36:30 EDT
Haven't heard any more noise about this so I assume it was some transient error. Please reopen if you can still reproduce.
Comment 2 Richard Michael 2013-11-19 12:25:11 EST
I have this problem when creating a new guest in Fedora 20 beta.

I have one user account (which is an administrator, as specified during F20 install) on this machine (the F20 host) and am logged in and running virt-manager using that account.  (I mention this because of recent changes in Fedora which discourage logging in as root -- is it even possible?)

Running virt-manager as my user, I'm prompted for the root password at virt-manager start as per default system policy.

SELinux is enabled.

After the final step of creating a virtual machine, virt-manager reports this error:

Unable to complete install: 'internal error: process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied
'

Details:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 389, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 454, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2897, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied
Comment 3 Daniel Berrange 2013-11-19 12:29:20 EST
Please provide the guest XML configuration for your guest. Also check if there are any AVCs from SELinux in /var/log/audit/audit.log, and check if it succeeds when SELinux is switched to permissive mode.
Comment 4 Cole Robinson 2013-11-19 12:57:42 EST
rmichael, are you using nvidia proprietary drivers?
Comment 5 Richard Michael 2013-11-19 13:15:45 EST
Indeed, it succeeds when SElinux is disabled.

In /var/log/audit/audit.log, there is one AVC.  I didn't verify the timestamp, but the 'execmem' is suspicious.

type=AVC msg=audit(1384880682.254:547): avc:  denied  { execmem } for  pid=2915 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c328,c388 tcontext=system_u:system_r:svirt_t:s0:c328,c388 tclass=process


Cole Robinson, Yes, I am using proprietary drivers installed via rpmfusion.

xorg-x11-drv-nvidia-304xx-libs-304.108-1.fc20.x86_64
kmod-nvidia-304xx-3.11.8-300.fc20.x86_64-304.108-4.fc20.x86_64
akmod-nvidia-304xx-304.108-4.fc20.x86_64
xorg-x11-drv-nvidia-304xx-304.108-1.fc20.x86_64

Could there be an SElinux issue with the files installed by those packages?

(Apologies, I am not particularly experienced with SElinux configuration.)
Comment 6 Daniel Berrange 2013-11-19 13:35:59 EST
(In reply to Richard Michael from comment #5)
> Indeed, it succeeds when SElinux is disabled.
> 
> In /var/log/audit/audit.log, there is one AVC.  I didn't verify the
> timestamp, but the 'execmem' is suspicious.
> 
> type=AVC msg=audit(1384880682.254:547): avc:  denied  { execmem } for 
> pid=2915 comm="qemu-system-x86"
> scontext=system_u:system_r:svirt_t:s0:c328,c388
> tcontext=system_u:system_r:svirt_t:s0:c328,c388 tclass=process

Ah ha. That explains the previously bizarre report we had of QEMU needing execmem in bug 1029328

> Cole Robinson, Yes, I am using proprietary drivers installed via rpmfusion.
> 
> xorg-x11-drv-nvidia-304xx-libs-304.108-1.fc20.x86_64
> kmod-nvidia-304xx-3.11.8-300.fc20.x86_64-304.108-4.fc20.x86_64
> akmod-nvidia-304xx-304.108-4.fc20.x86_64
> xorg-x11-drv-nvidia-304xx-304.108-1.fc20.x86_64
> 
> Could there be an SElinux issue with the files installed by those packages?
> 
> (Apologies, I am not particularly experienced with SElinux configuration.)

We intentionally block 'execmem' since is a very bad thing to allow from a security POV. It is really awful that nvidia's proprietary drivers require this, and I would not want SELinux to allow this.
Comment 7 Richard Michael 2013-11-19 14:02:35 EST
(It's always a fun time with proprietary Nvidia, this has been biting me in various ways for years. This is in fact old hardware, but the Nouveau driver does not yet seem to support it.  I'll never buy another motherboard or Nvida card for linux again.)

On the security issue, understood.

Though, I suppose many people will be affected by this.

At the moment, I simply disabled SELinux, which obviously not ideal.  Can I refine the policy to allow 'execmem' only for 'qemu-system-x86' and with respect to 'libGL.so'?  (Then possibly the nvidia RPMs could incorporate that small refinement and inform the user at install time.)
Comment 8 Cole Robinson 2013-11-19 14:58:13 EST
You should be able to keep selinux enabled, but do:

sudo setsebool -P virt_use_execmem=on

Can you confirm that fixes things?
Comment 9 Richard Michael 2013-11-19 15:52:04 EST
Yes, that works, thanks Cole.

[In fact, I re-enabled SELinux and generated a failure to be sure it was "broken" again and this time the SELinux notification pop-up (at the bottom of the screen) appeared.  Launching the "troubleshooter" revealed setsebool work-around as well.  If I'd seen the notification the first time, I wouldn't have filed here.. I really don't think it popped up, however ; I'm sitting at the console without anything else on the screen.]

Anyway, thanks again and sorry for the time waste.  I'll suggest 'sesetbool' be added to the nvidia RPMs.
Comment 10 Cole Robinson 2013-11-19 15:57:46 EST
I blogged about it here:

http://blog.wikichoon.com/2013/11/qemu-system-x8664-error-while-loading.html

Hopefully that adds some visibility
Comment 11 Cole Robinson 2013-11-19 15:58:45 EST
*** Bug 1029328 has been marked as a duplicate of this bug. ***
Comment 12 Zachary Graham 2013-11-21 00:36:23 EST
(In reply to Richard Michael from comment #7)
> Though, I suppose many people will be affected by this.
> 

Just ran into this problem and found this thread while looking to report... Nevermind.
Comment 13 Colin Hunt 2014-03-06 22:23:49 EST
Just want to add for other people who search about this issue that it is not just the proprietary Nvidia drivers that cause this, I am running the latest AMD proprietary fglrx video driver and get this same error with the same denied { execmem } in audit.log. Using the above metioned setsebool command fixes the issue in this case too though.
Comment 14 Sergei LITVINENKO 2014-03-16 05:32:34 EDT
fedora-20, 3.13.6-200.fc20.x86_64, NVidia proprietary driver

The solution below help

>> sudo setsebool -P virt_use_execmem=on
Comment 15 Matt Domsch 2014-03-23 20:57:25 EDT
I hit this today too.  Thanks for virt_use_execmem, though I wish nouveau wouldn't crash my system repeatedly which is what has forced me into using the nvidia driver instead.
Comment 16 Nicolas Chauvet (kwizart) 2014-08-21 12:42:37 EDT
execmem is caused by several rpath in fedora packages.

for f in *.so.*.* ; do chrpath -d ${f} ; done
That will break pulseaudio that is not able to run anymore.

http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

Here is a list of shared objects available on a virt-manager install
Exept for pulseaudio, others have RPATH on /usr/lib64.

libcogl-pango.so.15.3.0
libdcerpc-atsvc.so.0.0.1
libdcerpc-binding.so.0.0.1
libdcerpc.so.0.0.1
libfbembed.so.2.5
libfbembed.so.2.5.2
libfolks-eds.so.25.16.1
libfolks-telepathy.so.25.16.1
libgdbm_compat.so.4.0.0
libgensec.so.0.0.1
libgnutls-dane.so.0.4.1
libgnutls-xssl.so.0.0.0
libgrlpls-0.2.so.0.0.1
libgstaudio-0.10.so.0.25.0
libgstbase-0.10.so.0.30.0
libgstcdda-0.10.so.0.25.0
libgstriff-0.10.so.0.25.0
libgupnp-dlna-gst-2.0.so.3.0.0
libndr-krb5pac.so.0.0.1
libndr-nbt.so.0.0.1
libndr.so.0.0.2
libndr-standard.so.0.0.1
libpulse-mainloop-glib.so.0.0.5 RPATH=/usr/lib64/pulseaudio (OK)
libpulse-simple.so.0.1.0 RPATH=/usr/lib64/pulseaudio (OK)
libpulse.so.0.17.3 RPATH=/usr/lib64/pulseaudio (OK)
libregistry.so.0.0.1
librygel-renderer-2.0.so.1.0.0
librygel-renderer-gst-2.0.so.1.0.0
librygel-server-2.0.so.1.0.0
libsamba-credentials.so.0.0.1
libsamba-hostconfig.so.0.0.1
libsamba-policy.so.0.0.1
libsamba-util.so.0.0.1
libsamdb.so.0.0.1
libserf-1.so.0.3.0
libsmbclient-raw.so.0.0.1
libsmbclient.so.0.2.1
libtevent-util.so.0.0.1
libwbclient.so.0.11
Comment 17 Nicolas Chauvet (kwizart) 2014-08-22 03:25:10 EDT
Here is a list of sources package currently installed on my system, having rpath set
cogl-1.16.0-2.fc20.src.rpm
firebird-2.5.2.26539.0-8.fc20.src.rpm
folks-0.9.6-2.fc20.src.rpm
gdbm-1.10-7.fc20.src.rpm
gnutls-3.1.25-1.fc20.src.rpm
grilo-0.2.9-2.fc20.src.rpm
gstreamer-0.10.36-6.fc20.src.rpm
gstreamer-plugins-base-0.10.36-6.fc20.src.rpm
gupnp-dlna-0.10.2-2.fc20.src.rpm
libserf-1.3.4-1.fc20.src.rpm
rygel-0.20.3-1.fc20.src.rpm
samba-4.1.9-4.fc20.src.rpm

Given the bug affect this component I would keep it as a tracker for the ones that are actually dependency of virt-manager. (such as cogl)
Comment 18 Cole Robinson 2014-09-02 15:47:51 EDT
Nicolas, I can't really understand what you are getting at... the execmem violation seems to be an issue with using the proprietary nvidia drivers and does not happen when starting VMs on stock f20.

If you are hitting an issue with stock packages, please open a new bug and post the exact error message you are seeing
Comment 19 Nicolas Chauvet (kwizart) 2014-09-02 16:47:58 EDT
(In reply to Cole Robinson from comment #18)
> Nicolas, I can't really understand what you are getting at... the execmem
> violation seems to be an issue with using the proprietary nvidia drivers and
> does not happen when starting VMs on stock f20.
Altought there is nothing to be fixed with this issue in qemu itself (not even in the nvidia package) the problem is seen with qemu because some qemu dependencies are using rpath hence the process load the mesa-libGL from /usr/lib(64) instead of the libGL found by the linker at runtime.

Fixing every rpathes on a given system was enought to make the selinux denial to disappear. (So it wasn't a Selinux issue either).

Given that rpath in standard library path is forbidden in fedora and that some fedora packages are affected (altought remotely for qemu) I think it's fair for users to consider the issue unfixed until every qemu dependencies are fixed. (only fixed cogl so far)
Comment 20 Cole Robinson 2014-09-02 17:05:58 EDT
Why don't we see this with stock fedora then? What is nvidia doing that tickles the rpath issue, yet isn't an issue for nvidia to fix?

(How did you fix the rpath issue for cogl, can you provide a commit link?)
Comment 21 Nicolas Chauvet (kwizart) 2014-09-02 17:14:19 EDT
(In reply to Cole Robinson from comment #20)
> Why don't we see this with stock fedora then? What is nvidia doing that
> tickles the rpath issue, yet isn't an issue for nvidia to fix?
no, this is fedora breaking fedora's rules (no rpath), it's dead easy.
> (How did you fix the rpath issue for cogl, can you provide a commit link?)
git show 487559a84b53d6f8e2d429fd6d4c81957c0a06d9 in cogl's fedora package.
Altought I prefer patching libtool between %configure and make at the %build step

# remove rpath from libtool
sed -i.rpath 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i.rpath 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
Comment 22 Paul DeStefano 2016-01-03 19:49:31 EST
Really?  So, you actually found the bug with patch and still no joy?

Thanks for posting here, Nicolas.  I would have been lost and had no idea it could be fixed.  So, did you just build cogl from srpm (with your fix)?  Doesn't look too hard on the surface.  Any caveats?

Note You need to log in before you can comment on or make changes to this bug.