[CentOS] 7.2 kernel panic on boot

Phelps, Matthew mphelps at cfa.harvard.edu
Thu Dec 3 21:24:24 UTC 2015


On Thu, Dec 3, 2015 at 3:53 PM, Leon Fauster <leonfauster at googlemail.com>
wrote:

> Am 03.12.2015 um 19:35 schrieb Greg Lindahl <lindahl at pbm.com>:
> > On Thu, Dec 03, 2015 at 12:26:08PM +0100, Leon Fauster wrote:
> >>>
> >>> And the way I'd figure this out from the centos website is?
> >
> > Note that I was asking about the release numbering, not the release
> > itself. And while you're suggesting where I could find out more or
> > take part in the discussion, Leon, keep in mind that I've been using
> > CentOS since it was first released, I am on the -dev mailing list, and
> > I was a part of the discussion of this new numbering scheme when it
> > was first mooted - my recommendation was that if you did it at all,
> > you should use names like 7.2.1511. And I recall that the decision
> > was to use release names like 7.2.1511.
> >
> > If we can get the version numbering scheme right here:
> >
> > [lindahl at rd ~]$ more /etc/centos-release
> > CentOS Linux release 7.1.1503 (Core)
> >
> > {note the .1. in the name}
> >
> > Why can't we get it right on the website, and the mailing list?  Why
> > should I have to look at the bottom of a webpage to figure out the
> > mapping, when we could all say 7.2.1511?
>
>
> Just to be clear; I'm also motivated like you to understand
> why this was voted by the CentOS Board. I am just responding
> in a dialectic way to get more insights.
>
>
>
> > What is bad about being clear?
>
>
> Following implies that the context of argumentation is: "CentOS Project".
>
>   So, what should be clear here - the minor version - but is it relevant?
>   Relevancy means to be able to make a distinction between other minor
>   versions. For example: in the virtual case of 7.1.1512 vs. 7.2.1511 it
>   would be essential to use a minor number as infix and that is exactly the
>   point that was discussed on "centos-devel" -> there are no other
> "branches"
>   of CentOS 7 - only the current one. That makes a minor number obsolete.
>
> For a broader context:
>
> To answer the questions about the coherence to upstream:
>
>   The point in time of the question leads directly to the answer e.g.
>   1. Whats the minor version number (y)? [asked today (2015-12-03)]
>   2. Current RHEL is 7.2 released 2015-11-19
>   3. Current CentOS is 7 (1503) implies 2015-03
>   4. Minor numbers are in the set of natural numbers
>   5. 2015-03 < 2015-11-19 => 7.y < 7.2 => 7.1
>
>   The most workload on this 5 steps was at step 2 (search for the
> availability date).
>
> My very personal conclusion: Upstream should use a timestamp :-) and
> continue to using
> minor version numbers because of the AUS, ELS and EUS branches. CentOS
> does not need minor
> version numbers.
>
>
>
> --
> LF
>
>
CentOS should do whatever RHEL/Upstream does.

Period.


Why the change now? It really does matter, a lot, to those of us who need
to do compliance testing/security checks, etc. all based on "version"
number. I know there is no such thing in practice because of all the
non-sequential updates that happen, but there's a shit-ton of work that we
have to do for each new release, and we have depended in the past on the
versions matching the RHEL ones. Now, they don't, and that's wrong.


It seems like a minor thing, but in real-world practice it is most
definitely not.

-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu



More information about the CentOS mailing list