Bug#761062: Upgrading from 304.117-1 to 340.32-1 with older graphics card leaves system without X Windows

[Marvin Renich]

* Andreas Beckmann <anbe at debian.org> [140923 03:46]:
> We already have a NEWS entry about the legacy stuff - but nobody reads
> that or uses apt-listchanges.

Having a NEWS entry is important, but not sufficient.  I filed this bug
because the problem happened on my father's machine (which does have
apt-listchanges installed).  However, even if he were to have read the
changes carefully, he would not have known which specific GPU model he
has, nor would he have realized that it was important to find out before
continuing.

> We could probably reuse the approach I used for fglrx-driver in wheezy
> where AMD removed support for some legacy hardware ... and created a
> legacy driver that has not been maintained for newer Xorg versions ...
> 
> Raw outline: While installing or upgrading to the current (not a legacy)
> nvidia-driver (not sure which package this should go to) we have a
> debconf prompt in preinst that reports *unsupported* hardware (having
> *no* supported hardware in a system is not an error) and asks whether to
> proceed or abort. The answer will be remembered for future upgrades.
> This check can be disabled via preseeding to allow unattended
> installations in such setups - the admin probably knows what he does in
> this case.
> We probably need two cases here: totally unsupported and
> legacy-supported, giving hints about the legacy package to install instead.
> 
> nvidia-detect is probably *not* the tool for this task.

I still believe that a debconf prompt is the wrong solution.  If the
currently installed version of nvidia-kernel-dkms and/or nvidia-driver
supports the hardware, but the new version does not, and the appropriate
legacy packages are not installed, the upgrade should fail.  Period.
There is no reason to prompt the user, and the debconf priority should
not have any bearing on the outcome.

Looking closer at nvidia-detect, it doesn't provide enough information
by itself, because it doesn't have the nvidia.ids file for both the
currently installed package and the new version of the package.

I think what is needed is for nvidia-kernel-{legacy-.*}?dkms
and nvidia-{legacy-.*}?driver to each have their own copy of the
nvidia.ids file (4K).  Then, during preinst, check if the unpacked (new)
version of that file contains the pci id for the GPU.  If it does,
continue with the installation (the hardware is still supported).

Otherwise, check the nvidia.ids file from the currently installed
(older) package.  If that file does not have the pci id, then the older
package didn't support this hardware either, so we can safely continue
the installation; we aren't going to break something that was working
before the upgrade.

Now we have the case that the GPU was supported by the currently
installed package, but is not supported by the new package.  Has the
user installed an appropriate legacy package?  Look for the pci id in
the nvidia.ids files in all the installed legacy packages.  If you don't
find it, abort the installation.

If you found it, does the nvidia alternative point to that legacy
package?  If yes, continue the installation, otherwise, abort.

One thing I am not sure about is whether the unpacked files are moved
into their proper place in the file system before or after running the
preinst script.  If the are moved before, then we need a different
method to obtain the nvidia.ids file of the old package.

...Marvin