Description of problem:
System installation locks on Started Session c5 of user gdm
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert USB flashdrive with Fedora 24
2. Start Fedora-Workstation-Live 24 in basic graphics mode
System seems to progress with boot until it locks after displaying
"Started Session c5 of user gdm"
Pressing the shutdown key results in shutdown.
Normal boot into graphic mode
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
# 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
# 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
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
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,
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)
> 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,
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?
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.
There is a typo in my post, it should be
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
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...
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?
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
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?
[ 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
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
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?
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.
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.
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'
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.
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.