Bug 1354256 - Unable to install Fedora 24 on MSI GS60 6QE, likely due to hybrid graphics
Summary: Unable to install Fedora 24 on MSI GS60 6QE, likely due to hybrid graphics
Alias: None
Product: Fedora
Classification: Fedora
Component: 0install   
(Show other bugs)
Version: 24
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Michel Alexandre Salim
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-07-11 05:08 UTC by Mario J Borgnia
Modified: 2017-08-08 15:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-08 15:30:30 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mario J Borgnia 2016-07-11 05:08:51 UTC
Description of problem:
System installation locks on Started Session c5 of user gdm

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Insert USB flashdrive with Fedora 24
2. Start Fedora-Workstation-Live 24 in basic graphics mode

Actual results:
System seems to progress with boot until it locks after displaying 
"Started Session c5 of user gdm"
Pressing the shutdown key results in shutdown.

Expected results:
Normal boot into graphic mode

Additional info:
I have also tried to install OpenSUSE Tumbleweed, with Bumblebee. In that case, installation proceeded as expected, but the NVIDIA GPU could not be activated, if activated, the system would lock up.

This is the description of the process in OpenSUSE
# GS60 6QE
# CPU: Intel® Core™ i7-6700HQ
# GPU: NVIDIA GeForce® GTX 970M

# OpenSUSE Tumbleweed
# UEFI Enabled
# Fast Boot Enabled
# Secure mode Enabled
# Intel(R) SpeedStep(tm) Disabled
# CPU C states Disabled

# Installed using nomodeset, otherwise installation does not proceed
# Press e while starting installation and add nomodeset
# installed to /dev/sda using btrfs
# then reboot
# press Del key and change the following
# Boot Option #3 changed to UEFI Hard Disk: opensuse-secureboot
# This is selected via UEFI Hard Disk Drive BBS Priorities

# updated all before starting the next step
# also updated the kernel to 4.6.3-1-1

# What follows is the specific steps that worked until the last one

sudo zypper install -t pattern devel_C_C++ devel_kernel

# Installing Bumblebee/NVIDIA using the Bumblebee repository
# Add Bumblebee/Nvidia repository with priority 90
sudo zypper ar -f http://download.opensuse.org/reposit...SE_Tumbleweed/ Bumblebee
sudo zypper mr -p 90 Bumblebee

# Install bumblebee
sudo zypper in bumblebee
sudo gpasswd -a mborgnia bumblebee
sudo gpasswd -a mborgnia video
echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf
sudo systemctl enable bumblebeed
sudo mkinitrd

# Install the corresponding nvidia drivers
sudo zypper nvidia-bumblebee
sudo systemctl enambe dkms
sudo zypper in nvidia-bumblebee-32bit

# Put the system init mode 3 to separate graphic card issues
sudo systemctl set-default multi-user.target

### reboot

# System started in multi-user mode (init 3)
# Note: at the end of this process yet Active

optirun --status showed that bumblebeed was not active
[ 185.164629] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[ 185.164658] [ERROR]Could not connect to bumblebee daemon - is it running?

sudo service bumblebeed start

optirun --status
Bumblebee status: Ready (3.2.1). X inactive. Discrete video card is off.

# running startx from user at this point brings the system to a complete lock

Comment 1 Hans de Goede 2016-07-11 08:55:56 UTC

What happens if you start the livecd in runlevel 3? (just add 3 at the end of the kernel commandline)

If that works can you collect a "dmesg" output in runlevel 3 please?

Thanks & Regards,


Comment 2 Mario J Borgnia 2016-07-11 15:06:47 UTC
Hi Hans,
I figured the following. The use of nomodeset in basic graphic mode in this hybrid system does not work well with Fedora. Instead need to use the less restrictive:
There is also a problem with intel cstates that may require:

As you may guess, I am trying to get the NVIDIA GPU to work with this system. I am most familiar with OpenSUSE, as I have used it for all my work for the past 10 years or so. While trying to troubleshoot this installation on my MSI GS60 6QE I read your post at http://hansdegoede.livejournal.com/. I decided to give Fedora a try. With OpenSUSE I was able to boot and get a system that seems to be working, I cannot install get the NVIDIA driver to work. I decided to give Fedora a try, and bumped into this bug.
I guess that it is resolved for now. Please let me know if you need any additional information.

(In reply to Hans de Goede from comment #1)
> Hi,
> What happens if you start the livecd in runlevel 3? (just add 3 at the end
> of the kernel commandline)
> If that works can you collect a "dmesg" output in runlevel 3 please?
> Thanks & Regards,
> Hans

Comment 3 Hans de Goede 2016-07-11 15:11:43 UTC

I would not call needing to add "nouveau.modeset=0 intel_idle.scstate_max=7" resolved, it may be a workaround, but we really want things to just work, without the user needing to add such things.

Can you perhaps make some room on your disk to do a proper fedora install, update to kernel (to the 3.6.x one from updates-testing) and then see if things are better ?

If not can you try blacklisting the nouveau driver and then after boot ssh-ing into the machine and then insmod the driver and see if you can get dmesg output after the insmod?



Comment 4 Mario J Borgnia 2016-07-11 15:38:18 UTC
I agree with you, and I am willing to try and find the causes for this problem.
I can wipe the current OpenSUSE installation and install Fedora. Once I have it running update to kernel 4.6.X (I guess you meant that). I will inform once I am there.


Comment 5 Mario J Borgnia 2016-07-11 15:54:43 UTC
There is a typo in my post, it should be 
# nouveau.modeset=0
# intel_idle.cstate_max=7

Comment 6 Mario J Borgnia 2016-07-11 20:02:21 UTC
Hi Hans,
I am running kernel 4.6.3-300.fc24.x86_64. 
How are things supposed to be better?
How do I go about installing support for switchable graphics?

This is what I have done so far:

sudo vi /etc/default/grub
# add nouveau.modeset=0 intel_idle.cstate_max=7 to the end of GRUB_CMDLINE_LINUX
grub-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
# added updates-testing repo
yum --enablerepo=updates-testing check-update
yum update



Comment 7 Mario J Borgnia 2016-07-11 20:28:12 UTC
Removing nouveau.modeset=0 leads to a system lockup.
Adding rd.driver.blacklist=nouveau instead of the variable above does not help.
Added both and nouveau was loaded after booting...
Also did:
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf

nouveau is still loaded
rmmod nouveau did not prevent X from starting

How do I really blacklist nouveau in Fedora 24?

Comment 8 Mario J Borgnia 2016-07-11 21:19:17 UTC
Installed bumblebee as per instructions in:

dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora24/noarch/bumblebee-release-1.2-1.noarch.rpm

dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/fedora24/noarch/bumblebee-nonfree-release-1.2-1.noarch.rpm

dnf install bumblebee-nvidia bbswitch-dkms VirtualGL.x86_64 VirtualGL.i686 primus.x86_64 primus.i686 kernel-devel


Comment 9 Mario J Borgnia 2016-07-11 21:20:03 UTC
optirun -b none nvidia-settings -c :8
[  193.017473] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[  193.017511] [ERROR]Could not connect to bumblebee daemon - is it running?

Comment 10 Mario J Borgnia 2016-07-11 21:24:44 UTC
[  639.041904] bbswitch: module verification failed: signature and/or required key missing - tainting kernel
[  639.042555] bbswitch: version 0.8
[  639.042564] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[  639.042571] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[  639.042589] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  639.042736] bbswitch: detected an Optimus _DSM function
[  639.042752] pci 0000:01:00.0: enabling device (0006 -> 0007)
[  639.042851] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on

Comment 11 Hans de Goede 2016-07-11 21:32:35 UTC
Hi Mario,

I was hoping that with 4.6.x you would no longer need the nouveau.modeset=0, as for the blacklisting, try regenerating your initrd using "dracut -f", after creating the blacklist.conf .

As for bumblebee, we do not support bumblebee, but I would like to see this laptop just work on the igpu without needing the nouveau.modeset=0 



Comment 12 Mario J Borgnia 2016-07-11 23:32:42 UTC
Hi Hans,
Thanks for your help! I guess I will have to remove bumblebee in order to try just blacklisting nouveau. Now that nvidia is installed, and nouveau is not loaded, the flag nouveau.modeset=0 can be removed.
The bumblebee daemon was not working because I had enabled multi-user. When I enable graphical, the system will lock up if I log in. Still working on that.

Is the idea that the laptop will work with the nvidia drivers as well or just the iGPU?

Best regards


Comment 13 Alexander Nolting 2016-08-08 15:12:17 UTC
Hi Hans,

I'm having exactly the same issues but with a Lenovo Y700. I followed the wiki instructions for bumblebee and it didn't work as described.

I figured out that in the repo 


does not contain the file bumblebee-nonfree-unmanaged-release-1.2-1.noarch.rpm. There are only bumblebee-nvidia-2.0-(n).fc24.noarch.rpm packages found.

Due to this issue I decided to use the managed variant.
After installing bumble-nvidia (managed), primus etc. and calling bumblebee-nvidia the driver compilation ends with a "OK". But when the laptop reboots, the kernel module is not loaded.


Comment 14 Peter Wu 2016-11-04 23:37:30 UTC
You are likely affected by https://bugzilla.kernel.org/show_bug.cgi?id=156341

Your model (MSI GS60) and others will lock up as soon as the NVIDIA GPU is powered on again (via nouveau or bbswitch). A workaround is listed here:

Mario, can you give the acpi_osi workaround a try and report back the results? It should work with nouveau.

@Alexander Is your model the same as https://bugs.launchpad.net/ideapad-laptop/+bug/1528299?LENOVO CDCN25WW, BIOS 1.25 (09/04/2015). More friendly name:
Lenovo Ideapad Y700-15ISK. Based on the acpidump ("If(OSYS == 0x07D9)" in the PGON method of ssdt1.dsl), can you try adding this workaround to your kernel command line and report results:

acpi_osi=! acpi_osi="!Windows 2009"

1. boot with workaround
2. execute lspci.
3. wait for at least 5 seconds, execute lspci again
4. Verify that you see something like (from step 3):
"nouveau 0000:01:00.0: DRM: resuming kernel object tree..."
"nouveau 0000:01:00.0: DRM: resuming console..."
Five seconds later it should show:
"nouveau 0000:01:00.0: DRM: suspending console..."
Then step 4 should the same "resuming" message.

Comment 15 Fedora End Of Life 2017-07-25 21:43:23 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 16 Fedora End Of Life 2017-08-08 15:30:30 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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