Venting

[jlehtone]

Your own mistakes are the most annoying ones. At least mine are. :-(

And mine is laziness. I saw a kernel security update for a distro* reputed for stability.
Well, it is passing down good stuff from prominent upstream vendor*.

Security is important. But what a good admin should do, is to check for known bugs and
issues, both from vendor, and upstream. Did I? No. Was there something relevant
for my setup? Oh yes. A morning on "what did broke this?" that simple reading would
have avoided.


[*] Not specified to protect the innocent, nor I say "2.6.18-164" or "nfs4 server". It was
not their fault. Sort of. :roll:

[pjwelsh]

You don't expect this kinda of issue with a security update in the kernel, sadly :-(
https://bugzilla.redhat.com/show_bug.cgi?id=524520

[toracat]

Yes, this particular one is not CentOS' fault. The upstream vendor is even talking about fixing it on the [b]next[/b] point release unless they hear from customers through their official support channel. Several CentOS users (including couple of CentOS devs) rushed and filed such requests. We will see if they agree to do the fix within the 5.4 release.

[jlehtone]

"Quality" is, according to some sources, lack of variation. If so, then "good quality"
means that every item is just as good as the rest. And QA makes sure that they are so.
For example, the count of bugs must remain constant through every release in order
to "maintain quality". Decreasing bugs would imply loss of "established quality".

That is obviously not relevant in our world. :pint:


For this particular issue, upstream vendor bugzilla does link to a patch, and CentOS "plus"
repository naturally offers one too, if I'm not mistaken. Actually, I'm more confident to
find nicely patched kernel (for multiple issues) from centosplus than from the upstream.
Another dangerous assumption? :-)

[toracat]

[quote]
jlehtone wrote:

For this particular issue, upstream vendor bugzilla does link to a patch, and CentOS "plus"
repository naturally offers one too, if I'm not mistaken. Actually, I'm more confident to
find nicely patched kernel (for multiple issues) from centosplus than from the upstream.
Another dangerous assumption? :-)[/quote]
[b]Not at all[/b] ! Of course, I am [i]highly[/i] biased. :-D

-toracat (current centosplus kernel maintainer)

[pschaff]

Biases aside [b]toracat[/b], I don't see a -164 kernel in centosplus yet. What patch exists for the aforementioned https://bugzilla.redhat.com/show_bug.cgi?id=524520 in centosplus?

[toracat]

[quote]
pschaff wrote:
Biases aside [b]toracat[/b], I don't see a -164 kernel in centosplus yet. What patch exists for the aforementioned https://bugzilla.redhat.com/show_bug.cgi?id=524520 in centosplus?[/quote]
Johnny Hughes has taken the -164 centosplus kernel hostage. The patched kernel for bugzilla 524520 (formerly 522163 ) is only in my testing directory. If this is not in the next upstream kernel update, we can include it in the cplus kernel.

Or maybe it should be done for the -164 kernel now? Hmmm.

[pschaff]

Sure seem to be more than the usual number of problem reports for -164. I don't know if there's any sentiment to violate the bug-for-bug binary compatibility with upstream in [base]/[updates], but a [centosplus] offering certainly gets my vote. Haven't thought through the implications, but might we consider offering both bug-fix-patched (no extra modules) and added-functionality (extra modules plus patches) CentOSplus kernels?

[toracat]

Regarding the bug-fix-patched (no extra modules) kernels, Johnny Hughes used to offer those here:

http://people.centos.org/hughesjr/kernel/5/

Each bug applied is identified by the upstream bugzilla number. He has not been doing this for a while now. I need to ask him what his plan is.

[pschaff]

I remember using those years ago - had forgotten about that route. Looks like no updates there for quite a while, and something more "official" with at least yum metadata would be nice. I'd still vote for centosplus it it could be worked out.