nvidia -177 needs to be transitioned to -180 on upgrade

[Tim Lunn]

I just tried to upgrade to jaunty beta. It failed and now X will not start at all.

X goes to a blank screen, system becomes totally unrepsonive and I cannot even change out to a text terminal.

So now I decide to test the 'live CD' (which I prob should have done before the upgrade but anyway), it does the same thing, unless I select 'safe graphics mode'

I using a nvidia 9600GT card (w/ two monitors), on 64-bit intel system.

[Tim Lunn (darkxst)]

So looks like this is a bug with the 177 drivers.

X is loading but fails to display anything (i.e. all I get is a blank screen), I had a quick look through the Xorg log and there doesn't seem to be any errors. Which may explain why failsafe/low graphics mode does not kick in, since as far as the Xserver is concerned there are no problems with the graphics.

I have now upgraded to the 180 drivers and things seem to be working ok.

[Matt Zimmerman (mdz)]

If your card doesn't work properly with 177, but does with 180, jockey should be checked that it is selecting the proper driver for it, and perhaps update-manager should migrate it to the new version.

[Bryce Harrington (bryce)]

Hi darkxst,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Tim Lunn (darkxst)]

v177 doesnt seem to be in the repo's for jaunty, so I cant revert back to that version. Perhaps it was using a package that was left over from intrepid.

I can also recreate this bug by booting up off the live cd, however I have no way of getting to the logs, since I am stuck at the blank X screen.

I tried installing 173 it also failed to work. see attached log

[Martin Pitt (pitti)]

Unfortunately jockey can't do anything during upgrades.

Alberto, as far as I can see, we should reintroduce transitional -177 packages which pull in -180, so that upgrades do the right thing automatically. I propose to maintain those transitional packages in nvidia-common, easier to maintain there. WDYT?

[Alberto Milone (albertomilone)]

Tim: what's the output of this command?
nvidia-detector

[Tim Lunn (darkxst)]

$ nvidia-detector
none

On 09/04/09 18:02, Alberto Milone wrote:
> Tim: what's the output of this command?
> nvidia-detector
>
>

[Alberto Milone (albertomilone)]

the fact that it returns "none" (now that 177 is no longer installed) is ok.

nvidia-common is already used by Update Manager to migrate drivers from obsolete versions to more appropriate versions. I wonder why this didn't work.

Michael: any ideas?

[Alberto Milone (albertomilone)]

If I force the installation of driver 177 in Jaunty and I type nvidia-detector I get this:
$ nvidia-detector
nvidia-glx-180

which means that nvidia-glx-180 should be installed instead.

[Alberto Milone (albertomilone)]

Tim: did you upgrade your system using Update Manager or did you use the command line?

[Tim Lunn (darkxst)]

I upgraded using update manager.

nvidia-detector (nvidia-common package) was not installed just before
when I tried to run it. All though I may have removed it when I was
removing all the old drivers to get things working after the upgrade,
not sure.

On 09/04/09 21:01, Alberto Milone wrote:
> Tim: did you upgrade your system using Update Manager or did you use the
> command line?
>
>

[Martin Pitt (pitti)]

I still think it would be more robust to have transitional -177
packages just depending on the -180 ones. This will ensure that people
using apt-get dist-upgrade won't end up with an unbootable system, and
is probably also more reliable than the migration in u-m. The latter
is still a good idea, of course, since potentially never versions of
the driver need different xorg.conf options.

[Alberto Milone (albertomilone)]

Martin:
yes, that could be done (in this very specific case) but it would still be nice to see what happened.

In this case the transition can be smooth but usually there is no such clear transition to new drivers. For example what happens if 180 is no longer supported and part of the cards that it used to support should use, say, 173, while the other part of its supported cards should use, say, 190 (which I just made up)?

Tim: can you attach the files that you have in /var/log/dist-upgrade/ , please?

[Larrin (larrin-habeger)]

I just tried to upgrade to Jaunty from Intrepid using Nvidia 177. 173 had issues with buggy scrolling and 180 freezes ALL the time. Now that I have Jaunty installed there is no option to install 177. It is not supported on AMD64. That's odd because it was support and worked fine in Intrepid. Consequently I will have to revert back to Intrepid.

Sucks to be me.
Larrin

[Alberto Milone (albertomilone)]

Larrin: Nvidia dropped the support for 177 and there's nothing we can do about it, other than migrating users to 180.

[Martin Pitt (pitti)]

Alberto, indeed for more complicated cases we can only rely on update-manager.

apt.log has lots of

  ERROR:root:NvidiaDetector can not be imported No module named NvidiaDetector.nvidiadetector

which is most probably the cause of the failed transition here. This might be the cause or followup:

2009-03-30 17:08:53,526 DEBUG nvidiaUpdate()
2009-03-30 17:08:53,581 ERROR NvidiaDetection returned a error: dir ./modaliases/ not found

[Alberto Milone (albertomilone)]

Martin, the following problem depended on Python but, according to doko it's fixed now:
ERROR:root:NvidiaDetector can not be imported No module named NvidiaDetector.nvidiadetector

As regards this error:
ERROR:root:NvidiaDetection returned a error: dir ./modaliases/ not found

it looks like only in this case nvidia-common worked (without import errors) but the modaliases were not available. I guess it refers to the modaliases used by (and stored in) Update Manager as "./modaliases/" looks to me like a local path.

Here's the part that failed in Update Manager (in DistUpgrade/DistUpgradeCache.py):
http://pastebin.ubuntu.com/150801/

Michael, any ideas on this?

[Michael Vogt (mvo)]

Looking over the logs, I see there is a unreleated problem:
...
Setting up ca-certificates (20080809) ...

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

Xlib: extension "Generic Event Extension" missing on display ":0.0".

/usr/share/themes/Human/gtk-2.0/gtkrc:82: Murrine configuration option "highlight_ratio" will be deprecated in future releases. Please use "highlight_shade" instead.

/usr/share/themes/Human/gtk-2.0/gtkrc:83: Murrine configuration option "lightborder_ratio" will be deprecated in future releases. Please use "lightborder_shade" instead.

/usr/share/themes/Human/gtk-2.0/gtkrc:194: Murrine configuration option "highlight_ratio" will be deprecated in future releases. Please use "highlight_shade" instead.

Updating certificates in /etc/ssl/certs....done.

Running hooks in /etc/ca-certificates/update.d....

updating keystore /etc/ssl/certs/java/cacerts...

Unrecognized command: -importcert

Usage: keytool [COMMAND] [-- COMMAND]...

Manage private keys and public certificates.

Available commands:

  -genkey Generate a Key Entry, eventually creating a key store.

                    [-alias ALIAS] [-keyalg ALGORITHM] [-keysize KEY_SIZE]

                    [-sigalg ALGORITHM] [-dname NAME] [-keypass PASSWORD]

                    [-validity DAY_COUNT] [-storetype STORE_TYPE]

                    [-keystore URL] [-storepass PASSWORD]

                    [-provider PROVIDER_CLASS_NAME] [-v].

  -import Add Key Entries and Trusted Certificates.

                    [-alias ALIAS] [-file FILE] [-keypass PASSWORD]

                    [-noprompt] [-trustcacerts] [-storetype STORE_TYPE]

                    [-keystore URL] [-storepass PASSWORD]

                    [-provider PROVIDER_CLASS_NAME] [-v].

  -selfcert Generate a self-signed Trusted Certificate.

                    [-alias ALIAS] [-sigalg ALGORITHM] [-dname NAME]

                    [-validity DAY_COUNT] [-keypass PASSWORD]

                    [-storetype STORE_TYPE] [-keystore URL]

                    [-storepass PASSWORD] [-provider PROVIDER_CLASS_NAME] [-v].

  -identitydb NOT IMPLEMENTED YET. Import JDK1.1 Identity Database.

                    [-file FILE] [-storetype STORE_TYPE] [-keystore URL]

                    [-storepass PASSWORD] [-provider PROVIDER_CLASS_NAME] [-v].

  -certreq Issue a Certificate Signing Request (CSR).

                    [-alias ALIAS] [-sigalg ALGORITHM] [-file FILE]

       ...

[Michael Vogt (mvo)]

There is a additional solution:
The "oldDrivers" should just be a file as well in nvidia-common instead of part of the source
then u-m can just extract them as during build time (just as its doing now with the modalias files).

[Michael Vogt (mvo)]

Looking at the logs it seems nvidia-glx-177 got removed and the driver in xorg.conf changed to "nv". This is expected behavior if no other driver can be found that supports this card. So it seems the problem is really the "nv" driver (that is used on the livecd by default and having problems as well).

[Tim Lunn (darkxst)]

ok so I probably should pay more attention during the upgrade process
next time :) tho I am sure there were nvidia-glx packages still
installed after the upgrade (and not 180) maybe they were just the older
ones, I was using nvidia-glx-177 in intrepid, and at some stage was
using -envy packages though that prob may have been with hardy.

Anyway I pretty sure my card should be supported in 173 (and did work
with that version in intrepid), also never had any problems with the
"nv" driver with this card previous to jaunty (however vaguely recall
there might have been issues with the nv driver when running monitors on
DVI) . But I guess this is all just related to the new xorg version ?

regardless in the past Xorg has always been good with failsafe'ing over
to vesa driver, which didnt happen this time round.

however I am sure there where nvidia-glx packages

On 15/04/09 19:09, Michael Vogt wrote:
> Looking at the logs it seems nvidia-glx-177 got removed and the driver
> in xorg.conf changed to "nv". This is expected behavior if no other
> driver can be found that supports this card. So it seems the problem is
> really the "nv" driver (that is used on the livecd by default and having
> problems as well).
>
>

[Tim Lunn (darkxst)]

yes I do recall there was an issue with ca-certificates during the
upgrade, needless to say I got slightly distracted when X wouldn't
start and forgot all about it.

On 15/04/09 18:49, Michael Vogt wrote:
> Looking over the logs, I see there is a unreleated problem:
> ...
> Setting up ca-certificates (20080809) ...
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> Xlib: extension "Generic Event Extension" missing on display ":0.0".
>
> /usr/share/themes/Human/gtk-2.0/gtkrc:82: Murrine configuration option
> "highlight_ratio" will be deprecated in future releases. Please use
> "highlight_shade" instead.
>
> /usr/share/themes/Human/gtk-2.0/gtkrc:83: Murrine configuration option
> "lightborder_ratio" will be deprecated in future releases. Please use
> "lightborder_shade" instead.
>
> /usr/share/themes/Human/gtk-2.0/gtkrc:194: Murrine configuration option
> "highlight_ratio" will be deprecated in future releases. Please use
> "highlight_shade" instead.
>
> Updating certificates in /etc/ssl/certs....done.
>
> Running hooks in /etc/ca-certificates/update.d....
>
> updating keystore /etc/ssl/certs/java/cacerts...
>
> Unrecognized command: -importcert
>
> Usage: keytool [COMMAND] [-- COMMAND]...
>
> Manage private keys and public certificates.
>
>
> Available commands:
>
> -genkey Generate a Key Entry, eventually creating a key store.
>
> [-alias ALIAS] [-keyalg ALGORITHM] [-keysize
> KEY_SIZE]
>
> [-sigalg ALGORITHM] [-dname NAME] [-keypass
> PASSWORD]
>
> [-validity DAY_COUNT] [-storetype STORE_TYPE]
>
> [-keystore URL] [-storepass PASSWORD]
>
> [-provider PROVIDER_CLASS_NAME] [-v].
>
> -import Add Key Entries and Trusted Certificates.
>
> [-alias ALIAS] [-file FILE] [-keypass PASSWORD]
>
> [-noprompt] [-trustcacerts] [-storetype STORE_TYPE]
>
> [-keystore URL] [-storepass PASSWORD]
>
> [-provider PROVIDER_CLASS_NAME] [-v].
>
> -selfcert Generate a self-signed Trusted Certificate.
>
> [-alias ALIAS] [-sigalg ALGORITHM] [-dname NAME]
>
> [-validity DAY_COUNT] [-keypass PASSWORD]
>
> [-storetype STORE_TYPE] [-keystore URL]
>
> [-storepass PASSWORD] [-provider
> PROVIDER_CLASS_NAME] [-v].
>
> -identitydb ...

[Michael Vogt (mvo)]

I was looking not carefully enough, update-manager is already including a copy of the jaunty nvidia detector and the nvidia-glx-177 is correctly identified and removed. So the problem is really:
a) why nv.selectDriver() did not pick nvidia-glx-180
b) should we use "vesa" instead of "nv" for certain models that are not yet supported

[Michael Vogt (mvo)]

It turns out that (a) is not selected because "restricted" is not enabled

[Alberto Milone (albertomilone)]

In conclusion we found 2 different bugs.
1) If "restricted" is disabled, Update Manager won't know what driver to select, in which case it should simply comment out the Driver line in xorg.conf so that X.org can use an open source driver which works (or is supposed to work) with the card.
2) X.org defaults to the "nv" driver because the id of this specific nvidia card is included in nv's modalias file. The "nv" driver, at least in the version that we're shipping with Jaunty, doesn't seem to work well with this card (hence the black screen).

Problem 1 can be easily fixed in "Update Manager" while 2 should be fixed in "nv".

[Michael Vogt (mvo)]

The update-manager problem is fixed in lp:~mvo/update-manager/post-jaunty

[Martin Pitt (pitti)]

OK, so if restricted was disabled, then the only thing update-manager could do is to warn and offer to enable it again.

Since this seems to be a corner case with -nv and a corner case with local configuration, I take it off the release radar.

[Michael Vogt (mvo)]

I should be more clear, I commited a fix that comments out "Driver "nvidia" " in xorg.conf instead of rewriting it. It should probably also warn the user that he is using a restricted driver but does not have restricted enabled. but that is not done yet.

[Martin Pitt (pitti)]

The "-nv not working on this hardware" is an unrelated issue and should be reported separately. If the user was using the proprietary driver before, the upgrade should keep it, otherwise it'd be a functionality regression either way.

[Tim Lunn (darkxst)]

I would normally have restricted enabled. However I use my ISP's mirror
of the ubuntu repository normally , and this gets disabled at the start
of the upgrade.

In this case shouldnt update manager enable the restricted when it
re-enables the official repo's?

On 04/17/2009 11:49 PM, Martin Pitt wrote:
> OK, so if restricted was disabled, then the only thing update-manager
> could do is to warn and offer to enable it again.
>
> Since this seems to be a corner case with -nv and a corner case with
> local configuration, I take it off the release radar.
>
> ** Changed in: xserver-xorg-video-nv (Ubuntu Jaunty)
> Status: New => Won't Fix
>
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package update-manager - 1:0.120

---------------
update-manager (1:0.120) karmic; urgency=low

  * The 'Ready for karmic' version
  * DistUpgrade/DistUpgradeController.py:
    - do not fail in partial upgrades if apport must be
      enabled (LP: #357755)
    - when rewriting sources.list, check for cdrom entries
      that do not have associated list files and disable
      them (LP: #366459)
    - when rewriting sources.list, deal better with apt-cacher
      apt-torrent style uris (LP: #365537)
  * DistUpgrade/xorg_fix_proprietary.py:
    - instead of replacing fglrx->ati and nvidia->nv just
      comment out the driver and let xorg figure it out
      with its own magic (LP: #351394)
    - update tests/ for the change
  * UpdateManager/UpdateManager.py:
    - use a gtk link button to point the user to further
      upgrade information
  * DistUpgrade/DistUpgradeController.py:
    - ensure ./imported/invoke-rc.d is executable (LP: #147742)
  * refactor the quirks handlers and not run them in partial
    upgrade mode
  * tests/test_sources_list.py:
    - update tests for apt-torrent style uris (LP: #365537)
  * DistUpgrade/DistUpgrade.cfg:
    - remove edubuntu-desktop from the flavour metapackages, its
      not its own flavour anymore
  * help/C/update-manager-C.omf:
    - point to file:/usr/share/gnome/help/update-manager/C/update-manager.xml
      (LP: #368140)

 -- Michael Vogt <email address hidden> Tue, 28 Apr 2009 14:43:26 +0200

[Alex Valavanis (valavanisalex)]

Jaunty has reached end-of-life, so I'll close this report. The bug is marked as being fixed in later versions of Ubuntu