On Sun, Dec 06, 2015 at 09:22:15PM -0500, Jonathan Billings wrote:> On Sun, Dec 06, 2015 at 06:35:58PM +0000, Timothy Murphy wrote: > > Always Learning wrote: > > > > > I always admire Johnny's prose, passion for Centos and his calm approach > > > to everything. > > > > Agreed. > > But two possibly OT and probably ignorant queries: > > > > 1. I am running a standard Centos 32-bit system on my home servers. > > I keep them up-to-date, but have not re-booted for several months. > > I see from /etc/centos-release that I am running 7.1. > > If I re-booted would this become 7.2? > > > > 2. If so, is this kernel panic a widespread phenomenon? > > You're running the 32-bit AltArch build of CentOS? > > The /etc/centos-release is owned by the centos-release package, and > the contents will be updated when you update that pacakge. A reboot > won't change that. In the default x86_64 release, I think that you'd > need to pull updates from the CR repo to get the 7.2.1511 packages, > still.And just look at the confusion -- because the website almost never mentions 7.1.1053 or 7.2.1511, it can be really hard to understand this discussion -- one person using "7.1" and "7.2" and the other using "7.2.1511". Good thing the 2nd person didn't use "7 (1511)", like the website does. Oh, wait: CentOS, love it or leave it.
On 12/06/2015 10:11 PM, Greg Lindahl wrote:> On Sun, Dec 06, 2015 at 09:22:15PM -0500, Jonathan Billings wrote: >> On Sun, Dec 06, 2015 at 06:35:58PM +0000, Timothy Murphy wrote: >>> Always Learning wrote: >>> >>>> I always admire Johnny's prose, passion for Centos and his calm approach >>>> to everything. >>> >>> Agreed. >>> But two possibly OT and probably ignorant queries: >>> >>> 1. I am running a standard Centos 32-bit system on my home servers. >>> I keep them up-to-date, but have not re-booted for several months. >>> I see from /etc/centos-release that I am running 7.1. >>> If I re-booted would this become 7.2? >>> >>> 2. If so, is this kernel panic a widespread phenomenon? >> >> You're running the 32-bit AltArch build of CentOS? >> >> The /etc/centos-release is owned by the centos-release package, and >> the contents will be updated when you update that pacakge. A reboot >> won't change that. In the default x86_64 release, I think that you'd >> need to pull updates from the CR repo to get the 7.2.1511 packages, >> still. > > And just look at the confusion -- because the website almost never > mentions 7.1.1053 or 7.2.1511, it can be really hard to understand > this discussion -- one person using "7.1" and "7.2" and the other > using "7.2.1511". Good thing the 2nd person didn't use "7 (1511)", > like the website does. > > Oh, wait: CentOS, love it or leave it.Correct. In fact, I would prefer you leave. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20151207/3e4469a0/attachment-0001.sig>
On Dec 7, 2015 07:45, "Johnny Hughes" <johnny at centos.org> wrote:> > On 12/06/2015 10:11 PM, Greg Lindahl wrote: > > On Sun, Dec 06, 2015 at 09:22:15PM -0500, Jonathan Billings wrote: > >> On Sun, Dec 06, 2015 at 06:35:58PM +0000, Timothy Murphy wrote: > >>> Always Learning wrote: > >>> > >>>> I always admire Johnny's prose, passion for Centos and his calmapproach> >>>> to everything. > >>> > >>> Agreed. > >>> But two possibly OT and probably ignorant queries: > >>> > >>> 1. I am running a standard Centos 32-bit system on my home servers. > >>> I keep them up-to-date, but have not re-booted for several months. > >>> I see from /etc/centos-release that I am running 7.1. > >>> If I re-booted would this become 7.2? > >>> > >>> 2. If so, is this kernel panic a widespread phenomenon? > >> > >> You're running the 32-bit AltArch build of CentOS? > >> > >> The /etc/centos-release is owned by the centos-release package, and > >> the contents will be updated when you update that pacakge. A reboot > >> won't change that. In the default x86_64 release, I think that you'd > >> need to pull updates from the CR repo to get the 7.2.1511 packages, > >> still. > > > > And just look at the confusion -- because the website almost never > > mentions 7.1.1053 or 7.2.1511, it can be really hard to understand > > this discussion -- one person using "7.1" and "7.2" and the other > > using "7.2.1511". Good thing the 2nd person didn't use "7 (1511)", > > like the website does. > > > > Oh, wait: CentOS, love it or leave it. > > Correct. > > In fact, I would prefer you leave. > > >Really? This is what we're dealing with now? OK. I will recommend we move away from CentOS. Good job. _______________________________________________> CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
On 07/12/15 04:11, Greg Lindahl wrote:> On Sun, Dec 06, 2015 at 09:22:15PM -0500, Jonathan Billings wrote: >> On Sun, Dec 06, 2015 at 06:35:58PM +0000, Timothy Murphy wrote: >>> Always Learning wrote: >>> >>>> I always admire Johnny's prose, passion for Centos and his calm approach >>>> to everything. >>> >>> Agreed. >>> But two possibly OT and probably ignorant queries: >>> >>> 1. I am running a standard Centos 32-bit system on my home servers. >>> I keep them up-to-date, but have not re-booted for several months. >>> I see from /etc/centos-release that I am running 7.1. >>> If I re-booted would this become 7.2? >>> >>> 2. If so, is this kernel panic a widespread phenomenon? >> >> You're running the 32-bit AltArch build of CentOS? >> >> The /etc/centos-release is owned by the centos-release package, and >> the contents will be updated when you update that pacakge. A reboot >> won't change that. In the default x86_64 release, I think that you'd >> need to pull updates from the CR repo to get the 7.2.1511 packages, >> still. > > And just look at the confusion -- because the website almost never > mentions 7.1.1053 or 7.2.1511, it can be really hard to understand > this discussion -- one person using "7.1" and "7.2" and the other > using "7.2.1511". Good thing the 2nd person didn't use "7 (1511)", > like the website does.Note that there is a /etc/centos-release-upstream as well that identifies what ver of the upstream we are currently tracking.> Oh, wait: CentOS, love it or leave it.I hope its not that drastic! There are multiple issues and fallouts etc here, start from the fact that the point number isnt really much other than a datestamp, to who and how it gets used and for what purpose etc. But the thing that bothers me most is that the reason as to why we are doing this and how its implemented isnt clear to people on this thread. eg. when we were doing x.y, RHEL wasent. They were on a X release, and all the other point in time data was communicated outside of that scope ( eg in EL3 / 4 etc ). I believe being pragmatic around this, and delivering value into areas that needed it most is good thing for us and the userbase at large - however, if we are breaking systems for existing setup's then we should address that. I took onboard all the feedback from 7 release time and I believe the system we have in place now should work for most people ( no one has been able to demonstrate a problem space in the distro as such ). If the issue is around communication and how we export the metadata / mindset - I totally take on board that we've had serious issues in that space. Even the fact that there is a CR/ repo isnt something most people understand or even know about, its something we should fix. Greg's pointed out the website version reporting, and its a great point - however, note that we are already working on fixing that side of things by bringing all Download specific info into 1 place, and doing this on the wiki ( wiki.centos.org/Download ) - we are moving all version specific content away from the website; the net result being that the website becomes about the project, and the wiki becomes the defacto source for all things content ( linux distro, sig's content, user help etc ). This is also primarily driven by the fact that we've struggled to keep the site updated and relevant, whereas the wiki with its much larger user base and contributor base has far better churn. So lets workout what the tangible issues are, and then work on resolving those. I will end by saying that we have more than a few million monthly instances out there now, in container space, in cloud space, in developer instances - and all of those people have hugely benefited from the new visioning. I certainly dont want you to leave! regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
On Mon, Dec 7, 2015 at 4:45 AM, Johnny Hughes <johnny at centos.org> wrote:> On 12/06/2015 10:11 PM, Greg Lindahl wrote:(bit snip)>> Oh, wait: CentOS, love it or leave it. > > Correct. > > In fact, I would prefer you leave.No, I would prefer ALL of you leave. All of you who are not addressing the OP's issue should leave the thread. Just start a new thread, not here. Enough is enough (/me saying in the same tone as President Obama referring to the gun violence in the US). Now back to the topic... This bug report: https://bugs.centos.org/view.php?id=9860 and its upstream (RH) reference: https://bugzilla.redhat.com/show_bug.cgi?id=1285235 might possibly be related to the kernel panic the original poster reported. There is a workaround that may be worth a try: Boot with the kernel parameter : initcall_blacklist=clocksource_done_booting Akemi
On 12/07/2015 06:31 AM, Karanbir Singh wrote:> On 07/12/15 04:11, Greg Lindahl wrote: >> Oh, wait: CentOS, love it or leave it. > I hope its not that drastic!As a member of the user community, it's hard to see it any other way. I want to be fair to everyone, so I'll acknowledge that Greg was making an ass of himself. He said so, himself. I also think that the question of what release the problem occurred on is irrelevant. The relevant question is the version of the kernel package, not the centos-release package. But that aside, I think that Greg was right in that the version notation used in the wiki (https://wiki.centos.org/Download) is unnecessarily inconsistent with older releases. The rpm version for centos-release is 7-1.1503. The version reflected in /etc/centos-release is 7.1.1503. But text on the wiki omits a portion of that version number. Greg was consistent and (in my opinion) clear that he was suggesting that the wiki be consistent with the numbering used elsewhere. Johnny's response ignored that suggestion completely, and defended the version numbering scheme, which was not in question. And in his very first response, he said, "CentOS-7 Base OS is still there, it is free for anyone to use ... If you don't want to use it.. That is your choice." Can you see why that would be interpreted as "love it or leave it?" It has been my impression for a long time that the CentOS developers are reluctant to engage the community in contributing to the project, and this is a fairly good example of why that impression endures.> There are multiple issues and fallouts etc here, start from the fact > that the point number isnt really much other than a datestampArguably, that's all any version number is. Isn't it? But your response, like Johnny's ignores what Greg actually suggested: that the wiki use a version number consistent with the rpm version number and the content of /etc/centos-release.> Greg's pointed out the website version reporting, and its a great point > - however, note that we are already working on fixing that side of > things by bringing all Download specific info into 1 place, and doing > this on the wiki ( wiki.centos.org/Download )Yes, the wiki is where the problem is. That's the same URL that Greg mentioned originally.> This is also primarily driven by the fact that we've > struggled to keep the site updated and relevant, whereas the wiki with > its much larger user base and contributor base has far better churn.I would interpret that as an invitation to participate in the project, but I created an account on the wiki and don't seem to be able to edit anything.