LMDE BREAKAGES - tracking TESTING

[gazza]

hi trollboy, follow the post by Lewdsquirrel in the previous page viewtopic.php?f=141&t=67502&start=680#p442696 and you should have gui again;

after that use the "hold" switch provided by viking and you can update safely;

hope you can save it

hi viking

Thanks zerozero , these threads get real messy trying to find solutions. I blindly update && dist-upgrade. Broke nvidia for the forth time, before I was ignorant to using dkms, Ben on irc helped me with that issue and I passed through two kernel upgrades without an issue. I'm using 64bit so modified that , put it in a script and ran it as root, the system auto started x after running it, no driver. After rebooting, all is back the way it should driver running fine:D

for 64bit users, copy this to a file, chmod x and run it as root when your in tty, makes life easier

Code: Select all

#!/bin/bash
cd /var/cache/apt/archives
dpkg -i libgl1-mesa-glx_7.10.2-3_amd64.deb
dpkg -i libglu1-mesa_7.10.2-3_amd64.deb
dpkg -i mesa-common-dev_7.10.2-3_amd64.deb
dpkg -i xserver-common_2%3a1.10.2-1+wheezy1_all.deb
dpkg -i xserver-xorg-core_2%3a1.10.2-1+wheezy1_amd64.deb
dpkg -i libgl1-mesa-dri_7.10.2-3_amd64.deb
dpkg -i libgl1-mesa-dev_7.10.2-3_amd64.deb
apt-get install libgl1-nvidia-alternatives
apt-get install libgl1-nvidia-glx
apt-get install nvidia-glx


(just an fyi, I've had nothing but troubles with smxi, so don't use it).

A tip to lmde users, have at least 2 root partitions on your hd, install a nice stable OS like M10 on one and lmde on the other, when/if lmde breaks, boot the other , come here, find the solutions, make an exicutable file in the 'home' of your lmde, boot the lmde and just run the script, saves a lot of hassels that way

[h2-1]

I'm curious what type of 'nothing but trouble' you experienced with smxi, and in what areas.

Judging from your post it looks like you've had a lot of trouble in general, but I'm wondering what specifics you had with smxi.

Over about 5, 6 years, I've found the most rock solid stable way to run nvidia is via sgfxi/smxi, which simply means using the direct downloaded current real nvidia drivers from nvidia themselves.

All other methods tend to fail at some point.

Note a few things that I've seen mint users really get confused by: first of all, it's not necessary to upgrade constantly, so keep that in mind.

Things that cause you to need to reinstall or rebuild nvidia module is new kernel or new xorg. So smxi of course tracks if you got a new kernel or new xorg during the upgrade and lets you know that you'll need to reinstall your nvidia driver.

The dkms method is not a good method for rolling release, precisely because it fails on xorg updates, and also fails in other circumstances. It is a good method for stable pool distros, which will only see security fix kernel/xorg updates, which the existing packaged nvidia drivers can always support.

sgfxi of course supports all methods, including the nvidia deb installer (sgfxi -d), but I dont' test that method much because it's not nearly as reliable and stable and consistent as using the direct install method (sgfxi, or via smxi), which basically always works, unless you have a bug in your hardware triggered by nvidia driver, which is unrelated to methods used to install the driver.

But I am curious re the alleged smxi 'problems', I believe there may be an education problem with Mint users, who do not grasp quite the concept of rolling release, yet enthusiastically adopt it in LMDE anyway, then so of course encounter a variety of problems where really there is just a fairly normal flow of how this stuff works in real life. But since I get essentially zero feedback in any meaningful way from Mint users, I can't worry too much about it. All issues reported and followed through on my forums WILL BE SOLVED. If you fail to report an issue, then I'm not psychic, sad to say, but my first guess is its error in understanding more than anything else, or incomplete upgrades, or using kernel metapackages instead of more stable methods, like installing only kernels you need. I for example, only rarely update my kernels, and if there are bugs in a series, I just skip it until it works. This box, for example, exposes some serious nfs failures in 2.6.38 and 39, so I am using 2.6.37 until those get resolved upstream in kernel land. That's something I've done many times, and it's why I NEVER use kernel metapackages, ie, the ones that pull in new kernels with every upgrade.

Code: Select all

inxi -b
System:    Host yawn Kernel 2.6.37-2.dmz.1-liquorix-686 i686 (32 bit) Desktop KDE 3.5.10 Distro sidux-20070102-d:1
Machine:   Mobo ASRock model A770DE+ Bios American Megatrends version P1.70 date 09/07/2010
CPU:       Dual core AMD Athlon 64 X2 5000+ (-MCP-) clocked at 1000.00 MHz
Graphics:  Card: nVidia G86 [GeForce 8400 GS] X.Org 1.10.2 driver nvidia Resolution 2560x1024@50.0hz
           GLX Renderer GeForce 8400 GS/PCI/SSE2/3DNOW! GLX Version 3.3.0 NVIDIA 280.04
Network:   Card Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller driver r8169
Drives:    HDD Total Size: 810.2GB (71.0% used)
Info:      Processes 206 Uptime 5:09 Memory 1280.0/3166.7MB Client Shell inxi 1.7.13


[rhodry]

@h2-1 wrote:

Over about 5, 6 years, I've found the most rock solid stable way to run nvidia is via sgfxi/smxi, which simply means using the direct downloaded current real nvidia drivers from nvidia themselves.

All other methods tend to fail at some point.

Hallelujah!! I'm really glad you are here h2-1. I have run a multitude of Debian/Debian-based distros over the years; stable through to experimental, Crunchbang, Mepis, Aptosid and others and now LMDE . On every one of those systems I use your smxi/sgfxi for Nvidia driver installs and it has NEVER failed me; including in this current case of messy updates. The most I have ever had to do is run sgfxi twice on some hardware to enable the nouveau blacklisting. Read first, then act, and even that is always straight forward.

In this case, I have no 'mesa' packages to worry about because I went sgfxi straight after install so all i can do is shake my head at the amount of trouble people are reporting when I ran the same updates and just kept sailing on. I totally agree with your comments regarding 'meta' packages and rolling releases. Personally, I think that a real part of the problem here is that so many users simply do not understand the true nature of a rolling release, and, in particular, one that is based on a 'hybrid' of sorts in Debian Testing. My hope is that Clem decides to go the PCLinuxOS route of self-packaging with Debian base? We'll see?

I would suggest to all these folk landing at tty prompts and no gui that it is a perfect opportunity to remove the 'meta' nvidia stuff, mesa stuff, etc and simply install smxi/sgfxi and live happily ever after!

cheers, rhodry.

[craig10x]

Yes...i think the problem is that many assume "rolling release" means you just install constant updates and everything runs about as smooth as it would in Mint main edition...but in reality they soon realize that it isn't like that at all...

If only Clem could do it in the pclinuxos way, where the updates are very carefully controlled and only released to the mint users when they are safe to install...but i don't know if that is possible or not...

[gazza]

I'm curious what type of 'nothing but trouble' you experienced with smxi, and in what areas.

Hi h2, mid febuary I came to #smxi with an issue of my nvidia 8200 not installing (flashing cursor of death), I honestly don't know how many installs I did testing it out and giving you feedback, http://techpatterns.com/forums/post-7213.html#7213 being one of em. You did say you finally tracked the issue down, after about a week or two, I tried again, same issue, so I gave up, heard other people on #linuxmint-debian had issues as well with nvidia , so decided it wasn't worth the hassel as a 'fresh install' of lmde atm is a real pain in the butt, I've 3gig of updates now. (can't wait for a respin)..

I didn't come back to #smxi with the issue because at the time you were very frustrated with lmde, and I didn't want to hassel you "again and again". I found manually installing worked and was fine (esspecially after I learned dkms). I guess it's a case of first impressions stick. Of late I've heard people say smxi a lot so assume the buggs were finally ironed out, but at this point I really don't want to test it again as there is a minor chance it will totally break my system like the driver for the 5200 does. I'll wait till a respin before I go for a full install etc, see how smxi works for me then....

Other than that, I've had no real issue with lmde at all. It's my every day system, sure I know it's testing and living on the edge, but I'm happy with it and do regular upgrades. I'm no wizard, and half the stuff in these forums and irc are beyond me, but I get to learn a little more each time I have an issue, 11years in linux means nothing really as everything is constantly changing

[h2-1]

gazza, I believe those issues were caused by some mint configuration with nouveau blacklisting or something, I also recall that we finally got those fixed, took a while to track down the causes since they didn't really appear anywhere else than Mint, at least not initially. I think ikey was key in getting that finally figured out.

So I was wrong above when I said I got zero feedback from Mint, I did get some in that case, and I think we managed to collect enough user data to finally pin it down. There's still some glitchy mint behaviors that require something I can't reproduce, ie, a failed first install of nvidia that then works on second install the first time you install the real nvidia driver.

Those were nouveau related, some change in nouveau blacklisting if I remember right required redoing the blacklist logic to make it even more comprehensive, but that was done a long time ago.

nouveau has caused me more pain than any other non free driver ever, except maybe fglrx, in sgfxi, it takes an absurd amount of code to do what should be trivially easy, remove a simple module from the kernel, and the syntaxes required to do what should be simple ae fairly absurd. dkms is another mess, fine until it fails, fine for frozen pool stuff.

I could go back to svn history and check that, but the timing seems about what I remember to have been. It took quite a few sets of bug reports before we finally figured out roughly what was going on.

Just to be clear, this was NOT an smxi issue, that's what I was curious about, it was a sgfxi issue triggered by more extreme requirements to get that nouveau gunk out of the kernel out, ie, the stuff was working, then something changed in kernel/nouveau land, then sgfxi had to be adapted, again, at a big time loss, to handle that change.

[gazza]

Just a note to anyone who read my above post on thanking zerozero , I did the above, it went into gui, no driver, so I thought that was the way it would be , I was wrong, after a full day I shut down and saw a quick 'glimmer' of the nvidia logo, thinking this strange I rebooted, and what should I find, the driver is active again. I should have rebooted before I opened my mouth and complained that the driver didn't activate. I edited my above post to take that reference out and say 'reboot' to get an active driver for anyone who stumbles across it as a fix for the same issue...

Also, h2, when we do get a respin, I will use sgfxi to install the driver now that I know the issues are fixed (as best they can be with the way nouvea constantly changes). If I do have any issues I know where #smxi is and how to post a proper bug report

[GeneC]

I'm curious what type of 'nothing but trouble' you experienced with smxi, and in what areas.

Just to give you some feedback.
My problem was not with your scripts as such.
It was hardware related. Specifically my monitor. (Dell G2210).
For some reason I have not been able to pin down yet (I find NO settings anywhere).
When in tty prompt mode when running your scripts, the monitor "auto dims" after about 15 seconds making text near impossible to read, thus prompting input errors on my part. Its hard to make the right choice when you cant read the instructions
The same dimming happens on boot with the scolling text before "x" starts.

Didn't mean to imply something was wrong with your scripts. I did mention it was specific to me, and that I thought it was a good tool. I will try it again, if I can figure out how to disable the "autodim" feature. Though I must say the "dkms" method has never failed for me. Keep up the good work.

[thomasmc]

I rebooted, and what should I find, the driver is active again.

Yeah, the ATI driver even warns you after install to reboot your system, as it might become unstable.
The flip side of that coin is that you might not realize that an update has borked your video until you reboot.
And with Linux, I don't typically reboot all that often (With Windows it was maybe twice a day...)

[kruijf]

I dont know it any more, i try to find out why my flash whit youtube is giving some lag.
I tried a fiew things but nothing is working for me, i also installed mint-flasplugin10.2.
Who can help me whit this?

[Gerd50]

Thank's for all the helpful postings above, but there is one little thing with smxi - i don't understand how to use it. I tried it
once, but gave up. Reason, my small english knowledge. Technical instructions in english are often hard to understand, if
someone like me learned english at school and by listening AFN Bremerhaven about 45 years ago My first PC i've got
when i was 52 and all the english was driving me crazy and still sometimes does.

For LMDE i found a way i can use it. My best little friendly helper is the qt4-fsarchiver. If the system is working well, i create
a snapshot with fsarchiver. It only takes ten minutes. If an update breaks sth important, i playback the snapshot. It takes three
minutes doing that and i have a working system again.

Since i've installed LMDE in October 10 it only happened one time i had to use a fsarchiver snapshot. LMDE is daily in use,
i'm not what some call 'power user' and i never will be. What i have to do is, looking for alternatives if i don't understand
technical instructions. The good thing is, mostly Linux has alternatives for me, that i can understand

I must say, beside LMDE i have Debian Testing and Mint9 on the run. All that on 30 Gb hd space. Without /home's, only
several data partitions that i can use with the three systems. One of the system always is working. When i turned MS the
back, XP was using about 20 Gb hd space. With only 10 Gb more i now have three systems. One of them is always intact.

For all those with little english and technical knowledge, qt4-fsarchiver is an aide making it possible to use a rr distri like
LMDE without being stressed.

I forgot, if it is in the repos. If not:

http://qt4-fsarchiver.sourceforge.net/

[zerozero]

Who can help me whit this?

there's a thread here with some fixes (don't know if you have already looked at it) viewtopic.php?f=141&t=73108

and a few pages behind Clem posted some notes about flash update viewtopic.php?f=141&t=67502&start=540#p435212
don't know if your issue is included in any of these fixes

[clem]

Well, it looks like the recent updates are putting our users to the test LMDE is great but it's not for everybody

Anyway, I thought I'd let you know what's going on at the moment.

- We got a new server in Denver with 1Gbps output and unmetered bandwidth, and we're mirroring the Debian repositories on it at regular intervals (say once a month or so). In the near future, your LMDE system won't point directly to the Debian Testing repositories anymore, but to our own. So it won't be a matter of people getting upgrades as they come along... it will be a matter of them becoming available by packs, on a monthly basis.

- We forked mintupdate and we're writing a Debian version of this tool. We've already successfully removed all the level filtering and we're adding the ability for the tool to detect which "update pack" is installed on your system, which "update pack" is available online, and consequently which warnings and what information you should be aware of.

There's no doubt this is new for everybody and the minute we start using you will come with great ideas for us to improve it... but already, this means that you won't be talking about "some upgrade"... you'll be talking about a particular "update pack" number, and the info you give us, we'll be able to use to warn others, straight from the update manager.

In terms of ETA, it's hard to say, it could be a week or two.

In the meantime, I would recommend to be conservative on the updates you take, especially with Gnome 3 around the corner.

[zerozero]

- We forked mintupdate and we're writing a Debian version of this tool. We've already successfully removed all the level filtering and we're adding the ability for the tool to detect which "update pack" is installed on your system, which "update pack" is available online, and consequently which warnings and what information you should be aware of.

Thanks!

- We got a new server in Denver with 1Gbps output and unmetered bandwidth, and we're mirroring the Debian repositories on it at regular intervals (say once a month or so). In the near future, your LMDE system won't point directly to the Debian Testing repositories anymore, but to our own. So it won't be a matter of people getting upgrades as they come along... it will be a matter of them becoming available by packs, on a monthly basis.

and the questions start will we have a new repo that will replace the debian testing repos? or the mirrored updates will come though the mint repo (with the higher apt priority)?

LMDE is great but it's not for everybody

short and true

[clem]

It will be a new repo. So you'll be using Mint + Debian, or Mint + Debian-Mint

[The Diamond Geezer]

Hello Clem,

Many thanks for the update! This may sound like a dumb question, but in an effort to minimize further breakages and disruptions and ensure optimal compatibility with LMDE, are the new monthly "update packs" going to be somehow tested or QA'ed before they are released to the users?

[clem]

We're hoping to introduce stages... and let people choose at what stage they want to participate.

Debian Testing will feed a first archive on a montly basis, which will then feed a second one a couple of days later. People who point to the first one will be able to give us their feedback which we will add to our own testing to warn people pointing to the second one.

[amina]

Clem, this sounds great

I know that this thread is about breakages but I can't stand a question:
Is this upgrade package system then an "all or nothing" approach? For example, I don't like emesene 2.0, so I uninstalled it, reinstalled the 1.x version and set MintUpdate to ignore emesene updates. Will there be a similar way to exclude specific packages from the new upgrade method?
(Later I also apt-pinned it so it is not upgraded even from terminal. Is this enough to avoid such updates in the future systen as well?)

[clem]

Yes, you'll still be able to ignore updates using the same methods.

[secipolla]

Just an observation regarding libgl1-mesa-glx and the NVIDIA driver.
I don't know exactly what the libgl1-mesa-* packages account for. They seem to me to not be necessary when using the NVIDIA driver and I even suspect that they're not needed even when using the nouveau driver.
libgl1-mesa-glx includes some GL libraries that conflict with the NVIDIA's GL libraries. These are the files /usr/lib/i386-linux-gnu/libGL.so.1 and /usr/lib/i386-linux-gnu/libGL.so.1.2
The NVIDIA driver deletes those files so the system detects the NVIDIA GL libraries (/usr/lib/libGL.la, /usr/lib/libGL.so, /usr/lib/libGL.so.1 and /usr/lib/libGL.so.275.09.07 - for the 275.09.07 driver).
When libgl1-mesa-glx is updated, it reinstalls its own GL libraries and then the GLX support breaks for people that use the NVIDIA driver. To get the GLX support back, all is needed is to delete /usr/lib/i386-linux-gnu/libGL.so.1 and /usr/lib/i386-linux-gnu/libGL.so.1.2 and then run ldconfig as root so the system detects the NVIDIA GL libraries again.