Hints to get Bumblebee working on an Optimus laptop with discrete Nvidia graphics card

English Hardware
#1

I have an Optimus controlled Laptop with a discrete graphics card, a Nvidia Geforce GTX 670MX, and an Intel processor i7-3630QM with integrated graphics card using the i915 module.
This hardware constellation worked well with OpenSUSE 13.1 and bumblebee, allowing to use flight simulator X-Plane 10 under Linux with HD-resolution and good response characteristic.
The smithfarm site http://smithfarm-thebrain.blogspot.cz/2013/10/opensuse-131-nvidia-optimus-bumblebee.html helped me to correctly install bumblebee on OpenSUSE 13.1

A fresh installation of OpenSUSE 13.2 brought up the system with a decent graphics constellation using i915 and nouveau kernel modules.
Low power consumption in idle state hinted at a working offloading of the nouveau module yet without bbswitch installed.

The OpenSUSE 13.1 ‘smithfarm’ way of getting bumblebee and the proprietary Nvidia driver/module working **didn’t succeed **with OpenSUSE 13.2 though.

I reinstalled OpenSUSE 13.2 from scratch to start with a defined state.

I installed kernel headers kernel-devel and dependencies and joined the repository
Bumblebee_project_(openSUSE_13.2)|
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_13.2/

Next I installed bumblebee and dependencies from the repository above.
I prefer to use ‘zypper install package’ in such a case, because result reporting/reading is better than with yast.

message from package bumblebee:

INFO: Please ensure that users using bublebee/video card are in following group(s):
INFO: gpasswd -a <USER> bumblebee
INFO: If going to use nvidia binary driver:
INFO: gpasswd -a <USER> video

INFO: Also ensure the nouveau module is blacklisted (even if you plan to use it):
INFO: echo “blacklist nouveau” >> /etc/modprobe.d/50-blacklist.conf
INFO: mkinitrd

I did as told by package bumblebee, but the blacklist nouveau part had no effect, so I reverted this blacklisting and allowed nouveau again. I didn’t run mkinitrd.

I enabled bumblebeed:

systemctl enable bumblebeed
systemctl restart bumblebeed

and rebooted.

Next I installed nvidia-bumblebee and nvidia-bumblebee-32bit from bumblebee-repository with dependencies - (NVIDIA-Linux-x86_64-343.22).
Using

zypper install nvidia-bumblebee nvidia-bumblebee-32bit

which reported a successful build of the nvidia module.

After rebooting nothing had changed,

optirun glxspheres

didn’t find the gpu and the nvidia could not be loaded by modprobe.

I found this helpful site then:

https://forums.kali.org/showthread.php?21956-(Guide)-Installing-Nvidia-Bumblebee-CUDA-for-Optimus-enabled-Laptops

and tried to adapt the proceeding there to my situation by checking the BusId of my discrete graphics card with

lspci | egrep 'VGA|3D'

which brought the information about the BusId:

**01:00.0** VGA compatible controller: NVIDIA Corporation GK104M [GeForce GTX 670MX] (rev ff)

This BusId is necessary for inserting it to:

nano /etc/bumblebee/xorg.conf.nvidia

which looks like this now:

Section "ServerLayout"
    Identifier  "Layout0"
    Option      "AutoAddDevices" "false"
    Option      "AutoAddGPU" "false"
EndSection



Section "Device"
    Identifier  "DiscreteNvidia"
    Driver      "nvidia"
    VendorName  "NVIDIA Corporation"
   ** BusID "PCI:01:00:0"**
    Option "ProbeAllGpus" "false"

    Option "NoLogo" "true"
    Option "UseEDID" "false"
    Option "UseDisplayDevice" "none"
EndSection

Whereby the change happend within the line
BusID “PCI:01:00:0”

Next it is necessary to edit

nano /etc/bumblebee/bumblebee.conf

and change the line

Driver=

to

Driver=nvidia

Rebooting the system didn’t bring up the nvidia driver yet, I had to reinstall the nvidia driver - as described at the kali.org site - by:

zypper in -f nvidia-bumblebee nvidia-bumblebee-32bit

which finally did the trick after restarting bumblebeed with:

systemctl restart bumblebeed

optirun glxspheres

worked well and the system switched back to Intel graphics with low power consumption after stopping glxspheres.
X-Plane 10 is very usable with this configuration.
The nouveau module is not blacklisted.

Good Luck!
BrunoLab

#2

bumblebee just got updated to version 3.2.1-16.1, the nvidia-bumblebee driver updated to 343.22-1.1.
Restarting bumblebeed was not enough, I had to reboot and

zypper in -f nvidia-bumblebee nvidia-bumblebee-32bit

again.
After another reboot optirun glxspheres worked again.

#3

This doesn’t work for me either.

#4

Sorry to hear about your problems.

Here bumblebee is doing its job so far. Sole thing, I changed in the meantime:
Because from time to time after rebooting the nouveau module had appeared in the lsmod list,
I finally blacklisted nouveau in /etc/modprobe.d/50-blacklist.conf without calling mkinitrd.
The procedure described in my first post worked without blacklisting nouveau.

Blacklisting nouveau right after installing bumblebee in fact blocked every progress.

After all it was a tedious task of trial and error to get bumblebee up and running on my system.
The interference of the proprietary driver from Nvidia with the usual zypper installation procedure gives you
that kind of Windows feeling - either it is working or you get little help about what’s going wrong.

Good luck!

#5

After successful installation of the graphical system as described above, everything worked well, the discrete Nvidia graphical card allowed playing ‘optirun glxspheres’ and X-Plane 10,
and everything seemed fine …

Some zypper update procedures later, it was no longer possible to get the Nvidia card up and running with the proprietary driver.
The bumblebee based graphical system is highly susceptible for changes of the rest of the operating system.
Therefore it is unstable and not recommendable for someone, who wants to just use it without further troubles.

My suspicion is raised by the mkinitrd process, that is called by certain updated system packages.
At least calling ‘mkinitrd’ to make blacklisting the nouveau driver a part of the initrd was a sure method to doom the bumblebee graphical system.
I then couldn’t get it up and running again, unless I reinstalled the system from scratch and followed the procedure listed above.

The btrfs-filesystem and snapper are a necessary help to return to that virgin state of the graphical system without too much hassle.

Running ‘zypper up’ and updating ‘mdadm’ broke the bumblebee system - the operating system started nevertheless.
After returning to the pre-mdadm-updated state with the help of snapper made it run again.

Updating ‘dbus-1’, ‘dbus-1-x11’, and ‘libdbus-1-3’ to the version 1.8.12-8.1 made the bumblebee system unable to start the discrete graphic card with the nvidia proprietary driver.

While with openSUSE 13.1 you were done with getting bumblebee up and running once,
openSUSE 13.2 has brought with it a broken handling of the proprietary nvidia driver,
which causes a broken bumblebee whenever certain system packages get updated.
Maybe the change from ‘mkinitrd’ to ‘dracut’ is causing this behavior,
but that’s just guessing.

Once bumblebee is broken after such an update, I never could mend it without returning to the virgin state with snapper’s help or reinstalling from scratch.

#6

Thanks Brunolab for the updates. Unfortunately, due to opensuse being so unstable on laptops with optimus hardware, i had to give up and go back to ubuntu, where the optimus support is much better with the nvidia-prime package.
I’ll stay around for updates or maybe hints from users who got bumblebee working.

#7

I don’t think this is a bumblebee problem, possibly a kernel problem. I had no problems in RC1 but several in the final release. Running nvidia only, from the opensuse nvidia repo, over HDMI is very problematic, this worked without any problems in 13.1. It could be the new power management for the nvidia card on Optimus systems, I see a lot about that if I google “nouveau.runpm”, maybe switching to kernel stable solves it, I’ll give that a try over the weekend, my netbook is unbootable right now.

#8

My system with a working bumblebee graphical system (nvidia, 343.22, 3.16.6-2-desktop, x86_64: installed) is stable, awaking without problems from standby, etc., as long as I don’t update the system (zypper up), which I have installed according to my first post here.

It is possible though to set up the bumblebee system under openSUSE 13.2,
but it does not survive updates,
which don’t even touch the graphical system like the ‘mdadm’ package, which is meant to administer a software RAID system,
but which apparently calls post-installation script routines, that seem to change something (links, kernel parameters, module configuration,…) essential
for the bumblebee system.

I had blocked updates of the bumblebee system, nvidia and dkms, but even that mdadm update broke the bumblebee configuration.
Other updates like one for a jpeg library didn’t affect bumblebee.

#9

In #4 you wrote

I finally blacklisted nouveau in /etc/modprobe.d/50-blacklist.conf without calling mkinitrd.

This alone won’t blacklist nouveau, but any program, especially installation scripts, might afterwards run mkinitrd and so blacklist nouveau.
I can’t say I fully understand this new kernel feature that handles the powering down of the nvidia card on Optimus systems, but I have the impression that it’s part of the nouveau driver and consequently we shouldn’t blacklist nouveau any more?

#10

Unfortunately I also don’t know much about the mechanics behind the Optimus module handling and power-saving methods.
The trial-and-error method showed, that without blacklisting nouveau the nvidia-bumblebee installation went okay on my system, with blacklisting it didn’t.
But preventing the blacklisting of the nouveau driver isn’t enough to make the bumblebee system survive ‘zypper up’ updates of the system.

With bumblebee working, my laptop’s power consumption is down to about 17W, X-Plane demanding up to 85W.

#11

Well… :frowning:
I updated my system yesterday, and yes, Bublebee broke again.
It seems to be a problem with the nvidia-bumblebee drivers not installing correctly. (Version 343.36)

The command “zypper in -f nvidia-bumblebee*” dumps a message, telling me something is wrong and rolling back.
The output message also mentions mkinitrd, but running this does not help.

Is there a better way, or any other way, than using Bumblebee for Optimus systems?
(Btw. I am using a NVidia GTX860)

  • Kim -
#12

Btw. the error message I get, is very similar to the one listed here:
https://forums.opensuse.org/showthread.php/502084-How-to-make-Nvidia-Optimus-on-OpenSUSE-13-2-(See-details-inside)?p=2675768#post2675768

#13

Try installing the kernel source. With the source installed I could successfully install the nvidia-bumblebee 343.36 version.B u t that didn’t end the problems of the graphical system. ‘optimus glxspheres’ didn’t run, although the driver seemed correctly installed according to ‘dkms status’.

#14

I ran into a faulty NVIDIA 343.36 update yesterday night. To rule out remains of the previous nvidia-bumblebee install, I uninstalled these packages, then reinstalled the nvidia-bumblebee packages. A reboot and I’m back in business.

#15

Installing kernel-source and removing/reinstalling nvidia-bumblebee packages dit not work.

Output of nvidia-bumblebee-343.36-1.1.x86_64.rpm %posttrans script:
ln: failed to create symbolic link ‘/usr/share/licenses/nvidia-utils/nvidia’: File exists
++ ‘’ -x /usr/sbin/dkms ‘]’
++ /usr/sbin/dkms add -m nvidia -v 343.36 --rpm_safe_upgrade
Error! DKMS tree already contains: nvidia-343.36
You cannot add the same module/version combo more than once.
++ /usr/sbin/dkms build -m nvidia -v 343.36
Module nvidia/343.36 already built for kernel 3.16.6-2-desktop/4
++ /usr/sbin/dkms install -m nvidia -v 343.36

nvidia:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.16.6-2-desktop/updates/
Adding any weak-modules

depmod....

Backing up initrd-3.16.6-2-desktop to /boot/initrd-3.16.6-2-desktop.old-dkms
Making new initrd-3.16.6-2-desktop
(If next boot fails, revert to initrd-3.16.6-2-desktop.old-dkms image)
dracut....(bad exit status: 1)

-------- Uninstall Beginning --------
Module:  nvidia
Version: 343.36
Kernel:  3.16.6-2-desktop (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.
Removing any linked weak-modules

nvidia.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.16.6-2-desktop/updates/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod....

Backing up initrd-3.16.6-2-desktop to /boot/initrd-3.16.6-2-desktop.old-dkms
Making new initrd-3.16.6-2-desktop
(If next boot fails, revert to initrd-3.16.6-2-desktop.old-dkms image)
dracut....(bad exit status: 1)
: There was a problem remaking your initrd.  You must manually remake it
before booting into this kernel.

DKMS: uninstall completed.
Error! Problems with mkinitrd detected.  Automatically uninstalling this module.
DKMS: Install Failed (mkinitrd problems).  Module rolled back to built state.
++ popd
#16

I know this error message very well!Only thing that I can suggest now, is installation of ‘zypper in open-lldp fcoe-utils’, if you get some error messages when running mkinitrd about some missing dcbtool, fipvlan and lldpad. I am not sure, whether this will help, though.You can tell dkms about the built nvidia driver with: 'dkms install -m nvidia -v 343.36’But in my case, despite an nvidia-bumblebee installation without any error message, I cannot switch on the nvidia card with the proprietary driver.

#17

Thanks. :slight_smile:
I will try installing these, when I get home from work.

I actually tried the command ‘dkms install -m nvidia -v 343.36’ yesterday, without any luck.
I also tried grabbing an earlier version of nvidia-bumblebee, but that didn’t work either.
(Manual download from http://download.opensuse.org/repositories/home:/sysek/openSUSE_13.2/)

This is the kind of challenges, which kept me from rolling with Tumbleweed. lol!

#18

That did it!
Thank you very much!

Here is what i did:

sudo zypper in open-lldp fcoe-utils
sudo dkms install nvidia/343.36
sudo mkinitrd
sudo systemctl enable bumblebeed.service

Rebooted, and all is fine.

#19

Chiming in to tell that the trick below fixed it for me as well. Thank you thank you thank you.

#20

Great it worked for you and thanks for posting your proceeding!

I found out, that without the file /etc/sysconfig/kernel I couldn’t install the 343.36 nvidia driver, despite ‘zypper in open-lldp fcoe-utils’ and kernel-source installed.
This file didn’t exist after a fresh install of openSUSE 13.2 on my laptop.
I generated this file with

nano /etc/sysconfig/kernel

and pasted the following content from another post into it:

# Path:    System/Kernel
## Description:
## Type:    string
## Command:     /sbin/mkinitrd
#
# This variable contains the list of modules to be added to the initial
# ramdisk by calling the script "mkinitrd"
# (like drivers for scsi-controllers, for lvm or reiserfs)
#
INITRD_MODULES=" "

## Type:        yesno
## Default:     ""
## Command:     /sbin/mkinitrd
#
#
# This variable disables the initialization of KMS in the initrd
# by not including the modules required for KMS even though KMS is
# supported on the underlying hardware.
# After changing run mkinitrd again.
#
NO_KMS_IN_INITRD="no"

## Type:        string
## Command:     /sbin/mkinitrd
#
# This variable contains the list of modules to be added to the initial
# ramdisk that is created for unprivilegd Xen domains (domU); you may need
# drivers for virtual block and network devices in addition to filesystem
# and device-mapper modules.
#
DOMU_INITRD_MODULES="xennet xenblk"

## Type:        string
## Default:     ""
#
# The file name of a binary ACPI Differentiated System Description Table
# (DSDT). This table is appended to the initial ram disk (initrd) that
# the mkinitrd script creates. If the kernel finds that its initrd
# contains a DSDT, this table replaces the DSDT of the bios. If the file
# specified in ACPI_DSDT is not found or ACPI_DSDT is empty/not specified,
# no DSDT will be appended to the initrd.
# Example path /etc/acpi/DSDT.aml
# You can also override Secondary System Description Tables (SSDTs).
# Add DSDT and SSDT files separated by spaces, e.g. "DSDT.aml SSDT1.aml"
# The files must be named DSDT.aml and/or SSDT[1-9]*.aml.
# For compatiblity reasons, if only one file is added it is assumed it is
# the DSDT and will be used as such, in future the above naming scheme
# will be enforce.
# Be aware that overriding these tables can harm your system.
# Only do this if you know what you are doing and file a bug on
# bugzilla.kernel.org so that the root cause of the issue will get fixed.
ACPI_DSDT=""

Afterwards the installation succeeded with ‘dkms install nvidia/343.36’ and the module nvidia was added to two lines of the /etc/sysconfig/kernel file.

One must be aware, that after repeated (incomplete) tries to install nvidia there might be added more than just the one nvidia addition in the lines
INITRD_MODULES=" nvidia"
and
DOMU_INITRD_MODULES=“xennet xenblk nvidia”
but repetitions would surely cause problems.