Update pack 6 chat/questions/support thread

[BucolicBuffalo]

Has nothing to do with arrogance. The very first post in thread says this is for the Update Pack 6. To post in this thread with questions. But that goes against the guideline recommendations that says to post a new thread for a new problem. That of course generated some confusion on my part and wasted time. I admit, after reading the guidelines that I could have provided more info. I will try to remember to check the guidelines in the future and start my own threads.

[ddurdle]

Has nothing to do with arrogance. The very first post in thread says this is for the Update Pack 6. To post in this thread with questions. But that goes against the guideline recommendations that says to post a new thread for a new problem. That of course generated some confusion on my part and wasted time. I admit, after reading the guidelines that I could have provided more info. I will try to remember to check the guidelines in the future and start my own threads.

I would help you but I wouldn't know how.

Perhaps start by posting the list of filesystems (df).

[grraf]

Regarding wine & nvidia i'm pretty much stuck but i also found a viable working alternative : the gallium 0.4 glx render from mesa seems to work rather well for wine's d3d rendering needs , while there is little hope this will soon equal nvidia original driver's performance its decent enough for me to use as replacement and still bee able enjoy all LMDE &wine powered gaming have to offer so far.
Not sure exactly what other people's needs are when it comes to theyr graphics card so what is ok/enough for me may be insufficient for others, (i'm good with only linux games plus those old school rpg's found on GOG , otherwise my only other gpu intensive activity would be watching some movies/clips on various sites ) i guess in the end u will just have test out the gallium 0.4 glx render and see for yr self if its good enough for yr needs
PS: if u intend to test it out and are unsure how to get rid of the nvidia driver, pls do ask(it tends to be a rather messy affair(as u will need to(as simple as i know) use software manger to get rid of nvidia stuff, purge the nvidia kernel module and edit xorg.conf....) me or others how to do it (quite likely there are easier/more elegant ways to dispose of the nvidia driver then what i described)

[zerozero]

(quite likely there are easier/more elegant ways to dispose of the nvidia driver then what i described)

ddm can do that now with ease

[on4aa]

I posted my UP6 regression problem with /etc/fstab and CIFS here:
http://forums.linuxmint.com/viewtopic.php?f=198&p=664256#p664256

[EliasYFGM]

Seems i wasn't wrong, d3d wine games do work after installing libxvmc1:i386 and libgl1-nvidia-glx:i386 but the nasty consequence is the removal of xserver-xorg-video-nvidia; and on next reboot u only go as far as loading mdm after wich it complains about xserver-xorg not being set ok....
Naturally upon doing a sudo apt-get install xserver-xorg-video-nvidia the system reverts to its previous state(libxvmc1:i386 and libgl1-nvidia-glx:i386 get unisntalled and replaced with theyr amd64 equivalents)
What i'm asking now : is there a way for ibxvmc1 , libgl1-nvidia-glx to coexist on the system in i386 and amd64 form ?? (multiarch would be the word here ??) and if possible would smb be kind enough to give a step by step how to ??

Same problem here and would be itnerested in a solution

Yeah, I'm having the same problem as well. I hope they release a fix for that soon, because I've never had a problem like that before (been running Linux Mint Debian for about 1.5 years now and everything was fine).

I was using Wine 1.5.5 but changed to 1.4.1 (stable) to see if that would fix something, but no luck.

[zerozero]

Seems i wasn't wrong, d3d wine games do work after installing libxvmc1:i386 and libgl1-nvidia-glx:i386 but the nasty consequence is the removal of xserver-xorg-video-nvidia; and on next reboot u only go as far as loading mdm after wich it complains about xserver-xorg not being set ok....
Naturally upon doing a sudo apt-get install xserver-xorg-video-nvidia the system reverts to its previous state(libxvmc1:i386 and libgl1-nvidia-glx:i386 get unisntalled and replaced with theyr amd64 equivalents)
What i'm asking now : is there a way for ibxvmc1 , libgl1-nvidia-glx to coexist on the system in i386 and amd64 form ?? (multiarch would be the word here ??) and if possible would smb be kind enough to give a step by step how to ??

Same problem here and would be itnerested in a solution

Yeah, I'm having the same problem as well. I hope they release a fix for that soon, because I've never had a problem like that before (been running Linux Mint Debian for about 1.5 years now and everything was fine).

I was using Wine 1.5.5 but changed to 1.4.1 (stable) to see if that would fix something, but no luck.

searching for answers to another issue i found this http://www.mentby.com/Group/debian-user/multiarch-please-do-not-force-users-to-change-a-running-system.html that at some point refers to this bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499 (as you can see it's a much deeper problem: libxvmc is not multiarch atm)

in that bug report you can find (3rd party) pkgs multiarch aware (use at your own risk)

[ddurdle]

I upgraded another 64bit machine yesterday, this one really doesn't use anything 32bit so there were no issues. I never encountered the same issue that I had on the 32bit system. I've still got to find time to investigate the priorly mentioned 32bit system issue.

This leads me to my next question -- will there ever be a stable LMDE repository that we can use? I'm risk averse, I like to try the update packs outs system-by-system from lowest risk system to highest risk system to ensure there are no issues. The last thing I want to do is blindly update a machine I rely on heavily to suddenly suffer downtime while I either work out a compatibility issue or restore the system.

It would be nice to have "previous" repository around to give people the ability to install new packages etc before being forced to upgrade to the latest update pack. I want to install a new piece of software on my high risk machine today, but I can't because I need to update it to UP6 before I have access to the libraries the package needs. Any suggestions?

[cwwgateway]

I upgraded another 64bit machine yesterday, this one really doesn't use anything 32bit so there were no issues. I never encountered the same issue that I had on the 32bit system. I've still got to find time to investigate the priorly mentioned 32bit system issue.

This leads me to my next question -- will there ever be a stable LMDE repository that we can use? I'm risk averse, I like to try the update packs outs system-by-system from lowest risk system to highest risk system to ensure there are no issues. The last thing I want to do is blindly update a machine I rely on heavily to suddenly suffer downtime while I either work out a compatibility issue or restore the system.

It would be nice to have "previous" repository around to give people the ability to install new packages etc before being forced to upgrade to the latest update pack. I want to install a new piece of software on my high risk machine today, but I can't because I need to update it to UP6 before I have access to the libraries the package needs. Any suggestions?

I'm not sure how to answer this question because I'm not sure if I understand it correctly, but I'm going to try . I think that you want to have a repo that is stable, but allows you to upgrade certain packages (I may be wrong, though). I think there are already a few ways to get this currently, although I don't think they'll work on stock LMDE. If you look at SolusOS (which I have so many mixed feelings about, although they aren't important in this case) or a distro that uses Debian Stable with backports, then you see that it is possible to maintain a stable base (in this case using Debian Stable), but upgrade specific packages to newer versions. SolusOS (which relies heavily on Debian Backports and their own backports), CrunchBang (which offers a backport-less ISO and an ISO with lots of backports enabled), Snow Linux, SalineOS, etc. use backports. Some distros use normal Debian Backports, which I find to be the most reliable, and some have their own backports. By default on Debian, Backports are disabled, and when you add them you have to specifically "ask" to upgrade each package with an apt-get -t squeeze-backports install <package>. That would give you a stable base for everything except a few packages that you upgrade. However, only a few packages are backported (iceweasel/icedove, libreoffice, etc) and as a Debian Stable release grows old (there's only one every 2 +/- years), it becomes harder to backport packages. Other distros provide newer/more backports (I think SolusOS has the most), but this can lead to some compatibility issues. These distros often upgrade *all* of the packages that have been backported, and certain backported xorg updates can break things (usually not badly, but it's still not good). The other problem is that pure Debian Backports won't provide a newer kernel (although SolusOS, for example, comes with kernel 3.3) - Squeeze comes with kernel 2.6.32, and wheezy will come with 3.2-4 (3.7 is the newest kernel).

It is conceivable that Mint does something similar to this with LMDE, but I don't think they have the resources to do that while putting most of their effort towards the main edition. If LMDE was the main edition, then I believe that Mint could make a Debian Stable based release, a Stable with Backports release, and possibly an UP or Testing release. I suppose they could make sort of an LTS update pack that gets backports, but I don't know how feasible that is (simply basing off of Debian Stable would probably work better). I guess the problem is that if you have a fixed release (such as Debian Stable), packages get old and it is hard to backport packages without updating libraries and a bunch of other things, which can decrease the stability of it. If you upgrade the libraries (even occasionally, like with update packs), then you are at least partially rolling, in which case you are bound to have some (even if they are only minor) stability issues.

They could start treating update packs like releases (UP 4 could have been LMDE 4, then UP 5 being LMDE 5, and UP 6 being LMDE 6), with them backporting packages to each release (or maybe doing an LTS LMDE release), but it wouldn't be rolling anymore and that would take a lot of work. I'm not sure if Mint has the resources to do this, even if they were to switch to Debian. Ubuntu has never been particularly good at backporting packages to its previous releases, and they have a lot more resources than Mint does. There are PPAs, but that's developed from the community.

I hope I've at least sort of answered your question, and I hope I didn't sound like I was saying that it isn't possible .

Note: I've tried to make sure that whenever I'm referring to Debian Stable the "s" is capitalized and whenever I'm referring to something that is stable the "s" is lower-case.

[zerozero]

ddurdle,
you summed up in that post the reasons why you shouldn't be using lmde (or debian testing or ofc sid);

we love to have all the possible users aboard but for your user-case i honestly believe that a LTS kind of release (like mint maya) is the answer.

cww,
debian backports has updated kernels (3.2 atm) but there's one big issue with backports (better said with the way some people/distros use them): they forget/overlook the first recommendation:

Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!

It is therefore recommended to select single backported packages that fit your needs, and not use all available backports.

http://backports-master.debian.org/Instructions/
ofc the highlights are mine

[ddurdle]

ddurdle,
you summed up in that post the reasons why you shouldn't be using lmde (or debian testing or ofc sid);

we love to have all the possible users aboard but for your user-case i honestly believe that a LTS kind of release (like mint maya) is the answer.

I've always preferred Debian over Ubuntu, albeit the ladder is based on the former. When I tried Mint (forget which version it was, either 12 or 13?) last November (with gnome3 at the time), it was constant instability with gnome crashes 2-3 times. There was a thread about it, that I was also contributing to for finding the cause of the gnome3 crashes that seemed to inflict many users. After a month and half with no resolution in sight, I tossed Ubuntu once and for all.

I find stuff works better out the of the box with Ubuntu than Debian, but with using Debian, I find it forces you to learn more about Linux, and thus become more aware of things. I've had to get a lot of things working with Debian that worked out-of-the-box with Ubuntu.

Perhaps I should look at a stable Debian instead.

[ddurdle]

I'm not sure how to answer this question because I'm not sure if I understand it correctly, but I'm going to try . I think that you want to have a repo that is stable, but allows you to upgrade certain packages (I may be wrong, though). I think there are already a few ways to get this currently, although I don't think they'll work on stock LMDE. If you look at SolusOS (which I have so many mixed feelings about, although they aren't important in this case) or a distro that uses Debian Stable with backports, then you see that it is possible to maintain a stable base (in this case using Debian Stable), but upgrade specific packages to newer versions. SolusOS (which relies heavily on Debian Backports and their own backports), CrunchBang (which offers a backport-less ISO and an ISO with lots of backports enabled), Snow Linux, SalineOS, etc. use backports. Some distros use normal Debian Backports, which I find to be the most reliable, and some have their own backports. By default on Debian, Backports are disabled, and when you add them you have to specifically "ask" to upgrade each package with an apt-get -t squeeze-backports install <package>. That would give you a stable base for everything except a few packages that you upgrade. However, only a few packages are backported (iceweasel/icedove, libreoffice, etc) and as a Debian Stable release grows old (there's only one every 2 +/- years), it becomes harder to backport packages. Other distros provide newer/more backports (I think SolusOS has the most), but this can lead to some compatibility issues. These distros often upgrade *all* of the packages that have been backported, and certain backported xorg updates can break things (usually not badly, but it's still not good). The other problem is that pure Debian Backports won't provide a newer kernel (although SolusOS, for example, comes with kernel 3.3) - Squeeze comes with kernel 2.6.32, and wheezy will come with 3.2-4 (3.7 is the newest kernel).

It is conceivable that Mint does something similar to this with LMDE, but I don't think they have the resources to do that while putting most of their effort towards the main edition. If LMDE was the main edition, then I believe that Mint could make a Debian Stable based release, a Stable with Backports release, and possibly an UP or Testing release. I suppose they could make sort of an LTS update pack that gets backports, but I don't know how feasible that is (simply basing off of Debian Stable would probably work better). I guess the problem is that if you have a fixed release (such as Debian Stable), packages get old and it is hard to backport packages without updating libraries and a bunch of other things, which can decrease the stability of it. If you upgrade the libraries (even occasionally, like with update packs), then you are at least partially rolling, in which case you are bound to have some (even if they are only minor) stability issues.

They could start treating update packs like releases (UP 4 could have been LMDE 4, then UP 5 being LMDE 5, and UP 6 being LMDE 6), with them backporting packages to each release (or maybe doing an LTS LMDE release), but it wouldn't be rolling anymore and that would take a lot of work. I'm not sure if Mint has the resources to do this, even if they were to switch to Debian. Ubuntu has never been particularly good at backporting packages to its previous releases, and they have a lot more resources than Mint does. There are PPAs, but that's developed from the community.

I hope I've at least sort of answered your question, and I hope I didn't sound like I was saying that it isn't possible .

Note: I've tried to make sure that whenever I'm referring to Debian Stable the "s" is capitalized and whenever I'm referring to something that is stable the "s" is lower-case.

I don't know if when you make commentary on LMDE becoming the main Mint, if that is you supporting that or otherwise, but I always believed Mint would be better if it was directly based off Debian (aka LMDE) instead of Ubuntu.

Thanks for the insights on backports. I'm looking further into this for at least the critical-stable systems I have. Either that, or create my own mirror of an UP-release that I want to ensure is accessible until I'm able to upgrade all my systems over to the latest.

I generally like being "up-to-date" and prefer the Debian testing model on most of my machines versus when I used Ubuntu and found myself rarely upgrading and then would result in every machine running different versions, etc, which was a maintenance nightmare.

Regarding kernels, I'm using liquorix instead of the one provided by LMDE. So I have a range of 3.4-3.7 installed on each system, and use the latest version on each machine (as possible). Just some hardware has problems with some newer kernels that I'm waiting to be worked out, so I keep 3.4 kicking around.

[cwwgateway]

cww,
debian backports has updated kernels (3.2 atm) but there's one big issue with backports (better said with the way some people/distros use them): they forget/overlook the first recommendation:

Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!

It is therefore recommended to select single backported packages that fit your needs, and not use all available backports.

http://backports-master.debian.org/Instructions/
ofc the highlights are mine

Yeah, the stability (or possible lack thereof) of backports is often overlooked, and backports can sometimes be used to death . IIRC libreoffice broke sometime around the 3.5 upgrade in Debian, which was when SolusOS started maintaining their own libreoffice backport. I didn't realized that kernels were backported (I assumed distros that used backports added newer kernels manually). I think it's handled well in Debian where backports have a lower pin-priority and you manually select stuff. I usually use iceweasel, icedove, and libreoffice backports only (I'm pretty happy with the other software being stable and slightly out of date, with the possible exception of gimp 2.6.x and xfce 4.6.x).

ddurdle,
you summed up in that post the reasons why you shouldn't be using lmde (or debian testing or ofc sid);

we love to have all the possible users aboard but for your user-case i honestly believe that a LTS kind of release (like mint maya) is the answer.

I've always preferred Debian over Ubuntu, albeit the ladder is based on the former. When I tried Mint (forget which version it was, either 12 or 13?) last November (with gnome3 at the time), it was constant instability with gnome crashes 2-3 times. There was a thread about it, that I was also contributing to for finding the cause of the gnome3 crashes that seemed to inflict many users. After a month and half with no resolution in sight, I tossed Ubuntu once and for all.

I find stuff works better out the of the box with Ubuntu than Debian, but with using Debian, I find it forces you to learn more about Linux, and thus become more aware of things. I've had to get a lot of things working with Debian that worked out-of-the-box with Ubuntu.

Perhaps I should look at a stable Debian instead.

I actually agree with zerozero. I don't know what DE you are using now, but I'm pretty sure you'll have the same version on Mint Maya. With PPAs you get backport-like abilities, and overall newer software. However, Debian Stable is IMHO the most stable linux distro (with the possible exception of Red Hat and things like that). Adding backports can be helpful for a few apps, but again it could decrease stability. I'd suggest trying all of those options out and seeing which is the best for you.

I don't know if when you make commentary on LMDE becoming the main Mint, if that is you supporting that or otherwise, but I always believed Mint would be better if it was directly based off Debian (aka LMDE) instead of Ubuntu.

Thanks for the insights on backports. I'm looking further into this for at least the critical-stable systems I have. Either that, or create my own mirror of an UP-release that I want to ensure is accessible until I'm able to upgrade all my systems over to the latest.

I generally like being "up-to-date" and prefer the Debian testing model on most of my machines versus when I used Ubuntu and found myself rarely upgrading and then would result in every machine running different versions, etc, which was a maintenance nightmare.

Regarding kernels, I'm using liquorix instead of the one provided by LMDE. So I have a range of 3.4-3.7 installed on each system, and use the latest version on each machine (as possible). Just some hardware has problems with some newer kernels that I'm waiting to be worked out, so I keep 3.4 kicking around.

I think that for many users, Ubuntu is a better base because there is more software for it, PPAs, it is a more newbie friendly distro, etc. I think if Mint put all of its resources into Debian, then it could rival the Ubuntu based edition, but the main edition is already there. The benefit of Ubuntu-based Mint is that it gets all of the perks of Ubuntu - steam (which requires pulling packages from experimental and lots of tweaking to install on Debian), netflix, PPAs, lightworks when it comes out, etc.

Again, using a few backports is definitely a good option, but zerozero is very correct that they could cause problems. I'd suggest testing to make sure a backport works in a VM or non-critical system, and, if it does, then you can use it on your critical systems all you want. Personally, I find using a few backports is much more stable than using a Debian Testing (or UP) based distro.

I agree that updating Ubuntu sucks. Every Debian Stable release is supported for about 3 years (squeeze will lose support in February or March 2013), and they provide an upgrade path that *supposedly* works, although I've never tried using it, so YMMV. I have two debian testing installs, one debian sid install, and two debian stable w/ a few backports installs (these are various distros - LMDE, Crunchbang, Debian proper, etc).

Liquorix is probably my favorite kerenel, and I use it on my sid install. I'd use it on my testing installs, but it messes up my apt pinning. On those I just use the regular Debian kernels, which integrate well. Unfortunately, you can't use liquorix with Debian Stable due to gcc requirments. I haven't tried the aptosid or siduction kernels on anything, but they are supposedly good for sid (I've heard a lot of good things about the siduction kernel). Just to give you an idea of up-to-date-ness, Stable has 2.6.32, backports have 3.2, testing has 3.2-4, sid has 3.2-4, aptosid was the first to update to 3.7, then siduction, and then liquorix.

[cwsnyder]

My 2 cents worth: On stability versus up-to-date software, I keep a copy of Debian, usually either stable or within a few months of going stable after a feature freeze, because I have had personal experience with X and the audio system breaking on me and it taking months to get the bugs worked out, usually after multiple regular releases, on Ubuntu. I ran Ubuntu from 7.10 to 9.10. 8.04 installed pulse audio, and it wasn't until 9.10 that my audio worked like it had in 7.10. At that time I started dual-booting with Debian 5.0 Lenny to have a working system while I fought with Ubuntu. In Ubuntu 10.04 with Unity, neither fallback nor Unity with Compiz worked with my computer at the time, forcing the move to what has worked for me since, which is LMDE. At first I went with GNOME 2, then when GNOME 2 was dropped, I had switched to Xfce. My Debian Wheezy present install still works well with Xfce, and if LMDE finally crashes and burns, I will probably still keep Debian around.

I learn how to fix my system to work with the present software, then they change it, and I am left with a broken system. I am not going back to Windows, but Windows XP was my stable system before I installed Debian. Microsoft, going back to the days of MS-DOS 2.0 had a reputation for shipping broken x.0 software which needed x.1 updates to fulfill the promise of the upgrade, even on the good upgrades, and I am not including DOS 4.x, Win95, WinME/2000, WinVista, or Win8 as 'good' upgrades. All of them struggled even after their point or 'Service Pack' upgrades. I have seriously considered running CentOS or a BSD derivative as a desktop, although even when 'new' CentOS applications make Debian packages look new! At least the kernels are now getting updated to the point that my hardware is supported.

[TomANJ]

Only had 1 issue going from UP5 to UP6 concerning "mountnfs" see link below. The delay at boot up went away, but i still had to modify /etc/network/if-up.d/mountnfs. Is this something that will be addressed in the re-spin? Also, congratulations to the LMDE team. I ran the original release of LMDE until the the switch to the gnome 3 base. UP6 seems very fast, stable, and Cinnamon has matured nicely. I have a new SSD on the way waiting for the re-spin.

viewtopic.php?f=198&t=112981&p=635703&hilit=mountnfs#p635703