-nvidia upgrade issues

Bryce Harrington bryce at canonical.com
Thu Nov 5 00:31:14 GMT 2009

On Wed, Nov 04, 2009 at 05:08:17PM -0600, Mario Limonciello wrote:
> 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?

Sure.  Maybe we also need to update ubuntu-bug to automatically attach
those files for nvidia bugs.  Let me know if there are any other files
that are useful for debugging -nvidia or dkms issues and I'll add them
in as well.

> > 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.

*Nod* Also there is at least one bug report where it is claimed dkms was
doing its thing while gdm was starting up, and since the module hadn't
finished building, boom.  Bug 453365.

> > 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.

Agreed.  All three would be worth having, I would prioritize #3 since it
sounds like it would require the least code change and may be quickest
to get an SRU on.  Pitti, opinions?

> > 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.

Yeah, I brought this one up pre-release but I guess too late to solve it
before the release was finalized.  I hope we can see an SRU on it soon.


More information about the ubuntu-devel mailing list