-nvidia upgrade issues

Mario Limonciello superm1 at ubuntu.com
Wed Nov 4 23:08:17 GMT 2009

Hi Bryce:

I've got a couple of comments i'll echo here

On Wed, Nov 4, 2009 at 16:26, Bryce Harrington <bryce at canonical.com> wrote:

> I've been looking into some problems people have been reporting
> upgrading to Karmic with -nvidia installed.
> One thing I've noticed is aside from whatever issue is occuring with
> nvidia, there are bugs elsewhere which are compounding the problems and
> leading to some poor user experiences.  A common scenario occurs if for
> whatever reason the -nvidia kernel module fails to build in DKMS:

It would be very good to try to get a sampling of why the kernel modules are
failing to build.  Can you try to get people to collect the failed
make.log's in these scenarios?

> 438398 - If DKMS fails to build the kernel module, the package upgrade
> does not kick out.  It shows package upgrade as successful.  So this
> leads directly to...
So the problem with declaring the package as failed if the DKMS build failed
is that it may actually pass or fail depending on how far along into the
updates you are.

Say you are updating to a new linux-headers with a new ABI at the same time
as installing the NVIDIA package.

Well if the NVIDIA package is processed first, the headers aren't yet
installed, so the package will fail during postinst, but as soon as the
headers are loaded, the kernel postinst runs and the modules get
successfully built.
Perhaps a potential solution is to look into whether the headers are yet
available for this kernel, and if they aren't don't let the DKMS build fail
cause the postinst to fail, but in any other scenario let the postinst fail.

> 451305 - Jockey misses that the driver failed to build, and so is not
> letting users know about the potential problem.  It goes ahead and
> updates xorg.conf as if the driver was there.  X tries to obey the
> configuration settings, but of course they won't work, so it exits on
> startup with an error message.  *Normally* bulletproof-X would kick in
> at this point, display the error to the user, and give them some tools
> to diagnose and/or debug the situation.  Unfortunately...

I see three potential improvements to Jockey for this scenario.

   1. Have Jockey be able to work in an interactive frontend.  If the
   package install behavior is modified to query if the headers are yet
   available, then you can more nicely present this information to the user
   2. Have Jockey check for the headers for the current kernel before even
   starting to install the packages.
   3. Before modifying the xorg.conf, do the equivalent of a modinfo nvidia
   to determine if the nvidia kernel module is indeed created.  Show a
   warning/error otherwise.

> 474806 - The new gdm no longer supports the FailsafeXServer option, so
> the diagnostic session no longer can be triggered to come up.  Instead,
> gdm tries several times, then gives up, but then...
> 441638 - The gdm upstart job notices gdm has failed and so restarts it.
> X of course continues to fail, gdm tries a few times and continues to
> fail, repeat ad infinitum, and the user is just left looking at a
> flashing screen.  Ick.
> This has been a pet peeve of mine too, so i'm glad to see a karmic-updates
milestoned task on this bug.

> The above appears to be a pretty common scenario that we're getting a
> rash of bug reports about.  It's hard to be certain because many of the
> bug reports are only including information about the failed boot, not on
> the failed build.  So I'm not sure if it is just one reason why the
> build fails, or several.  However if we can solve the above bugs it
> should give much better visibility into things.
> Btw, workaround for anyone experiencing this issue is to purge your
> nvidia (and fglrx) packages, remove /etc/X11/xorg.conf, and reinstall
> nvidia (or fglrx).  It appears that in most of the bug reports this gets
> the system functioning again.  Doing a full reinstall of Ubuntu rather
> than an upgrade also appears to work around the issues.
> Bryce
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Mario Limonciello
superm1 at gmail.com
Sent from Manchester, New Hampshire, United States
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20091104/a0ed512a/attachment.htm 

More information about the ubuntu-devel mailing list