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

Hi,

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:

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?

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 close merge delete

Sort by » oldest newest most voted

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.

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.

more