Two installer bugs

[macemoneta]

I've encountered two bugs in the 9631 installer:

1. Running the installer with the "-s --no-kernel-module --no-x-check" options still aborts the userland installation with (from the nvidia-installer.log):

Using built-in stream user interface
-> Tagging shared libraries with chcon -t textrel_shlib_t.
-> The file '/tmp/.X0-lock' exists and appears to contain the process ID
   '13145' of a runnning X server.
-> Continuing per the '--no-x-check' option.
ERROR: An NVIDIA kernel module 'nvidia' appears to already be loaded in your
       kernel.  This may be because it is in use (for example, by the X
       server), but may also happen if your kernel was configured without
       support for module unloading.  Please be sure you have exited X before
       attempting to upgrade your driver.  If you have exited X, know that your
       kernel supports module unloading, and still receive this message, then
       an error may have occured that has corrupted the NVIDIA kernel module's
       usage count; the simplest remedy is to reboot your computer.
ERROR: Installation has failed.  Please see the file
       '/var/log/nvidia-installer.log' for details.  You may find suggestions
       on fixing installation problems in the README available on the Linux
       driver download page at www.nvidia.com.

2. Running the installer with the "--update" option, the installer attempts to download the 9746 driver. In other word, to upgrade from the legacy driver to the non-legacy driver, which is obviously incorrect (and won't work, since the hardware is unsupported). From nvidia-installer.log:

Using: nvidia-installer ncurses user interface
-> Tagging shared libraries with chcon -t textrel_shlib_t.
-> Downloading:
   ftp://download.nvidia.com/XFree86/Linux-x86/1.0-9746/NVIDIA-Linux-x86-1.0-97
   46-pkg1.run

Both of these issues make automating the installer around system maintenance impossible.

[zander]

Thanks for your feedback.

The first problem is intended behavior and ensures that no NVIDIA driver components are still in use; this helps avoid e.g. X server crashes on some systems when the NVIDIA X driver module is replaced while still in use by the X server.

The second problem definetely isn't the intended behavior.

[macemoneta]

Originally Posted by zander

Thanks for your feedback.

The first problem is intended behavior and ensures that no NVIDIA driver components are still in use; this helps avoid e.g. X server crashes on some systems when the NVIDIA X driver module is replaced while still in use by the X server.

The second problem definetely isn't the intended behavior.

The problem with the first situation is that it occurs when regularly scheduled (automatic, system unattended) maintenance updates mesa-libGL files or xorg-x11-server-Xorg files, as has happened several times recently (for Fedora). Without the ability to refresh the userland files, the next time the user logs off and X attempts to restart, it will fail.

Re-running the Nvidia installer is the only way to correct that, and as long as the kernel has not changed, the kernel module will continue to function. It's an advanced option for a reason. The alternative is an on-site visit to each workstation, or training everyone on kernel and Nvidia administration.

The worst case scenario is that X can crash and recover, but X crashing and not recovering is a 100% certainty without this option working as expected.

Please reconsider that portion of the implementation.

[zander]

That's not necessarily true - if X crashed in the middle of such a "refresh" installation or if it was run stand-alone (i.e. without a session manager), it would not recover. It's also possible that the console isn't restored correctly in this case, which would probably look just like a system crash to many users. I'm not sure I understand why X can't be shut down temporarily as part of the maintenance updates, e.g. right before the NVIDIA Linux graphics driver installation.

[macemoneta]

Apparently, the system maintenance was able to swap the files and symlinks without causing a crash. Perhaps permitting the operation if and only if the prior version is the same as the current driver would be a better option?

It's undesirable to terminate X, because that also means terminating any running applications and open documents. Since no one is present at the time maintenance is performed, there's no way to determine the impact to the end user of forcing X to close down.