Ask Your Question

Fedora 20 unable to boot after update from kernel 3.11 to kernel 3.12 (Nouveau issue?)

asked 2013-12-21 05:23:39 -0500

remjg gravatar image

updated 2013-12-26 15:58:17 -0500


I have installed the latest kernel update on Fedora 20:

  • previous version : 3.11.10-301.fc20.x86_64 (working well)
  • new version : 3.12.5-302.fc20.x86_64

Unfortunately, I can't seem to have my laptop boot completely with the linux 3.12 kernel.

  • Usually GDM shows up after a long time but when I log in, GNOME Shell doesn't seem to launch.
  • If I try to switch to a virtual console pressing Ctrl+Alt+F2 for example, I rarely manage to log in (computer doesn't seem to react, some errors are displayed involving Nouveau).

My laptop is a Dell Vostro 3300, a kind of pre-optimus laptop with:

  • integrated Intel graphics (ironlake)
  • a discrete Nvidia GeForce 310M GPU

I uninstalled bumblebee without seeing any change and I don't use the proprietary driver. I pasted below what I could gathered using dmesg when I got lucky to log in a virtual console:

fedora pastebin link

Among the common messages I see:

[   38.115354] ALSA sound/pci/hda/hda_eld.c:338 HDMI: invalid ELD buf size -1
[  106.939226] nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x04200000, ch 2
[  112.923355] nouveau E[   PFIFO][0000:01:00.0] channel 2 [DRM] unload timeout

Clearly, I should write a bug report but I have a few questions before:

  1. On which component should I report the bug and how could I explain my issue?
  2. Is there any workaround I could try to boot on the linux kernel 3.12?
  3. How can I gather more information about my problem?

Edit: I have reported the bug on bugzilla (bug 1045851). In the meantime, I also tried to boot on the linux 3.13 kernel (a release candidate from rawhide) with no luck either.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-01-02 16:16:15 -0500

remjg gravatar image

updated 2014-01-03 07:25:26 -0500

I'll answer my own question as a reminder for me in the future but maybe that will help someone.

1) Bug reporting

So the bug has been reported against xorg-x11-drv-nouveau as bug 1045851 and my issue is related to runtime power management.

To find that, I tried to install older kernels from koji following this answer to the question How to force the installation of an old kernel? to track down where my problem first appeared.

Then I had to bisect the linux kernel to find which commit caused my issue which is not a easy task when you don't know... I got the version numbers corresponding to the kernel I had installed from koki in the changelogs (see this question I asked).

2) Workaround

- To keep the 3.11 kernel without fearing any update, I used this answer to the question How to tell yum to keep an old kernel when updating the kernel?.

Then I typed the following command to set the 3.11 kernel as the default boot choice in the grub menu:

grub2-set-default "Fedora, with Linux 3.11.10-301.fc20.x86_64"

(to find the menu entry "Fedora, with Linux 3.11.10-301.fc20.x86_64", I looked up in the file /boot/grub2/grub.cfg)

- To boot on a 3.12 kernel, I disabled runtime power management at boot by adding the parameter nouveau.runpm=0.

I opened as root the file /boot/grub2/grub.cfg:

sudo gedit /boot/grub2/grub.cfg

Then, I looked for the entry corresponding to the 3.12 kernel that was not booting:

menuentry 'Fedora (3.12.5-302.fc20.x86_64) 20 (Heisenbug)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11.10-301.fc20.x86_64-advanced-a165f620-1ba6-49d0-9b56-40cbabe1af33' {
        linux   /vmlinuz-3.12.5-302.fc20.x86_64 root=UUID=a165f620-1ba6-49d0-9b56-40cbabe1af33 ro vconsole.font=latarcyrheb-sun16  rhgb quiet LANG=en_US.UTF-8

And I added the paramater nouveau.runpm=0:

        linux   /vmlinuz-3.12.5-302.fc20.x86_64 root=UUID=a165f620-1ba6-49d0-9b56-40cbabe1af33 ro vconsole.font=latarcyrheb-sun16  rhgb quiet LANG=en_US.UTF-8 nouveau.runpm=0

I will need to do that everytime I install a new kernel. Another (a better?) solution would be to modify directly the file /etc/default/grub so it would be added automatically.

3) Gathering more information

As I read in comment 2 from bug 1045751, we can use journalctl to get the logs of a previous boot:

journalctl --list-boots
journalctl -k --no-pager -b <boot number>  > journalctl.log

I could also add the boot parameter drm.debug=15 to get a more verbose output.

edit flag offensive delete link more


Thanks a lot man this is the exact answer I was looking for. Really appreciated!

Real_B gravatar imageReal_B ( 2014-09-13 01:25:56 -0500 )edit

Question Tools


Asked: 2013-12-21 05:23:39 -0500

Seen: 7,425 times

Last updated: Jan 03 '14