RPM Packages for Bumblebee

[gsgatlin]

Hello.

I am creating packages for Red Hat type systems. I have a problem on CentOS 6 i686 only. The same package works fine
on i686 and x86_64 fedora 15, 16, and 17 and x86_64 CentOS 6... Its quite odd. My laptop has 8 GB of RAM. It is a lenovo ideapad Y470. The rpms are stored at a yum repository at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/

and

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/

bumblebeed will not stay running. If you reboot and start it by hand it will work for one use. Like:

optirun glxgears

but once you close the glxgears window bumblebeed crashes. It does not do this on a 64 bit OS on the same system.
(E.G. CentOS 6.2 x86_64) On 64 bit everything is working great. I've generated a bumblebee-bugreport-20120512_225151.tar.gz file which I will email.

I have more info which I will add in another section because its very long....

[gsgatlin]

If I run bumblebeed by hand with the --debug flag, I get this output:

http://pastebin.com/kyvGsWii

Notice the part that starts with:
*** stack smashing detected ***

I wonder if I need to use
-fno-stack-protector

on this platform only?

If the red hat "spec file" is useful to help debug this issue I have pasted it to:

http://pastebin.com/0UqAKkG6

Let me know if you need any other info? I don't actually plan on using a 32 bit OS on this box at all but I figured some people might install a 32 bit CentOS 6 for some weird reason.

[Lekensteyn]

Can you compile with `CFLAGS="-g -O0" and paste a new log? Thanks.

[gsgatlin]

Sure. Thanks a lot for looking at this. I pasted the output at:

http://pastebin.com/ZfeSLYps

Looks like its still ending with the same message. *** stack smashing detected ***: /usr/sbin/bumblebeed terminated

[gsgatlin]

Hello. Sorry. I played around with the bumblebee spec file some more. I changed:

make %{?_smp_mflags}
to
make CFLAGS="-g -O0" %{?_smp_mflags}

This seems to have fixed the issue actually. bublebeed no longer seems to be crashing on i686.

http://pastebin.com/mBvJXLQH

So do you think these flags safe to use on all platforms or should this only be changed for centOS 6 i686 systems?

Or maybe there is still some issue that "-g -O0" is hiding? Any ideas appreciated.

[Lekensteyn]

I can't find something that may have caused it, perhaps the compiler is buggy. -O0 disables any optimizations, what about using -O2?

[gsgatlin]

Greetings. I tried:

make %{?_smp_mflags}

which produces a bumblebeed that crashes after one use on i686 centos 6.

make CFLAGS="-g -O2" %{?_smp_mflags}

which works perfectly on i686 centos 6. Quite odd! The Macro %{?_smp_mflags} should default to -j1 I think. It is being built inside a KVM virtual machine with one virtual CPU. Just "make" by itself also crashes after one use.

I believe %{?_smp_mflags} expands to -j[number of CPU's in the system]

I built all of these inside KVM vms because I do not own enough physical hardware to keep around all these systems.

The OS I am building this for is a little bit older because its an "Enterprise OS" so they backport bug fixes and security updates for all the software including gcc. the gcc is version 4.4.6 while in newish fedoras it is newer. Also the kernel is a bit older: gsgatlin@localhost specs]$ uname -a
Linux localhost.localdomain 2.6.32-220.13.1.el6.i686 #1 SMP Tue Apr 17 22:09:08 BST 2012 i686 i686 i386 GNU/Linux

gcc versions in fedora...
fedora 15: 4.6.3
fedora 16: 4.6.3
fedora 17: 4.7.0

In the fedoras I never saw any problems on 32 bit. Just this one OS and arch. Do you think I should add a
conditional in my spec file for stuff older than fedora 15 to use:

make CFLAGS="-g -O2" %{?_smp_mflags}

and then fedora 15 and newer should use:

make %{?_smp_mflags}

Any ideas greatly appreciated.

[Lekensteyn]

Yh, I've looked it up and _smp_flags seems to add a -j flag. I wonder if it's the optimization flag (-Ox) or debugging flag (-g). Since it's likely a compiler issue I suggest you to try different optimization levels (0, 1, 2 or even 3) and see if it helps. If you know assembly a bit, you can also objdump it and diff it.

[gsgatlin]

Hello, Just to follow up, further tests indicate that it doesn't matter which switches are added. Its very strange.

make CFLAGS="-g -O2" %{?_smp_mflags} #works
make CFLAGS="-O2" %{?_smp_mflags} #works
make CFLAGS="-g" %{?_smp_mflags} #works
make CFLAGS="-O3" %{?_smp_mflags} #works
make CFLAGS="-O1" %{?_smp_mflags} #works
make CFLAGS="-O0" %{?_smp_mflags} #works
#make %{?_smp_mflags} #fails
#make #fails

I guess maybe I should add a conditional for this distro and maybe use -O3 ?

[gsgatlin]

Oops. The comments on those last two were a typo. :) They were:

make %{?_smp_mflags} #fails
make #fails

cheers

[Lekensteyn]

I think there is some global CFLAGS var that is being overwritten. Please check the output of configure while compiling using the spec file.

[gsgatlin]

Aha! that makes sense. Well... Quite the line.

CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables'

Let me see if I can narrow down what is actually causing the issue. I'll try one by one to figure it out.

[gsgatlin]

It seems "-fstack-protector" has some effect on this.

make CFLAGS="-fstack-protector" #fails
make CFLAGS="" # works

So perhaps any conditional would need to exclude "-fstack-protector" from the default CFLAGS. But only on
fedoras <=15 and on arch i686 only?

[gsgatlin]

Just for a reference it looks like this spec file:

http://pastebin.com/VimAHTjp

builds with the correct CFLAGS on 32 bit and 64 bit VMs. It takes a few days to properly test however because I
have only one laptop and so I have to re-install with fedoras and RHELs in my spare time at night. So let me know if you think that would be ok or if if there is a bug with bumblebeed and the -fstack-protector CFLAGS that could be fixed?

cheers,

[Lekensteyn]

Probably this bug. I know that there is a place where we use a char array of size 100: https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/switch/sw_bbswitch.c#L40

[gsgatlin]

Thank you for your help with this problem.

I still need to do more tests. But I think I am mostly finished. Here are some URLs to some spec files I made in case I get hit by a car or something before I can write docs and go on IRC and if someone want to pick up where I left off:

bumblebee: http://pastebin.com/wqeZyJ9S
bbswitch: http://pastebin.com/Q8j6xKWn
acpi-handle-hack: http://pastebin.com/zfdK3DPK
acpi-handle-hack-nouveau: http://pastebin.com/Gu2YHJJj
bumblebee-nvidia-32: http://pastebin.com/FJEeT5c1
bumblebee-nvidia-64: http://pastebin.com/qAbF2fJL

I will try to write up some docs and then I'll be in touch on #bumblebee-dev on Freenode. The bumblebee package at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/

and the nvidia drivers at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/

Have been updated. I will work on writing some docs next. I was able to build a pair of VirtualGL rpms on fedora but it was kind of ugly so I need some fedora experts to look at it to see how it could be built with a modern libjpeg-turbo in fedora to make this more acceptable to the community as a submission. (These problems are not there on RHEL 6/ centos 6)

Thanks again.

[amonakov]

Stack smashing looks like a real bug in bumblebee sources fixed now by commit 034f2ec

[gsgatlin]

Updated package at review request here with patch to fix stack smashing:

https://bugzilla.redhat.com/show_bug.cgi?id=827167

Also, documentation has been updated on my docs site with some recent changes:

http://techies.ncsu.edu/wiki/bumblebee

Basically, things are stalled with getting bumblebee into fedora / EPEL due to problems with VirtualGL building in "rawhide" ("rawhide" is what will become fedora 18 when its ready)

See https://bugzilla.redhat.com/show_bug.cgi?id=839060
and
https://bugzilla.redhat.com/show_bug.cgi?id=834127
for more information on that.

Assuming I were to have luck with bumblebee and VirtualGL in fedora / EPEL, I will look at doing a bbswitch and acpi-handle-hack in a third party repository such as "rpmfusion" and "elrepo."

I have not been hanging out in your developer IRC channel since everything is stalled and there is no certainty about getting these packages into fedora. If both packages were to be accepted into fedora and build for all branches at some point then I will start hanging out in there.

Cheers,

[amonakov]

It looks like your package is based on version 3.0.0, but 3.0.1 has been released, which includes some fixes, most importantly a fix for a critical bug affecting users with new Kepler-based laptops. The stack smashing fix is also
included in 3.0.1.

[gsgatlin]

Cool. I'll update that to 3.0.1 then. Thanks for the info.

[gsgatlin]

Ok. Updated to version 3.0.1 at the fedora review request and also at my test repository. I tested it briefly with minecraft and it seems to be working well. Thanks again for the info on the new version.

[gustavokrm]

Hello, I used these rpm packages + the bumblebee-nvidia one and I am facing some problems as we speak.
I cannot get software like Totem or Cheese to work with optirun -- no video. Also, wine also is not working properly. How can I fix this? I'm willing to supply info for you guys, just ask.

[amonakov]

What are you trying to achieve by running video players via optirun? Can you use Intel hardware decoding via libva? Bumblebee does not perform video decoding offloading, only OpenGL offloading.

Wine is a 32-bit program, if you're running it on a 64-bit OS via optirun, you'll need 32-bit VirtualGL.

[gustavokrm]

I was trying to test this, but it didn't work. Also, optirun bit.trip.runner, supertuxkart, whatever doesn't work either. I get no video either way, even if they are native games.
I removed the bumblebee-nvidia package but the error persists. There is no real use for the card then.. =\
I know Wine is 32 bit, but I couldn't figure out how to make it work. It wouldn't work anyway, even with a 32 bit prefix, latest packages and 32 bit VirtualGL ( yes, i double-checked ).
With the Intel card, everything functions as usual, but I cannot run games via wine.

[gsgatlin]

Hello. I am the author of these RPM packages. In the process of getting VirtualGL into fedora and EPEL, I think we/I broke multilib support. So if you have a 64 bit system I think running 32 bit apps is currently broken, both in the package in my repo, and the package in fedora "testing" for f16, f17, and f18. I will see what I can do to fix that. I have used optirun with the 64 bit version of bit.trip.runner so I know it works on at least my laptop... (With Nvidia driver, in bumblebee-nvidia package. I eat my own dog food, but I don't run wine which may be why I missed this.)

I'll reply back to this thread once I have some more info on this. The version on the VirtualGL site may not suffer from this bug, but it does not meet fedora packaging guidelines either. You may want to check that out if you can't wait?

The version currently at my repo will hit fedora in about 3 more days I think...

Cheers,

[gsgatlin]

I didn't remember that correctly. After looking again I get

Fatal error
failed to create SDL window: Couldn't find matching GLX visual

When launching bit.trip.runner via optirun. But that particular game seems to perform fine on the intel card. I have used optirun on some other humble bundle games however. (Cogs was one that improved the most) So I'm pretty sure at least many 64 bit openGL apps work on fedora. May wish to try:

optirun glxgears

just to test the most basic functionality of your bumblebee setup.

[Lekensteyn]

You might be interested in https://github.com/amonakov/primus as well.

[gsgatlin]

Ok, If you are using my fedora/rhel bumblebee repo, do a yum update and that should fix multilib support. The version in fedora will be fixed soon.

If you are having trouble running

optirun glxgears

you may wish to run

/usr/bin/bumblebee-bugreport

to help figure out what is going on with your laptop.

Special thanks to Andy Kwong for the multilib patch.

[gustavokrm]

So, testing this against Fedora 18 beta now.
Installing bumblebee went just fine. When I installed the bumblebee-nvidia package, I experienced a big problem: I couldn't reach the graphic interface. It would start blinking, trying to start gdm, but it couldn't. Removing this package and reinstalling bumblebee solved the problem.

[gsgatlin]

Yeah. I could not get it to work on fedora 18 either. I suspect it is a SELinux issue. I actually use CentOS 6 as my main desktop, not fedora 18 beta. So its working ok for my system. I do have a spare Y470 laptop with f18 beta on it. I will try to look at it tomorrow to see if it might be possible to figure out how to make it work. See also #298 which is preventing me from testing bumblebee with the nouveau driver on my particular laptop make and model.

I know it worked on f17 the last time I tested it. Sorry about that. You might want to try building it by hand with:

/usr/sbin/bumblebee-nvidia --debug

to see if that works better. That was going to be the first thing I try with f18.

[tmsqt]

Hi,
I still have a problem to unload nvidia_uvm, when I run optirun -b primus glxgears the card turns off properly because doesn't use nvidia_uvm.

running...

grep nvidia; cat /proc/acpi/bbswitch

nvidia_modeset        841750  2 
nvidia              13009634  242 nvidia_modeset
i2c_core               40756  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nvidia
0000:01:00.0 ON

exiting...

grep nvidia; cat /proc/acpi/bbswitch

0000:01:00.0 OFF

but if I run a 3D application like maya optirun -b primus maya the card doesn't turn off properly.

running...

grep nvidia; cat /proc/acpi/bbswitch

nvidia_uvm            665601  2 
nvidia_modeset        841750  2 
nvidia              13009634  333 nvidia_modeset,nvidia_uvm
i2c_core               40756  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nvidia
0000:01:00.0 ON

exiting...

grep nvidia; cat /proc/acpi/bbswitch

nvidia_uvm            665601  0 
nvidia              13009634  1 nvidia_uvm
i2c_core               40756  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nvidia
0000:01:00.0 ON

I have to run following commands to properly turn off the card.

sudo modprobe -r nvidia_uvm
sudo tee /proc/acpi/bbswitch <<< OFF

Another problem is when I close the laptop lid(sleep) while I'm runnig optirun the app crashes when the laptop wakes up, do you know how to solve this problems, is the only thing missing to run nvidia smoothly.

System info:

cat /etc/centos-release
CentOS Linux release 7.4.1708 (Core) 

uname -r
3.10.0-693.2.2.el7.x86_64

rpm -qa bumblebee* primus* bbswitch*
primus-1.1.03282015-4.el7.centos.x86_64
bumblebee-3.2.1-13.el7.centos.x86_64
bbswitch-dkms-0.8.0-3.el7.centos.x86_64
bumblebee-nvidia-384.90-1.el7.centos.x86_64

Thanks

[gsgatlin]

@atomicvoxel Does it only do that with maya? or is it any 3d apps? I will try to reproduce this on a test system I have.

I am not sure but I think optirun/primusrun may not be able to work when suspended. Does this work in other distros? Does anyone know?

[tmsqt]

@gsgatlin I've tried other apps, but maya is the only one triggering nviidia_uvm. Do you know any other that might help testing this?

[gsgatlin]

Hmnn. I don't think it is possible with the suspend stuff. I tested "glxgears" with primusrun on fedora 26, centos 7, and ubuntu 16.04 LTS. (using bumblebee from https://launchpad.net/~bumblebee/+archive/ubuntu/testing ppa with nvidia-375 drivers)

In all cases, glxgears will crash into a white screen when suspending a laptop and then resuming. I think you will need to quit out of any applications running on the nvidia card before closing laptop lid. It is regrettable but I see the same behavior across multiple linux distros so its a bumblebee thing not a CentOS or fedora issue with the rpm.

How did you install maya? I get

[root@t540p ~]# dnf install maya
Last metadata expiration check: 1:10:49 ago on Fri 13 Oct 2017 02:05:57 PM EDT.
No match for argument: maya
Error: Unable to find a match

on fedora 26 and

[root@localhost ~]# yum install maya
Loaded plugins: fastestmirror
base | 3.6 kB 00:00
bumblebee | 2.9 kB 00:00
epel/x86_64/metalink | 18 kB 00:00
epel | 4.3 kB 00:00
extras | 3.4 kB 00:00
openafs | 2.9 kB 00:00
updates | 3.4 kB 00:00
(1/3): epel/x86_64/updateinfo | 837 kB 00:00
(2/3): epel/x86_64/primary_db | 4.8 MB 00:00
(3/3): updates/7/x86_64/primary_db | 2.7 MB 00:01
Loading mirror speeds from cached hostfile

• base: mirror.net.cen.ct.gov
• epel: download-ib01.fedoraproject.org
• extras: mirror.net.cen.ct.gov
• updates: www.gtlib.gatech.edu
  No package maya available.

on centos 7.

Is there a yum repo for that? Thanks.

[mhirsch]

Is there a yum repo for that?

lollll

He's probably running this in Wine or something.
https://www.autodesk.com/products/maya/overview

BTW nvidia_uvm is triggered when you load a CUDA kernel. I wouldn't expect most graphics apps to do that. However, back when I was playing with CUDA a bunch I put something like this

remove nvidia rmmod nvidia-uvm nvidia

in /etc/modprobe.d/nvidia-unload.conf

That will only work if you manually modprobe -r nvidia though. I definitely experienced the same thing though, that you can't suspend the computer with the nvidia module loaded.

[gsgatlin]

@mhirsch OIC. Thanks. Yeah. not gonna try to reproduce if its not easily available or not a Linux native app.

[tmsqt]

@gsgatlin Maya is a native app but it's commercial, that's why I was trying to find another one that triggers nvidia_uvm to help testing it.

@mhirsch Thanks for the tip, I will give a try.

[thesourcehim]

Hello, bbswitch has a problem in new Fedora 4.14.15 kernel. It compiles, but system says:
bbswitch: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '

UPDATE: seems to be compiler version mismatch (gcc 7.3 was uses to build kernel, but system has only 7.2.1)

[gsgatlin]

I see user slartibart70 made a bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1539165

So maybe kernel-4.14.15-301.fc27.x86_64 will work?

[thesourcehim]

Hi, vulkan json file nvidia_icd is missing in the current 390.25 installation.

[gsgatlin]

@thesourcehim Do you know if it was in the last version of the driver? Perhaps it could be added in manually in my package.

[thesourcehim]

No, didn't check, sorry. However it is present in xorg-x11-drv-nvidia-libs package, so I assume nvidia installer has it.

[gsgatlin]

Not sure if anyone is still using my packages but the yum repos have been moved to https://linux.itecs.ncsu.edu/redhat/public/ and my documentation at https://www.linux.ncsu.edu/bumblebee/ has been updated to reflect the new urls. The various *-release rpms have been updated in the old repo so users should get pointed to the new repos automatically after a yum/dnf update. The new repos were required because install.linux.ncsu.edu is bit rotting away and the new yum repos use https protocol instead of http.

[mhirsch]

Awesome, thank you! Https is great.

[sudhirkhanger]

@gsgatlin is it possible that bbswitch module is not built properly. When I update the kernel I get systemd-modules-load.service failed error. It gets fixed if I create a new initramfs using dracut. Relevant discussion can be found here.

Thanks.

[gsgatlin]

@sudhirkhanger Ok. I will try to look into this tomorrow or tuesday when I have time. Thanks.

[thesourcehim]

Today I updated bumblebee package to 430.14 (fedora 30 x86_64) and started to get this error when trying to launch any application under optirun:

From Xorg.8.log:
[ 2376.069] (EE)
[ 2376.069] (EE) Backtrace:
[ 2376.106] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x13c) [0x561df7c3775c]
[ 2376.136] (EE) 1: /usr/lib64/libpthread.so.0 (funlockfile+0x50) [0x7f1a6da2debf]
[ 2376.165] (EE) 2: /usr/lib64/libc.so.6 (memcpy+0x23) [0x7f1a6d8f8553]
[ 2376.180] (EE) 3: /usr/lib64/nvidia-bumblebee/libnvidia-glcore.so.430.14 (_nv043glcore+0x27f659) [0x7f1a6c627869]
[ 2376.180] (EE) 4: /usr/lib64/nvidia-bumblebee/libnvidia-glcore.so.430.14 (_nv043glcore+0x27f7bd) [0x7f1a6c627b8d]
[ 2376.189] (EE) 5: /usr/lib64/nvidia-bumblebee/libnvidia-glcore.so.430.14 (_nv015glcore+0x49ad8) [0x7f1a6c0db418]
[ 2376.190] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 2376.190] (EE) 6: /usr/lib64/nvidia-bumblebee/xorg/modules/extensions/libglxserver_nvidia.so (?+0x0) [0x7f1a6a200d32]
[ 2376.190] (EE)
[ 2376.190] (EE) Segmentation fault at address 0x7f1a6a2fa000
[ 2376.190] (EE)
Fatal server error:
[ 2376.190] (EE) Caught signal 11 (Segmentation fault). Server aborting

[gsgatlin]

Sorry. I thought I tested this and I did not it seems. I suggest you downgrade and I will try to remove it.

[gsgatlin]

@thesourcehim Removed broken package from yum repo.

I am working on a new one that will use epoch to install the older driver.

I opened a topic here:

https://devtalk.nvidia.com/default/topic/1052453/linux/xorg-segfalt-started-with-430-14-optimus/

so hopefully a new version will either fix it or someone might have a patch or something.

[thesourcehim]

I downgraded using dnf distrosync command, everything works fine now, thank you.

[thesourcehim]

Ahh, and guess what, 418.56 is not compatible with kernel 5.1. Of course.

[gsgatlin]

Yeah. Looks like maybe bumblebee is done. I'm sure this will affect all the distros soon.

https://devtalk.nvidia.com/default/topic/1050786/linux/nvidia-drivers-430-09-causes-xorg-segfault-at-start-/1

It is most regrettable nvidia has decided to do this. It might be possible to do:

Building nvidia-drivers with USE="-compat" works around the segfault.

But it will soon not be possible at all it looks like. I have not tried that yet in a copy of the shell script.

[thesourcehim]

Can primus be built with glvnd instead of legacy gl, or it's not compatible?

[gsgatlin]

From what I can tell USE="-compat" is a gentoo thing. So I'm at a loss as to what to do. I'm very sorry. Does anyone know what that does? I asked on the nvidia forums. Then again what do I know about any of this stuff really.

I don't know if VirtualGL or primus projects have any interest in glvnd support. I would ask but I don't know if its supported any longer. Maybe if Aaron Plattner from NVIDIA Linux Graphics asked he might get an answer? Maybe he will open an issue on primus github site?

I had a opened pull request but he never replied.
amonakov/primus#195

I'm sorry if I did something wrong in my pull request or otherwise bothered him. Sincerely.

The guy who makes VirtualGL does not like the rules about how stuff is compiled on fedora so I am unsure about asking him anything also. I am trying to upgrade that package to a newer version however for a non bumblee user. I'm not sure if that breaks that use case. I guess I'm gonna find out though with the rpmfusion drivers on a desktop PC over ethernet. Then I can go ask on the mailing list if its broken.

I honestly just have no clue why nvidia haven't come up with something official after 7 freaking years like dri prime or something. Something that work like it does on windows so you don't have to log out/log in. I'm super bummed out about this and very stressed out. Thinking about switching to centos and keeping my fingers crossed for how long it works. If you comment on any of the issues on the nvidia dev forums I'd advise being super nice because getting all pissed off probably won't help sway their minds.

All we can do now is probably watch the discussions to see if anyone replys. I asked if there is a patch for NVIDIA-Linux-x86_64-418.56.run and kernel 5.1 so we'll see. perhaps a patch can be developed from http://rglinuxtech.com/?p=2530

I will try later when I have more energy.

[gsgatlin]

Here is a patch for legacy driver 390.116 to work on kernel 5.1:

https://paste.fedoraproject.org/paste/qXeYjMoRTlp7uvRiFSmgOQ

Here is a patch for out of date driver 418.56 to work on on kernel 5.1:

https://paste.fedoraproject.org/paste/AMguWBz1U1Q3dSHj-Jp41A

I will add the second one to the bumblebee-nvidia package when I have more energy since it works with 5.0 kernel also.

I am uncertain whether these could be patched to work with a future 5.2 kernel. Or if anyone who knows how to make these patches will even care since nvidia 4.30.XX is out now....

All these were tested with kernel-5.1.5-300.fc30.x86_64.

[gsgatlin]

So it looks like bumblebee can work with 430.14 but my shell script needs to be altered to not use

--no-libglx-indirect --no-install-libglvnd --no-glvnd-glx-client --no-glvnd-egl-client

So I will work on getting that out once I have tested it a bit more with some applications.

[thesourcehim]

It's working now! Additionally applications linked with libglvnd instead of legacy gl now work with bumblebee too (they did not before).

[gsgatlin]

Cool. I'm glad its working. Hopefully it will continue working after they go to something higher then 430.

[giomasce]

@gsgatlin I think I have the same problem, and it seems that you manage to find a workaround, but I do not understand it. You mention a script, but I don't understand which one. Could you please summarize how to implement your workaround? Thanks!

[gsgatlin]

Hello. So I made some bumblebee packages for RHEL and fedora. The nvidia driver is installed in a package called bumblebee-nvidia which contains a script called bumblebee-nvidia which is also in a separate git repo.

Here is a link to the commit where I made the change:

gsgatlin/bumblebee-nvidia@ed0d809

Hope that helps.