| === marjomercado is now known as marjo | ||
| apw | bryce, tseliot, are we flodded with X issues on Karmic? | 14:45 |
|---|---|---|
| tseliot | apw: we're always flooded with X issues :-) Anything in particular that concerns you? | 14:46 |
| tseliot | (not all of them are real bugs) | 14:47 |
| bryce | apw, it does seem we're getting more than normal; like tseliot said a lot of them are not valid | 17:17 |
| apw | i saw the bug in which you were getting bashed and wondering if it was the tip of an iceberg or not | 17:18 |
| apw | bryce, was trying to acertain if we are failing somewhere to turn off proprietry drivers cleanly enough to allow booting after upgrade or something? | 17:18 |
| apw | which leads us into the gdm constant restart issue which is causing much complaining | 17:19 |
| bryce | which bug was I getting bashed in? | 17:19 |
| bryce | apw, it is possible | 17:19 |
| bryce | apw, I've a sense something is wrong with -nvidia | 17:20 |
| apw | the one about the proprietry drivers not letting them login, lots of flashing etc | 17:20 |
| bryce | apw, like, did the kernel change and we forgot to rebuild it? | 17:20 |
| apw | it got linked to slashdot | 17:20 |
| bryce | oh? | 17:20 |
| apw | yeah thats how i know about it | 17:20 |
| bryce | hrm | 17:20 |
| bryce | mvo, hey question on upgrades for you | 17:34 |
| bryce | mvo, during the upgrade process, do the proprietary drivers get disabled? I'm wondering if it is, then if it should also go ahead and remove the xorg.conf so the user doesn't hit problems on reboot. | 17:35 |
| bryce | mvo, if it does not disable the drivers, perhaps it should do a reinstall in case there are xorg.conf changes needed - according to https://bugs.edge.launchpad.net/ubuntu/+bug/464591/comments/17 some people don't have busid listed there | 17:36 |
| ubottu | Ubuntu bug 464591 in xorg "upgrade breaks graphic drivers and x, preventing login or startx" [High,Won't fix] | 17:36 |
| mvo | bryce: it does not disable proprietary drivers | 18:14 |
| mvo | bryce: but if after the upgrade the driver is no longer avaialble for whatever reason it will remove it from the xorg.conf | 18:15 |
| bryce | mvo, how does it do that removal? | 18:15 |
| mvo | bryce: it comments them out (fglrx and nvidia are the ones that get checked | 18:16 |
| bryce | mvo, does it just comment out the Driver line? | 18:17 |
| mvo | bryce: it also creates a log file, so its easy to figure what it was doing ( /var/log/dist-upgrade/ | 18:17 |
| mvo | bryce: yes, just comments them out | 18:17 |
| bryce | -nvidia installs several lines in addition to Driver, which I imagine could cause problems if -nv is used | 18:17 |
| mvo | I think I asked about this a while ago and was told that unknown options will be ignored | 18:18 |
| mvo | but I can't remember who it was I talked to :/ | 18:18 |
| bryce | hmm | 18:18 |
| bryce | ok, thanks though, this could explain the failures we see | 18:19 |
| bryce | I also would expect unknown options to be ignored though, so my guess may not be right | 18:19 |
| mvo | well, we need more data, the bugreport is not great :/ | 18:20 |
| mvo | upgrade logs for a start | 18:20 |
| bryce | mvo, how does it determine that the driver is no longer available? I'm wondering if it may be that some upgrades are not noticing it | 18:20 |
| bryce | yeah | 18:20 |
| mvo | it simply check /usr/lib/xorg/modules/drivers/ | 18:20 |
| mvo | so it would have to be a chain of error a) nvidia driver no longer available b) xorg with options that cause "nv" to explode | 18:21 |
| mvo | I asked for logs now | 18:22 |
| mvo | the forums have: | 18:24 |
| mvo | (EE) NVIDIA(0): Failed to load the NVIDIA kernel module! | 18:24 |
| mvo | (EE) NVIDIA(0): *** Aborting *** | 18:24 |
| mvo | with instructions like this: | 18:24 |
| mvo | * Boot from the install disk into recovery mode | 18:24 |
| mvo | * download from nvidia.com the NVIDIA-Linux-*.run for your hardware and copy it to your PC (I did it with a second PC and transfered via scp) | 18:24 |
| mvo | * run the NVIDIA-Linux-*.run | 18:24 |
| mvo | * Follow the instructions | 18:24 |
| mvo | * reboot | 18:24 |
| mvo | its no wonder it breaks on every upgrade :( | 18:25 |
| mvo | what can we do to detect situations like ? | 18:25 |
| bryce | hmm | 18:33 |
| bryce | do you think they had hand-installed nvidia previously? | 18:33 |
| mvo | hard to say, but at least one of them suggests it | 18:36 |
| mvo | maybe tseliot knows if there is a way to reliable detect this | 18:36 |
| mvo | hm, I have a testsystem where I can try that I think | 18:38 |
| * mvo searches for a old nvidia card | 18:38 | |
| bryce | apw, 438398 looks like an actionable nvidia bug | 20:01 |
| apw | bug 438398 | 20:01 |
| ubottu | Launchpad bug 438398 in nvidia-graphics-drivers-180 "DKMS build fails, but package upgrade still successful" [Undecided,Triaged] https://launchpad.net/bugs/438398 | 20:02 |
| apw | yeah it does, i assume we should have a dep on the package for the tools it needs | 20:03 |
| apw | though its possible it filaing to install is ok | 20:03 |
| apw | as you can install the package kernel headers and kernel image in any order | 20:04 |
| apw | and it should build on the last one installed i think | 20:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!