Bug 1450052

Summary:	System upgrade from Fedora 25 to 26 breaks NVIDIA driver
Product:	[Fedora] Fedora	Reporter:	Christophe de Dinechin <dinechin>
Component:	dnf-plugins-extras	Assignee:	rpm-software-management
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	29	CC:	dmach, fziglio, jkadlcik, jmracek, mblaha, rpm-software-management, vmukhame, wwoods, zbyszek
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-12 16:25:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Christophe de Dinechin 2017-05-11 12:57:41 UTC

Description of problem:

Starting from a Fedora 25 system with the latest "official" NVIDIA driver (375.39). This driver cannot build its kernel modules against a 4.10 kernel (issue with linux/fence.h header), so I was keeping a 4.8 kernel around. Also, my system has a M2000 card, and apparently, nouveau cannot deal with it.

I tried a system upgrade, which overall went smoothly, but *removed* the 4.8 kernel entry. As a result, the system cannot boot in graphical mode anymore.

I downloaded the 381.09 beta driver. This one does not install cleanly either: I get an "initialization from incompatible pointer type" for line nvidia-drm-gem.c:558, assigning nvidia_drm_vma_fault to field .fault.

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

python3-dnf-plugin-system-upgrade.noarch 2.0.0-1.fc26 @@commandline

How reproducible: Only tested once

Steps to Reproduce:
1. Install Fedora 25 on a system with some NVIDIA card that nouveau does not like (e.g. M2000)

2. Install latest supported NVIDIA driver to date, 375.39, which means you have to be running a 4.8 series kernel.

3. Do a system upgrade. Watch your 4.8 kernel entry disappear

Actual results:

System boots, fails to launch a graphical session. For a couple of minutes, the screen blinks attempting to start Gnome.

Expected results:

If an NVIDIA driver requiring a 4.8 kernel is installed, either suggest an upgrade and perform that upgrade before upgrading the kernel, or leave a 4.8 kernel entry behind.

Additional info:

Comment 1 Frediano Ziglio 2017-05-11 13:18:19 UTC

Have you tried with 375.66 ?
http://www.nvidia.com/download/driverResults.aspx/118290/en-us
There's also 381.22
http://www.nvidia.com/download/driverResults.aspx/118524/en-us

Comment 2 Christophe de Dinechin 2017-05-11 14:32:01 UTC

Apparently, 381.22 fixes the kernel build issue. Thanks

Comment 3 Christophe de Dinechin 2017-05-11 15:00:20 UTC

But it still fails to load GNOME. I'm still trying.

Comment 4 Christophe de Dinechin 2017-05-11 15:01:48 UTC

Apparently, fails to link against the latest kernel:

FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'refcount_inc'
make[3]: *** [/usr/src/kernels/4.11.0-0.rc8.git0.1.fc26.x86_64/scripts/Makefi

Comment 5 Christophe de Dinechin 2017-05-11 15:08:00 UTC

OK. The 381.22 driver works against 4.10 but not 4.11.

Comment 6 Christophe de Dinechin 2017-05-11 16:34:20 UTC

journalctl output, looking for Linux versions that were booted:

# Initial system setup
May 02 23:49:50 turbo.dinechin.lan kernel: Linux version 4.8.6-300.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016
May 03 09:45:18 turbo.dinechin.lan kernel: Linux version 4.10.13-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Thu Apr 27 20:39:25 UTC 2017
May 03 12:09:09 turbo.dinechin.lan kernel: Linux version 4.8.6-300.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016
May 03 12:19:16 turbo.dinechin.lan kernel: Linux version 4.8.6-300.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016

# My attempts at using 4.10
May 08 19:39:40 turbo.dinechin.lan kernel: Linux version 4.10.13-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Thu Apr 27 20:39:25 UTC 2017
May 08 19:53:20 turbo.dinechin.lan kernel: Linux version 4.10.13-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Thu Apr 27 20:39:25 UTC 2017

# Reverting to 4.8.6 to get graphics
May 08 19:55:04 turbo.dinechin.lan kernel: Linux version 4.8.6-300.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016

# After dnf system-update reboot
May 11 12:37:48 turbo.dinechin.lan kernel: Linux version 4.10.14-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Wed May 3 22:52:30 UTC 2017

# After update
May 11 13:18:57 turbo.dinechin.lan kernel: Linux version 4.11.0-0.rc8.git0.1.fc26.x86_64 (mockbuild.fedoraproject.org) (gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) ) #1 SMP Mon Apr 24 15:42:54 UTC 2017

# Trying to get a version that works (I was testing kernel / driver combinations)
# At that point, 4.8.6-300 was gone from grub.
May 11 13:38:17 turbo.dinechin.lan kernel: Linux version 4.10.13-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Thu Apr 27 20:39:25 UTC 2017
May 11 14:33:39 localhost kernel: Linux version 4.8.6-300.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) ) #1 SMP Tue Nov 1 12:36:38 UTC 2016
May 11 14:35:44 turbo.dinechin.lan kernel: Linux version 4.11.0-0.rc8.git0.1.fc26.x86_64 (mockbuild.fedoraproject.org) (gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) ) #1 SMP Mon Apr 24 15:42:54 UTC 2017
May 11 15:07:48 turbo.dinechin.lan kernel: Linux version 4.10.14-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Wed May 3 22:52:30 UTC 2017
May 11 16:56:36 turbo.dinechin.lan kernel: Linux version 4.11.0-0.rc8.git0.1.fc26.x86_64 (mockbuild.fedoraproject.org) (gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) ) #1 SMP Mon Apr 24 15:42:54 UTC 2017
May 11 17:03:01 turbo.dinechin.lan kernel: Linux version 4.11.0-0.rc8.git0.1.fc26.x86_64 (mockbuild.fedoraproject.org) (gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) ) #1 SMP Mon Apr 24 15:42:54 UTC 2017

# This is what I am running now. 4.10.14 works against driver 381.22
May 11 17:06:41 turbo.dinechin.lan kernel: Linux version 4.10.14-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Wed May 3 22:52:30 UTC 2017

Comment 7 Christophe de Dinechin 2017-05-12 08:47:13 UTC

Summary of my previous comments:

- I now have a working system by combining a 4.10 kernel with a 381.22 driver.

- The original bug is really about the installer deleting the GRUB entry for the running kernel at the time of install. There may be good reasons why someone is running an older kernel (in my case, compatibility with a closed-source driver). I believe that the upgrade process should take special care to preserve the kernel that was running at the time the original upgrade was initiated (i.e. the kernel that was running at the time of dnf system-upgrade reboot).

Comment 8 Marek Blaha 2017-11-30 13:03:35 UTC

From dnf point of view:
- running kernel is always protected and is not removed when doing upgrade
- if you want to keep particular kernel version, you can use command "dnf versionlock exclude 'kernel-0:4.13.13-200*'" to exclude package from all dnf operations
- you can set number of kernels kept on system (default is 3). Just edit /etc/dnf/dnf.conf and set installonly_limit

Comment 9 Fedora End Of Life 2018-05-03 08:26:40 UTC

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. 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 '26'.

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 26 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 10 Jan Kurik 2018-08-14 10:19:31 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 11 Jaroslav Mracek 2019-04-12 16:25:31 UTC

At the present time we cannot offer more than versionlock plugin. Hope that it helped.