aww, this is causing me lots system unstabilities (any kernel call @ one particular drive causes unkillable process deadlock)... I'd hate to waste the time of recompiling locally what will be out in a few days. Would it be possible to push the patch any sooner, even if directly atop what's out now? If I'd have known I'd have stayed on the previous kernel (an older tumbleweed release from at least a month ago). I didn't see a stable kernel regression like this coming though. On 05/12/2011 02:07 PM, Greg KH wrote:

On Thu, May 12, 2011 at 07:58:39AM -0700, Greg KH wrote:

...

On Thu, May 12, 2011 at 12:55:03AM -0700, Jason Newton wrote:

...

This patch needs applied to be applied

https://patchwork.kernel.org/patch/769162/

else it dies in ata_eh_set_lpm, at least on my desktop. Ah, nice to know, as it is queued for stable, tumbleweed will get it soon, but I'll look at adding it sooner if it will be taking a while. Now added to the kernel git tree, will show up in a tumbleweed updated kernel in a few days.

thanks,

greg k-h

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 05/13/2011 08:44 AM, Jiri Slaby wrote:

On 05/13/2011 05:41 AM, Jason Newton wrote:

...

aww, this is causing me lots system unstabilities (any kernel call @ one particular drive causes unkillable process deadlock)... I'd hate to waste the time of recompiling locally what will be out in a few days. Would it be possible to push the patch any sooner, even if directly atop what's out now?

The kernel with the patch is currently building in k:stable. So if you want, take it from: http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.4/

The correct link is: http://download.opensuse.org/repositories/Kernel:/stable/standard/

after it builds.

Sad is, that there are other 30000 packages in the build queue, so it may take a while.

thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 5/13/2011 5:11 PM, Greg KH wrote:

On Thu, May 12, 2011 at 08:41:41PM -0700, Jason Newton wrote:

...

aww, this is causing me lots system unstabilities (any kernel call @ one particular drive causes unkillable process deadlock)... I'd hate to waste the time of recompiling locally what will be out in a few days. Would it be possible to push the patch any sooner, even if directly atop what's out now?

If I'd have known I'd have stayed on the previous kernel (an older tumbleweed release from at least a month ago). I didn't see a stable kernel regression like this coming though.

Regressions happen no matter how hard we try, it's just a fact of life, sorry.

If you use tumbleweed, or heck, any release, I STRONGLY suggest that you keep at least one kernel installed on your system that you know works properly. zypper can easily handle multiple kernels, use that if you want, or keep one around by hand.

thanks,

greg k-h

That's not good enough. The repo should actually provide a way to manually choose older known-working builds. The updates repo does not delete the packages it updates. One is always the newest that gets installed by default, but every incremental package is still there also. For kotd , especially stable , I think that is really called for. Maybe in head you can say "hey, this is head" just like Factory is Factory and is always turning over. But push an untested kernel out, blowing away the current one irrecoverably, into a "stable" repo ? That is very unexpected, and now that I do know that it is allowed to happen, only _now_ I'll know, the hard way, to make my own one-way mirror of the repo so that in my copy the old packages don't go away. Merely enabling multiple kernels in zypper is not a good enough answer. If the current packages are bad in the repo, even if I have an old one still installed currently and don't uninstall it, I'm still screwed because I can't install any of the matching packages I might need, nor can I re-install the version I currently have, say if I uninstalled it or broke it, like say I had the source package, and some proprietary crapola 3rd party driver scribbled all over the source and I need to start over *cough*Dialogic/Eicon T1 cards*cough*. Nor can I install new machines and bring them to parity with the other machines already installed. I have to go back to the updates kernel, or wait until the kotd is good again, neither is always simple to accept. It's not the end of the world but it's not good. I think if k:stable isn't going to preserve at least some old packages (even if not every single rebuild, pick whatever milestones you like) then people should be warned against even using it. Might as well use head. The whole k:stable/standard vs distro-specific repos is still a mess too. I think it's a plain broken scheme but I'm still testing things and getting my thoughts and facts in order about that. With the old repos, as time goes on, and as the kernel inevitably breaks compatibility with the older distros, no problem, the old version-specific repos just stopped progressing at some point and for an old distro you'd still have a kernel that was far newer than the updates kernel for that distro, and only the other distros would continue to track the current kernel. Now what you have is for a given distro, the kernel gets higher, higher, higher over time, and then explodes and disappears completely one day and you only have whatever is in updates which could be 2 years old and be bad for you for any number of reasons. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, May 14, 2011 at 10:42 AM, Greg KH wrote:

...

The updates repo does not delete the packages it updates. One is always the newest that gets installed by default, but every incremental package is still there also.

I don't think you understand the amount of disk space that would take up over time...

I don't know how to address the space issue, but I think this is a significant issue. I'm new to rolling updates, but if one of the eventual targets of Tumbleweed is servers, there needs to be way to roll a consistent set of updates to first a test server, and then to production servers. I don't think Tumbleweed has any design goal yet to support that use case. I don't know if the soon to be released OBS 1.3 will make doing so easier or not. For now, is it safe to say Tumbleweed doesn't address consistent rollout needs as required by production systems and therefore is not a good choice for that use? If so, I can update the wiki page. Thanks Greg (not KH) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, May 14, 2011 at 10:41 PM, jdd wrote:

Le 14/05/2011 18:48, Greg Freemyer a écrit :

...

I'm new to rolling updates, but if one of the eventual targets of Tumbleweed is servers, there needs to be way to roll a consistent set of updates to first a test server, and then to production servers.

I wouldn't use Tumblweed for servers, but evergreen (but may be I'm wrong)

but I read in a previous post from Greg KH "it's enough to uncomment one line"

please, Greg KH, can you make clear what line you think of (I have some ideas, but you certainly know better than I do)

http://www.lmgtfy.com/?q=installing+multiple+kernels+on+openSUSE

My idea to test server (servers as remote with no physical access ones) is to use the grub feature to have a one shot boot (boots one menu.lst entry but use the default one next time) - I simply reboot the server if the test go wrong

jdd

-- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 14/05/2011 19:53, jdd a écrit : ttp://www.lmgtfy.com/?q=installing+multiple+kernels+on+openSUSE

at least a line to uncomment in /etc/zypp/zypp.conf

http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-08/msg01310.html

best here: http://lists.opensuse.org/opensuse/2010-08/msg01313.html jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, May 14, 2011 at 08:10:01PM -0400, Greg Freemyer wrote:

On Sat, May 14, 2011 at 1:11 PM, jdd wrote:

...

Le 14/05/2011 18:48, Greg Freemyer a écrit :

...

I'm new to rolling updates, but if one of the eventual targets of Tumbleweed is servers, there needs to be way to roll a consistent set of updates to first a test server, and then to production servers.

I wouldn't use Tumblweed for servers, but evergreen (but may be I'm wrong)

...

From my understanding, a lot of people run Arch on servers because they prefer a slow continuous upgrade process instead of a big upgrade every year or two.

I don't know if the long term goal of Tumbleweed is to support that model or not.

Yes it is, and I use it that way, but again, using Arch you don't get a "consistant set of updates" either, just like Gentoo or Debian unstable. Although you can set up a test and roll-out method that creates this, just like you have to do for the other distros, it's not "built in" unlike the "enterprise" distros that are offered by SUSE and Red Hat. Again, different models for different usages and people. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, May 14, 2011 at 11:32:50PM -0400, Greg Freemyer wrote:

Back to the small office type user.

If a small office with 3 or 4 servers is eventually a Tumbleweed target, then a way to accomplish a consistent rollout to a test box, and then a week or two later rollout to "production" boxes should at a minimum be well documented.

It would be nice to document that, but that's not something that I have the time to do.

I think David Rankin on the users list has written up some procedures for how to pull a set of rpms to a local repo server, and then have it serve those rpms out to other local boxes. I recall the instructions seeming fairly complex, but at least they looked reproducible.

If and when Tumbleweed has matured enough to target that use case, I hope those instructions or similar can be incorporated into the Tumbleweed doc set.

What would be the level at which you would feel that Tumbleweed has "matured" to that state? Remember, it's constantly changing, just like Arch and Gentoo and Debian are. So if you feel you can handle such an ever-changing environment in your server situation, then great, move to it. But that's something that every user is going to have to decide, nothing that we can do here will help with that. good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, May 14, 2011 at 4:44 PM, Greg KH wrote:

On Sat, May 14, 2011 at 12:48:37PM -0400, Greg Freemyer wrote:

...

On Sat, May 14, 2011 at 10:42 AM, Greg KH wrote:

...

...

The updates repo does not delete the packages it updates. One is always the newest that gets installed by default, but every incremental package is still there also.

I don't think you understand the amount of disk space that would take up over time...

I don't know how to address the space issue, but I think this is a significant issue.

I'm new to rolling updates, but if one of the eventual targets of Tumbleweed is servers, there needs to be way to roll a consistent set of updates to first a test server, and then to production servers.

Um, the idea of a "constantly rolling update" is in contrast to a "consistent set of updates", they are not the same thing, nor are they supposed to be.  They both fit a different need.

...

I don't think Tumbleweed has any design goal yet to support that use case.

That is explicitly NOT the design goal of Tumbleweed at this point in time.

...

I don't know if the soon to be released OBS 1.3 will make doing so easier or not.

I don't know either.

...

For now, is it safe to say Tumbleweed doesn't address consistent rollout needs as required by production systems and therefore is not a good choice for that use?  If so, I can update the wiki page.

Tumbleweed also doesn't support making me a jelly sandwich every day for lunch, should that be on the wiki as well?  :)

Seriously, saying all the things that Tumblweed isn't really isn't helpful, saying what it is, is.

thanks,

greg k-h

I disagree only because I have seen Arch and its rolling upgrade model recommended for some server use. I've never done that, but I can easily see a end-user familiar with Arch and using it for servers to assume the same target goal for Tumbleweed. I believe I've even seen that expectation mentioned on the opensuse end user mailing list. So I'm not saying we need to document Tumbleweed's jelly making skills because there is no expectation it makes sandwiches. But where the expectation is reasonable, I think the wiki should point out that the expectation is not going to be met. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org