7 comments

[ 1.5 ms ] story [ 19.9 ms ] thread
Title is misleading since that bug only happens on some systems and will not introduce any remote execution. This bug also has a Priority of 'high' and not 'critical', since you could actually just go back to the latest kernel.

Edit: I have 10 systems on this kernel and all of them are working.

It also seems, from a few minutes research, that the fix is available with an OS point release update, the only thing being held back is the z-stream (fix without point release update).

Disclaimer: worked at Red Hat more than a decade ago.

That could be six months or a year from now. I don't like the idea of having to put "exclude=kernel*" in my yum.conf.
Changed title, but still, I'd call "crashes on boot" a critical bug.

Interest: I have an affected system, and discovered the crash when I upgraded to CentOS 7-1511. Until this gets fixed, I'm stuck on the last working kernel, though I could use the mainline kernel from ELRepo. Otherwise, it's "hello, Ubuntu Server."

The first comment starts with z-Stream releases are not reproduced by CentOS - you need to buy those

If it's in the kernel doesn't it have to be GPLv2? So only one person has to buy it, and they can share it with CentOS. Does CentOS have a special deal with RedHat that they won't do this?

> If it's in the kernel doesn't it have to be GPLv2?

That's a tricky question. As far I know Red Hat provides all the sources for their free software (that's the reason why CentOS can exist), but the binary things are a tricky question.

I think you could share your recipe (the source code), but retain the sauce (the configuration and compiler that produces the binary and the binary itself) and still comply GPL, it's a grey area.

Why CentOS wont share the Red Hat binaries? Well you won't want to bite the hand that feed you.