Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah......
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot!
TIA
On 09/16/2011 09:52 PM, Thomas Dukes wrote:
Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah......
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot!
TIA
Is Red Hat Enterprise Linux listed as a supported operating system? If so, download the trial version and see if you have the same problem. If/when you do, call Lenovo and open a support ticket.
On Fri, 2011-09-16 at 21:52 -0400, Thomas Dukes wrote:
Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah......
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot!
---- Xeon processor? sounds old - might not run 64 bit. If you boot the 32 bit, what do you get for processor when you run dmidecode? (note - there's quite a bit of data there - only want the process info.
Craig
On 09/16/2011 10:36 PM, Craig White wrote:
On Fri, 2011-09-16 at 21:52 -0400, Thomas Dukes wrote:
Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah......
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot!
Xeon processor? sounds old - might not run 64 bit. If you boot the 32 bit, what do you get for processor when you run dmidecode? (note - there's quite a bit of data there - only want the process info.
Craig
That model is new and is 64bit.
Email Lenovo support and ask about RedHat 6.0 support for the TS130
The Lenovo TS130 is not listed on Redhat 6.0 system Certified list.
https://hardware.redhat.com/list.cgi?product=Red+Hat+Hardware+Certification&...
There are some notes on other think servers, maybe that would help
On 9/16/2011 7:36 PM, Craig White wrote:
On Fri, 2011-09-16 at 21:52 -0400, Thomas Dukes wrote:
Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah......
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot!
Xeon processor? sounds old - might not run 64 bit. If you boot the 32 bit, what do you get for processor when you run dmidecode? (note - there's quite a bit of data there - only want the process info.
Craig
Hi,
On 09/17/2011 02:52 AM, Thomas Dukes wrote:
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Can you expand a bit on the 'wont boot', actually expand quite a lot. Run the installer in debug mode and turn off all rhgb, quiet etc and see what point and how far the system gets.
Also, some manufacturers have been known to turn off 64 bit ( lm ) support in BIOS when the device is sold with a 32bit Windows. Make sure that its not the case.
Finally, you mentioned 5.7 but didnt say what your test results there were. Does the 5.7/x86_64 installer boot for you ? if not, how far does it get ? is that about the same point as the 6.0 installer ?
- KB
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: Saturday, September 17, 2011 5:34 AM To: CentOS mailing list Subject: Re: [CentOS] This doesn't make sense
Hi,
On 09/17/2011 02:52 AM, Thomas Dukes wrote:
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit
6.1, but will
boot 32 bit CentOS 6.0.
Can you expand a bit on the 'wont boot', actually expand quite a lot. Run the installer in debug mode and turn off all rhgb, quiet etc and see what point and how far the system gets.
I get the 'Welcome' screen, I make the selection to install or upgrade, get to 'Loading vmlinuz..', then it hangs.
Maybe the DVDs are bad. Can a 32 bit machine create a 64 bit install disc?
Also, some manufacturers have been known to turn off 64 bit ( lm ) support in BIOS when the device is sold with a 32bit Windows. Make sure that its not the case.
I looked through the BIOS but didn't see anything about 64 bit
Finally, you mentioned 5.7 but didnt say what your test results there were. Does the 5.7/x86_64 installer boot for you ? if not, how far does it get ? is that about the same point as the 6.0 installer ?
I'm running 5.7 32 bit on 32 bit machines.
Thanks,
Eddie
On Sat, 17 Sep 2011, Thomas Dukes wrote:
I get the 'Welcome' screen, I make the selection to install or upgrade, get to 'Loading vmlinuz..', then it hangs.
Maybe the DVDs are bad. Can a 32 bit machine create a 64 bit install disc?
I had that with 32 bit installation. Try to boot in plain ascii text mode, and see what the error message is please?
Mine was faulty burn media.
AFAIK an iso image is an iso image, whatever OS you use to burn it to CD/DVD.
HTH
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On 09/17/2011 12:25 PM, Thomas Dukes wrote:
I get the 'Welcome' screen, I make the selection to install or upgrade, get to 'Loading vmlinuz..', then it hangs.
Edit that line, add 'debug' and 'text' to the boot line, see how far it gets. Try to list the last 25 odd lines of the boot messages before you assume its hanging.
Also, can you quantify what you consider 'hanging'. Was it stuck for 1 min, 15 min, 30 min.
If the kernel does not report something along the lines of 'this machine does not support long mode', its highly probable that the cpu/bios are fine.
Maybe the DVDs are bad. Can a 32 bit machine create a 64 bit install disc?
yes, 32bit host should be able to burn x86_64 media just fine. did you sha sum check the isos files before trying to do the burn ? That would be a good indicator about bad or incomplete data.
Finally, you mentioned 5.7 but didnt say what your test results there were. Does the 5.7/x86_64 installer boot for you ? if not, how far does it get ? is that about the same point as the 6.0 installer ?
I'm running 5.7 32 bit on 32 bit machines.
Well, since we are hoping to help you with the ts130, it would only really be relevant if you were to try the 5.7/x86_64 installer on this machine. If nothing else, as a data point to compare and test the 64bit'ness of this machine.
As a second data point, you could grab the c6/x86_64/livecd and see how you get along with booting that.
- KB
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: Saturday, September 17, 2011 1:35 PM To: CentOS mailing list Subject: Re: [CentOS] This doesn't make sense
On 09/17/2011 12:25 PM, Thomas Dukes wrote:
I get the 'Welcome' screen, I make the selection to install or upgrade, get to 'Loading vmlinuz..', then it hangs.
Edit that line, add 'debug' and 'text' to the boot line, see how far it gets. Try to list the last 25 odd lines of the boot messages before you assume its hanging.
Also, can you quantify what you consider 'hanging'. Was it stuck for 1 min, 15 min, 30 min.
If the kernel does not report something along the lines of 'this machine does not support long mode', its highly probable that the cpu/bios are fine.
Maybe the DVDs are bad. Can a 32 bit machine create a 64
bit install disc?
yes, 32bit host should be able to burn x86_64 media just fine. did you sha sum check the isos files before trying to do the burn ? That would be a good indicator about bad or incomplete data.
Finally, you mentioned 5.7 but didnt say what your test
results there
were. Does the 5.7/x86_64 installer boot for you ? if not, how far does it get ? is that about the same point as the 6.0 installer ?
I'm running 5.7 32 bit on 32 bit machines.
Well, since we are hoping to help you with the ts130, it would only really be relevant if you were to try the 5.7/x86_64 installer on this machine. If nothing else, as a data point to compare and test the 64bit'ness of this machine.
As a second data point, you could grab the c6/x86_64/livecd and see how you get along with booting that.
- KB
SUCCESS!! Finally!! Not sure if the DVD drive in my 5.7 machine is bad or what, but I have a trash can full of 'coasters'. Thank goodness I had some DVD+RWs!!
Doing updates now. Unbelievable how fast this machine is (well, as compared to the CIRCA 2003 Netvistas I'm using). Did an install in under 15 mins. Never did see options for partitioning.
I do miss the old startup where you can see if services start or fail.
Thanks, everyone, for all the help!!
I'm sure I'll have more questions later as 6.0 is much different than previous versions. :-)
Eddie
Thomas Dukes tdukes@sc.rr.com wrote:
I do miss the old startup where you can see if services start or fail.
Edit /etc/grub.conf. Comment out the splashimage and hiddenmenu lines. Remove the 'rhgb' and 'quiet' options from the kernel argument list. On your next reboot you should see something useful once more.
If you only want to see it once in a while, I think hitting 'escape' during the boot sequence will show that screen.
Devin
On Sat, 2011-09-17 at 19:20 -0400, Thomas Dukes wrote:
I'm sure I'll have more questions later as 6.0 is much different than previous versions. :-)
---- bear in mind... CentOS 6.0 is almost a year old without security updates CentOS 6.1 (when it finally gets released) will likely be about 6 months old without security updates
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
Craig
On Sep 17, 2011, at 7:49 PM, Craig White craigwhite@azapple.com wrote:
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
I'm sorry I don't follow you here?
I'm fairly certain that 6.1 will include both 6.1 security/bug updates AND security/bug updates that have been released up to the beginning of the 6.1 release cycle, minus several that where released during the C6.1 release cycle. Security updates and bug fixes are intermingled without being able to distinguish one from the other outside of the RPM history.
It's not the security updates that prevent me from moving to 6.0 right now, but those pesky .0 blues.
-Ross
On Mon, 2011-09-19 at 18:41 -0400, Ross Walker wrote:
On Sep 17, 2011, at 7:49 PM, Craig White craigwhite@azapple.com wrote:
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
I'm sorry I don't follow you here?
I'm fairly certain that 6.1 will include both 6.1 security/bug updates AND security/bug updates that have been released up to the beginning of the 6.1 release cycle, minus several that where released during the C6.1 release cycle. Security updates and bug fixes are intermingled without being able to distinguish one from the other outside of the RPM history.
It's not the security updates that prevent me from moving to 6.0 right now, but those pesky .0 blues.
---- those pesky .0 blues as you call them were clearly there - see other threads about video issues, etc.
I guess the point I was trying to make without being excessively blunt is that the track record of timely releases for CentOS 6.x (any release) and the track record of timely security updates (none) should really cause any one to pause before installing any version of CentOS 6 - even if 6.1 and all of the current security updates were released tomorrow.
Craig
On Sep 19, 2011, at 7:12 PM, Craig White craig.white@ttiltd.com wrote:
On Mon, 2011-09-19 at 18:41 -0400, Ross Walker wrote:
On Sep 17, 2011, at 7:49 PM, Craig White craigwhite@azapple.com wrote:
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
I'm sorry I don't follow you here?
I'm fairly certain that 6.1 will include both 6.1 security/bug updates AND security/bug updates that have been released up to the beginning of the 6.1 release cycle, minus several that where released during the C6.1 release cycle. Security updates and bug fixes are intermingled without being able to distinguish one from the other outside of the RPM history.
It's not the security updates that prevent me from moving to 6.0 right now, but those pesky .0 blues.
those pesky .0 blues as you call them were clearly there - see other threads about video issues, etc.
I guess the point I was trying to make without being excessively blunt is that the track record of timely releases for CentOS 6.x (any release) and the track record of timely security updates (none) should really cause any one to pause before installing any version of CentOS 6 - even if 6.1 and all of the current security updates were released tomorrow.
For those systems that are important enough that I need immediate security updates I buy a RHEL license.
It's those one-off systems behind the firewall that I use CentOS for.
No point in buying an expensive license for an instant messenging server. IPtables is setup to block all non-application traffic, so the risks are low.
More likely to have systems compromised through the applications they run then the system utilities themselves.
-Ross
On Tue, 2011-09-20 at 09:18 -0400, Ross Walker wrote:
On Sep 19, 2011, at 7:12 PM, Craig White craig.white@ttiltd.com wrote:
On Mon, 2011-09-19 at 18:41 -0400, Ross Walker wrote:
On Sep 17, 2011, at 7:49 PM, Craig White craigwhite@azapple.com wrote:
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
I'm sorry I don't follow you here?
I'm fairly certain that 6.1 will include both 6.1 security/bug updates AND security/bug updates that have been released up to the beginning of the 6.1 release cycle, minus several that where released during the C6.1 release cycle. Security updates and bug fixes are intermingled without being able to distinguish one from the other outside of the RPM history.
It's not the security updates that prevent me from moving to 6.0 right now, but those pesky .0 blues.
those pesky .0 blues as you call them were clearly there - see other threads about video issues, etc.
I guess the point I was trying to make without being excessively blunt is that the track record of timely releases for CentOS 6.x (any release) and the track record of timely security updates (none) should really cause any one to pause before installing any version of CentOS 6 - even if 6.1 and all of the current security updates were released tomorrow.
For those systems that are important enough that I need immediate security updates I buy a RHEL license.
It's those one-off systems behind the firewall that I use CentOS for.
No point in buying an expensive license for an instant messenging server. IPtables is setup to block all non-application traffic, so the risks are low.
More likely to have systems compromised through the applications they run then the system utilities themselves.
---- I have been using Red Hat and derivations (WBL, CentOS, Fedora) since 1998 and the last few years it has been harder and harder to justify waiting for everyone to get their act together on a new release.
My current employer and previous employer both stopped using RHEL/CentOS for new installs in favor of Ubuntu and now so have I. It is Linux after all and it is reasonable to use it and it works well.
I don't have to justify the shortcomings of lack of timely security updates.
I don't have to worry about 'long term support'
I have a simpler path for version upgrades (apt-get dist-upgrade)
Their documentation is often quite good.
I certainly appreciate CentOS rescuing me from the drift that was WBL some 6 years ago and they generally delivered in a timely fashion. Version 6 however made it clear to me that it was time to move on. I'm only maintaining the CentOS 5 boxes at this point and at some point, they will be replaced.
Craig
On Sep 21, 2011, at 12:03 AM, Craig White craigwhite@azapple.com wrote:
On Tue, 2011-09-20 at 09:18 -0400, Ross Walker wrote:
On Sep 19, 2011, at 7:12 PM, Craig White craig.white@ttiltd.com wrote:
On Mon, 2011-09-19 at 18:41 -0400, Ross Walker wrote:
On Sep 17, 2011, at 7:49 PM, Craig White craigwhite@azapple.com wrote:
At some point, security updates for 6.1 will be released and then it becomes a matter of deciding to install it based on the evidence that security updates have been non-existent all this time.
I'm sorry I don't follow you here?
I'm fairly certain that 6.1 will include both 6.1 security/bug updates AND security/bug updates that have been released up to the beginning of the 6.1 release cycle, minus several that where released during the C6.1 release cycle. Security updates and bug fixes are intermingled without being able to distinguish one from the other outside of the RPM history.
It's not the security updates that prevent me from moving to 6.0 right now, but those pesky .0 blues.
those pesky .0 blues as you call them were clearly there - see other threads about video issues, etc.
I guess the point I was trying to make without being excessively blunt is that the track record of timely releases for CentOS 6.x (any release) and the track record of timely security updates (none) should really cause any one to pause before installing any version of CentOS 6 - even if 6.1 and all of the current security updates were released tomorrow.
For those systems that are important enough that I need immediate security updates I buy a RHEL license.
It's those one-off systems behind the firewall that I use CentOS for.
No point in buying an expensive license for an instant messenging server. IPtables is setup to block all non-application traffic, so the risks are low.
More likely to have systems compromised through the applications they run then the system utilities themselves.
I have been using Red Hat and derivations (WBL, CentOS, Fedora) since 1998 and the last few years it has been harder and harder to justify waiting for everyone to get their act together on a new release.
My current employer and previous employer both stopped using RHEL/CentOS for new installs in favor of Ubuntu and now so have I. It is Linux after all and it is reasonable to use it and it works well.
That's great! I hope it works well for you.
We moved from Debian to CentOS/RHEL cause the version upgrades kept breaking our environment and always unpredictably.
Unfortunately a version upgrade is often the only way to get a security update on Debian I found.
And if I pin a release I didn't get the security updates!
I don't have to justify the shortcomings of lack of timely security updates.
Yes, with the one big downside that you can't prevent version upgrades without sacrificing security.
I don't have to worry about 'long term support'
Cause there is none.
I have a simpler path for version upgrades (apt-get dist-upgrade)
True dist-upgrade is nice unless third party software causes it to break in the middle. Then, ouch.
Their documentation is often quite good.
I think that can be said about most Linux distros.
I certainly appreciate CentOS rescuing me from the drift that was WBL some 6 years ago and they generally delivered in a timely fashion. Version 6 however made it clear to me that it was time to move on. I'm only maintaining the CentOS 5 boxes at this point and at some point, they will be replaced.
I view the version 6 release as a special case, a perfect storm of version releases; 4.9, 6.0, 5.7, 6.1, and a totally new build process upstream put in place for 6.0.
I think CentOS did the right thing by supporting 4 and 5 first. 6 was brand new and still buggy.
If it were me making the decisions I might have said, use 6.0 to perfect the build environment, but release 6.1 and let all the early adopters whine and jump if they want to.
-Ross
On Sep 21, 2011, at 6:41 AM, Ross Walker wrote:
On Sep 21, 2011, at 12:03 AM, Craig White craigwhite@azapple.com wrote:
I guess the point I was trying to make without being excessively blunt is that the track record of timely releases for CentOS 6.x (any release) and the track record of timely security updates (none) should really cause any one to pause before installing any version of CentOS 6 - even if 6.1 and all of the current security updates were released tomorrow.
For those systems that are important enough that I need immediate security updates I buy a RHEL license.
It's those one-off systems behind the firewall that I use CentOS for.
No point in buying an expensive license for an instant messenging server. IPtables is setup to block all non-application traffic, so the risks are low.
More likely to have systems compromised through the applications they run then the system utilities themselves.
I have been using Red Hat and derivations (WBL, CentOS, Fedora) since 1998 and the last few years it has been harder and harder to justify waiting for everyone to get their act together on a new release.
My current employer and previous employer both stopped using RHEL/CentOS for new installs in favor of Ubuntu and now so have I. It is Linux after all and it is reasonable to use it and it works well.
That's great! I hope it works well for you.
We moved from Debian to CentOS/RHEL cause the version upgrades kept breaking our environment and always unpredictably.
Unfortunately a version upgrade is often the only way to get a security update on Debian I found.
And if I pin a release I didn't get the security updates!
I don't have to justify the shortcomings of lack of timely security updates.
Yes, with the one big downside that you can't prevent version upgrades without sacrificing security.
I don't have to worry about 'long term support'
Cause there is none.
---- Ubuntu != Debian
No LTS? - https://wiki.ubuntu.com/LTS ----
I have a simpler path for version upgrades (apt-get dist-upgrade)
True dist-upgrade is nice unless third party software causes it to break in the middle. Then, ouch.
---- third party software would in that case break regardless of distribution - the rest is just way easier... people who are seeking to in-place upgrade from CentOS 5.x to 6.x would love to have this option. ----
Their documentation is often quite good.
I think that can be said about most Linux distros.
I certainly appreciate CentOS rescuing me from the drift that was WBL some 6 years ago and they generally delivered in a timely fashion. Version 6 however made it clear to me that it was time to move on. I'm only maintaining the CentOS 5 boxes at this point and at some point, they will be replaced.
I view the version 6 release as a special case, a perfect storm of version releases; 4.9, 6.0, 5.7, 6.1, and a totally new build process upstream put in place for 6.0.
I think CentOS did the right thing by supporting 4 and 5 first. 6 was brand new and still buggy.
If it were me making the decisions I might have said, use 6.0 to perfect the build environment, but release 6.1 and let all the early adopters whine and jump if they want to.
---- 'the perfect storm' argument seems sort of ridiculous now almost 11 months after the initial release of RHEL 6.0 and there isn't any nor has then ever been any security updates and you almost get the feeling that RHEL 6.2 will be released by the time CentOS gets 6.1 out the door.
More to the core issue though, there has always been simultaneous versions of RHEL available and given the current trajectory, there always will be. There was a time when a few of the admins of CentOS used to chide users of WBL for not being able to get timely security updates from WBL and indicated that this should be of primary concern for its users... I guess now, not so much.
But it's not really my intent to debate which distro - just wanted to point out that at this point, it requires a leap of faith to install CentOS 6.0 and believe that you will get timely security updates because all evidence is to the contrary.
Craig
On Wed, 2011-09-21 at 09:50 -0700, Craig White wrote:
Ubuntu != Debian
http://www.differencebetween.net/technology/difference-between-ubuntu-vs-deb...
But it's not really my intent to debate which distro - just wanted to point out that at this point, it requires a leap of faith to install CentOS 6.0 and believe that you will get timely security updates because all evidence is to the contrary.
Many Centos installations wishing to upgrade to a newer kernel are remaining on Centos 5.7 until 6.1 emerges.
craig
this is your second troll in two posts.
stop trolling
we are glad for your past life when centos rescued you from whatever.
plus, your past and current usage of centos, migrations to another distro, and opinions are duly noted "again".
like for the hundredth time
another time will not be necessary
please contribute towards the future of CentOS, or move on.
- rh
On Thursday, September 22, 2011 12:50 AM, Craig White wrote:
I don't have to worry about 'long term support'
Cause there is none.
Ubuntu != Debian
No LTS? - https://wiki.ubuntu.com/LTS
For Ubuntu's definition of 'support'. It is in no way comparable to what you can get in previous Centos releases. It is 'comparable' to CEntos 6 - none
On Wed, Sep 21, 2011 at 5:46 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
No LTS? - https://wiki.ubuntu.com/LTS
For Ubuntu's definition of 'support'. It is in no way comparable to what you can get in previous Centos releases. It is 'comparable' to CEntos 6
- none
Errr, what? Apt-get is still happily getting updates, and without any fiddling around with temporary changes to recommended-but-not-default repositories.
On Thursday, September 22, 2011 07:00 AM, Les Mikesell wrote:
On Wed, Sep 21, 2011 at 5:46 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
No LTS? - https://wiki.ubuntu.com/LTS
For Ubuntu's definition of 'support'. It is in no way comparable to what you can get in previous Centos releases. It is 'comparable' to CEntos 6
- none
Errr, what? Apt-get is still happily getting updates, and without any fiddling around with temporary changes to recommended-but-not-default repositories.
Errr, like not fixing functional breakage even though the package is in a current LTS release and even though patches that work were provided by others. eg: Hardy -> pidgin which lost YM capabilities.
Backports like the big ones RH did for C5 do not exist in any Ubuntu release.
So please, do not ever compare Ubuntu LTS with RHEL. Ubuntu LTS is a joke. Of course, currently Centos 6 is a joke too but the landscape is probably going to change very soon.
On 09/21/2011 06:00 PM, Les Mikesell wrote:
On Wed, Sep 21, 2011 at 5:46 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
No LTS? - https://wiki.ubuntu.com/LTS
For Ubuntu's definition of 'support'. It is in no way comparable to what you can get in previous Centos releases. It is 'comparable' to CEntos 6
- none
Errr, what? Apt-get is still happily getting updates, and without any fiddling around with temporary changes to recommended-but-not-default repositories.
Feel free to not use CentOS if it does not meet your needs.
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
If you aren't happy, well then we would recommend "something else" that does make you happy.
Happy is important ... don't go through life unhappy because of an OS.
If Ubuntu makes you happy ... use Ubuntu. If Debian makes you happy use that. Or Scientific Linux, or Open SUSE, or Fedora.
We just want you to be happy Les.
On Thu, Sep 22, 2011 at 7:28 AM, Johnny Hughes mailing-lists@hughesjr.com wrote:
On 09/21/2011 06:00 PM, Les Mikesell wrote:
On Wed, Sep 21, 2011 at 5:46 PM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
No LTS? - https://wiki.ubuntu.com/LTS
For Ubuntu's definition of 'support'. It is in no way comparable to what you can get in previous Centos releases. It is 'comparable' to CEntos 6
- none
Errr, what? Apt-get is still happily getting updates, and without any fiddling around with temporary changes to recommended-but-not-default repositories.
Feel free to not use CentOS if it does not meet your needs.
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
If you aren't happy, well then we would recommend "something else" that does make you happy.
Happy is important ... don't go through life unhappy because of an OS.
If Ubuntu makes you happy ... use Ubuntu. If Debian makes you happy use that. Or Scientific Linux, or Open SUSE, or Fedora.
We just want you to be happy Les.
Regardless of what I do on my own machines, I don't see much opportunity to be happy about the large installed base of Centos not getting security fixes by default as fast as you can process them which is the behavior I always expected from a 'yum update'. I don't understand the argument that making rolling updates the default would change expectations (who ever expected to have to change from the default to get security fixes?), or why you should recommend doing one thing on the mail list yet not make it the default. And the inability to do a kickstart install that will continue to follow the recommended action shows the problem.
Le 22/09/2011 14:28, Johnny Hughes a écrit :
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Which rolling updates ? OK for 5.x, but 5.7 has been released, so this repo is no more useful at this time. But where is the 6.0 CR repo ? When 6.0 was relaesed, last July, it was written in the announcement it will be available within two days. More than two months after, still nothing.
And no 6.1 release yet. So, there are no updates at all for 6.0 since months (6.1 has been released by upstream in May).
Johnny, are you happy with this situation ?
Alain
On 09/23/2011 07:50 AM, Alain Péan wrote:
Le 22/09/2011 14:28, Johnny Hughes a écrit :
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Which rolling updates ? OK for 5.x, but 5.7 has been released, so this repo is no more useful at this time. But where is the 6.0 CR repo ? When 6.0 was relaesed, last July, it was written in the announcement it will be available within two days. More than two months after, still nothing.
And no 6.1 release yet. So, there are no updates at all for 6.0 since months (6.1 has been released by upstream in May).
Johnny, are you happy with this situation ?
Define happy?
I know I am working as fast and as hard as I can to get you updates. So is Karanbir and Tru.
If it is not fast enough, then you will need to do something else.
I can tell you that we are building 6.x stuff for QA now and have been for several weeks.
If we release something that is broken, that is not going to help either.
This stuff does not magically appear, it takes much work.
If our time line does not work for anyone (this includes even me) ... then they should pay for a faster option for that machine.
RHEL has no such delays.
On 9/24/11, Johnny Hughes johnny@centos.org wrote:
I can tell you that we are building 6.x stuff for QA now and have been for several weeks.
I'm not personally unhappy with the devs over the situation since I pretty much didn't plan on any critical C6 installations until 6.1 comes out. So with just one testing/internal-only C6 server, these security issues are largely not a non-concern for me.
So just voicing my 2 bits worth...
As with the 6.0 release, the problem I see is a lack of communication rather than the actual speed of release. The qaweb was a nice step forward in the weeks before 6.0, then right after the 6.0 release, it became for all practical purposes dead.
With the 6.0, I think most of us could understand and accept that it's an entirely new environment. But why is 6.1 taking so much longer, especially the CR which was mentioned to become available within days? More so since it appears that most of the 6.1 packages are built and ready.
It probably would had been OK if there was a follow up that simply stated there were unexpected issues and the CR could not be roll out anytime soon. Otherwise there are some that likely took the dev's word for it that at least critical security updates would be available through CR and so 6.0 is OK to go.
In summary: please make use of the existing QAWeb and Communicate with the Community.
Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes:
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Your "Customers" are not unhappy because they don't like what you do. Your "Customers" are unhappy because they don't know what you do.
The Release and QA Process seems recently to have become a mirracle. There is nothing discussed where your Problems are in getting things done.
So if nobody knows where you are stuck. (Who are the persons anyway hidden in the secret labs?!) Nobody can step up and help out.
Where is this discussion maintained anyway? The Currents process is untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem this fact is not acceptable.
We know that the big boys at RH changed the whole system, but the community accepted that you need time for 6.0 to adept to these changes.
Since then we all thought the issues would have been solved. So what now? What exactly is holding of the release of 6.1 and where can we as a community step in and help?
If you aren't happy, well then we would recommend "something else" that does make you happy.
Or give us the possibility to help becoming happy again. But doing it like Dumbledore in secret regions of the Centos-Hogwards Terrertory is an bad option as it seems.
Happy is important ... don't go through life unhappy because of an OS.
You seem very unhappy at the moment ;)
We just want you to be happy Les.
see my above text.
On 09/23/2011 09:06 AM, Stefan Held wrote:
Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes:
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Your "Customers" are not unhappy because they don't like what you do. Your "Customers" are unhappy because they don't know what you do.
The Release and QA Process seems recently to have become a mirracle. There is nothing discussed where your Problems are in getting things done.
So if nobody knows where you are stuck. (Who are the persons anyway hidden in the secret labs?!) Nobody can step up and help out.
Where is this discussion maintained anyway? The Currents process is untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem this fact is not acceptable.
We know that the big boys at RH changed the whole system, but the community accepted that you need time for 6.0 to adept to these changes.
Since then we all thought the issues would have been solved. So what now? What exactly is holding of the release of 6.1 and where can we as a community step in and help?
If you aren't happy, well then we would recommend "something else" that does make you happy.
Or give us the possibility to help becoming happy again. But doing it like Dumbledore in secret regions of the Centos-Hogwards Terrertory is an bad option as it seems.
Happy is important ... don't go through life unhappy because of an OS.
You seem very unhappy at the moment ;)
We just want you to be happy Les.
see my above text.
Are we going to start this again ... we are doing the best we can and we are building things as we go along to take care of issue when we hit a snag.
There is a whole channel of RPMs that we are not allowed to look at from upstream now. They do not release them on any ISOs and we can't pull things directly off RHN (the only way to get the optional channel) and use it. This is just one of many issues we are having right now.
If you can do it better, then do it.
If you can not do it better, great, neither can we ... if we could have been done by now, we would have been by now.
You can, as always, pay Red Hat for RHEL if you have servers where CentOS does not meet your update requirements.
All that continual whining does is make me want to quit trying to get it out the door.
I am busting my ass here ... I can't do any more than I am. If it is not good enough, then its just not.
<MVNCH> Johnny - blow all this off. The rest of us, posters and lurkers alike, appreciate the work the team's doing.
The *only* thing that I'm interested in, now, is the apache update for the bloody Digitar mess.
mark
On 09/23/2011 06:57 PM, Johnny Hughes wrote:
On 09/23/2011 09:06 AM, Stefan Held wrote:
Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes:
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Your "Customers" are not unhappy because they don't like what you do. Your "Customers" are unhappy because they don't know what you do.
The Release and QA Process seems recently to have become a mirracle. There is nothing discussed where your Problems are in getting things done.
So if nobody knows where you are stuck. (Who are the persons anyway hidden in the secret labs?!) Nobody can step up and help out.
Where is this discussion maintained anyway? The Currents process is untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem this fact is not acceptable.
We know that the big boys at RH changed the whole system, but the community accepted that you need time for 6.0 to adept to these changes.
Since then we all thought the issues would have been solved. So what now? What exactly is holding of the release of 6.1 and where can we as a community step in and help?
If you aren't happy, well then we would recommend "something else" that does make you happy.
Or give us the possibility to help becoming happy again. But doing it like Dumbledore in secret regions of the Centos-Hogwards Terrertory is an bad option as it seems.
Happy is important ... don't go through life unhappy because of an OS.
You seem very unhappy at the moment ;)
We just want you to be happy Les.
see my above text.
Are we going to start this again ... we are doing the best we can and we are building things as we go along to take care of issue when we hit a snag.
There is a whole channel of RPMs that we are not allowed to look at from upstream now. They do not release them on any ISOs and we can't pull things directly off RHN (the only way to get the optional channel) and use it. This is just one of many issues we are having right now.
If you can do it better, then do it.
If you can not do it better, great, neither can we ... if we could have been done by now, we would have been by now.
You can, as always, pay Red Hat for RHEL if you have servers where CentOS does not meet your update requirements.
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems. Have you pondered the moral implications of your statement? Does that mean that the centos project is perfectly fine with knowingly distributing a system that insecure and a danger not only to its users but to others as well?
If as you also seem to suggest the project is so severly understaffed have the people in charge considered shutting down the project? This might be the more responsible option compared to having a lot of unsecured systems out there for long periods of time.
Another issue are the priorities of the project. So apparently you are busy working on 6.0/cr and 6.x which is fine. But there is a major but in the current apache packages with a known and released fix upstream. Why can nobody make a manual build sign it and upload it to vault.centos.org? The fact that apparently people are busy with other stuff but this important update is not considered worthy of anyone's attention is not a problem that can be solved by adding more people but only by the current people making better decisions. Drop whatever 6.x related things you are doing, build the package, put it online, make an announcement and then get back to the regular schedule. If there are issues that prevent this then make an announcement to that effect so that people at least know that they have to take matter in their own hands. Writing such an email would take 5 minutes and there are not technical hurdles preventing you from doing so. This alone would already be a big improvement over the current situation.
Regards, Dennis
On Friday, September 23, 2011 01:29:51 PM Dennis Jacobfeuerborn wrote:
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems.
If the timeliness of security updates is essential/critical you cannt get faster updates than with the upstream paid subscription; it is impossible for a rebuild to release the update before it's posted. So, yeah, if getting the fix the quickest is mission-critical then a subscription to upstream should be purchased. If you can't afford or don't want to pay for a subscription, then you have two options:
1.) Build and test it yourself; 2.) Wait on someone else to build it and test it, where 'someone else' can be an individual or one of the rebuild projects, of which CentOS has the largest distribution with SL next largest.
If you can't wait and can't build it and can't pay for a subscription, then you have two options: 1.) Get your server off the net immediately; 2.) Be insecure until you get the update.
Have you pondered the moral implications of your statement? Does that mean that the centos project is perfectly fine with knowingly distributing a system that insecure and a danger not only to its users but to others as well?
All systems are insecure. Updates are for the known holes; there are and always will be unknown holes.
Have you pondered the moral implications of knowlingly installing insecure software and placing it on the public internet? Oh, wait, it's not a moral issue, since there is no such thing as secure software.
Drop whatever 6.x related things you are doing, build the package, put it online, make an announcement and then get back to the regular schedule.
You are missing some highly important steps. Let me summarize: 1.) Get source RPM(s) for the update from upstream. Upstream's source RPM's for the updates have been known to be delayed, sometimes for quite a while; 2.) Build; 3.) Verify binary compatibility (that is, does it have identical binary dependencies on identical versions of dependencies, verifying that it was built in an identical buildroot as upstream?) (you do realize that a given source RPM can be built to generate very different and potentially incompatible binary RPMs depending upon the contents of the buildroot, right?); 4.) QA the package to make sure other people with various systems can install and use the package, and that it really does fix the problem; 5.) Make sure the resulting repository is 'closed' (that is, in a consistent state so people updating don't get nasty surprises); 6.) Seed the mirror system. A large package update set can take a significant amount of time to propagate; 7.) Announce, and wait on the inevitable bug reports and complaints that it broke users' systems.
Sounds like fun, no?
On Sep 23, 2011, at 10:57 AM, Lamar Owen wrote:
On Friday, September 23, 2011 01:29:51 PM Dennis Jacobfeuerborn wrote:
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems.
If the timeliness of security updates is essential/critical you cannt get faster updates than with the upstream paid subscription; it is impossible for a rebuild to release the update before it's posted. So, yeah, if getting the fix the quickest is mission-critical then a subscription to upstream should be purchased. If you can't afford or don't want to pay for a subscription, then you have two options:
1.) Build and test it yourself; 2.) Wait on someone else to build it and test it, where 'someone else' can be an individual or one of the rebuild projects, of which CentOS has the largest distribution with SL next largest.
If you can't wait and can't build it and can't pay for a subscription, then you have two options: 1.) Get your server off the net immediately; 2.) Be insecure until you get the update.
---- or use something other than a Red Hat derived distribution.
I moved to Ubuntu on my own server, some of my customers servers as has my employer.
The decision(s) were not wholly driven by CentOS' inability to deliver 6.x but also the huge gap of time it took for upstream to get the version out the door and the fact that when it comes down to it, they all are still Linux.
Craig
On Friday, September 23, 2011 02:35:40 PM Craig White wrote:
I moved to Ubuntu on my own server, some of my customers servers as has my employer.
This is not a Ubuntu list.
I have had my share of problems with more than one of the LTS Ubuntu distributions, more than I have had with CentOS. Dist-upgrade has broken more things, in my experience with several versions, than I care to detail.
On Sep 23, 2011, at 12:13 PM, Lamar Owen wrote:
On Friday, September 23, 2011 02:35:40 PM Craig White wrote:
I moved to Ubuntu on my own server, some of my customers servers as has my employer.
This is not a Ubuntu list.
I have had my share of problems with more than one of the LTS Ubuntu distributions, more than I have had with CentOS. Dist-upgrade has broken more things, in my experience with several versions, than I care to detail.
---- it's an option, not a panacea and I'm quite sure that I have continually offered that type of an assessment.
I think that it's reasonable to expect that some things will work better and some things worse when comparing CentOS (or RHEL or ???) with any other distribution.
Craig
On Fri, Sep 23, 2011 at 2:13 PM, Lamar Owen lowen@pari.edu wrote:
On Friday, September 23, 2011 02:35:40 PM Craig White wrote:
I moved to Ubuntu on my own server, some of my customers servers as has my employer.
This is not a Ubuntu list.
It's not a Red Hat list either, yet you didn't complain when someone mentioned the vendor that is the source of our problems.
On Saturday, September 24, 2011 03:13 AM, Lamar Owen wrote:
On Friday, September 23, 2011 02:35:40 PM Craig White wrote:
I moved to Ubuntu on my own server, some of my customers servers as has my employer.
This is not a Ubuntu list.
I have had my share of problems with more than one of the LTS Ubuntu distributions, more than I have had with CentOS. Dist-upgrade has broken more things, in my experience with several versions, than I care to detail.
Ah...you're supposed to use do-release-upgrade and not 'apt dist-upgrade'
Ubuntu ain't Debian. It's something worse and requires uber hacks to get around crap. Them uber hacks are loaded in do-release-upgrade.
Pound Ubuntu properly pal. Giving examples of unsupported processes ain't pounding it properly.
On Saturday, September 24, 2011 06:34:15 AM Christopher Chan wrote:
Ah...you're supposed to use do-release-upgrade and not 'apt dist-upgrade'
If that is what is called by the gui distribution upgrade button, it has done similar things to a few installs I have had to repair.
Ubuntu ain't Debian. It's something worse and requires uber hacks to get around crap. Them uber hacks are loaded in do-release-upgrade.
Been there, broke that.
Pound Ubuntu properly pal. Giving examples of unsupported processes ain't pounding it properly.
TMTOWTDI.
If it's not supported it shouldn't be enabled and easily (ab)used. This is part of the reason you have to add a boot argument to get CentOS to do a version upgrade; it's known to not work properly, and thus is semi-hidden.
On Monday, September 26, 2011 06:40 PM, Lamar Owen wrote:
If it's not supported it shouldn't be enabled and easily (ab)used. This is part of the reason you have to add a boot argument to get CentOS to do a version upgrade; it's known to not work properly, and thus is semi-hidden.
Now that's pounding Ubuntu properly. But it will fall on deaf ears. Complain on the list and they will tell you that it is YOUR fault because you did not read the documentation or bother to google how to dist-upgrade before doing 'apt-get dist-upgrade'. With such devs, where's the 'community' or who is the 'community'?
If that's what some folks here want over too tired to communicate devs, be our guest eh Lamar?
On 09/23/2011 07:57 PM, Lamar Owen wrote:
On Friday, September 23, 2011 01:29:51 PM Dennis Jacobfeuerborn wrote:
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems.
If the timeliness of security updates is essential/critical you cannt get faster updates than with the upstream paid subscription; it is impossible for a rebuild to release the update before it's posted. So, yeah, if getting the fix the quickest is mission-critical then a subscription to upstream should be purchased. If you can't afford or don't want to pay for a subscription, then you have two options:
1.) Build and test it yourself; 2.) Wait on someone else to build it and test it, where 'someone else' can be an individual or one of the rebuild projects, of which CentOS has the largest distribution with SL next largest.
If you can't wait and can't build it and can't pay for a subscription, then you have two options: 1.) Get your server off the net immediately; 2.) Be insecure until you get the update.
Have you pondered the moral implications of your statement? Does that mean that the centos project is perfectly fine with knowingly distributing a system that insecure and a danger not only to its users but to others as well?
All systems are insecure. Updates are for the known holes; there are and always will be unknown holes.
Have you pondered the moral implications of knowlingly installing insecure software and placing it on the public internet? Oh, wait, it's not a moral issue, since there is no such thing as secure software.
It is a moral issue if you know that you cannot provide timely updates.
Drop whatever 6.x related things you are doing, build the package, put it online, make an announcement and then get back to the regular schedule.
You are missing some highly important steps. Let me summarize: 1.) Get source RPM(s) for the update from upstream. Upstream's source RPM's for the updates have been known to be delayed, sometimes for quite a while; 2.) Build; 3.) Verify binary compatibility (that is, does it have identical binary dependencies on identical versions of dependencies, verifying that it was built in an identical buildroot as upstream?) (you do realize that a given source RPM can be built to generate very different and potentially incompatible binary RPMs depending upon the contents of the buildroot, right?); 4.) QA the package to make sure other people with various systems can install and use the package, and that it really does fix the problem; 5.) Make sure the resulting repository is 'closed' (that is, in a consistent state so people updating don't get nasty surprises); 6.) Seed the mirror system. A large package update set can take a significant amount of time to propagate; 7.) Announce, and wait on the inevitable bug reports and complaints that it broke users' systems.
Sounds like fun, no?
"Fun" doesn't enter into it. Apparently there existed an updated httpd package on Sept. 1st that was ready to go and yet here we are three weeks later with no release but more importantly no timely message that it will in fact not be released as planned.
Again if it's not possible for the project to keep up with the updates then this should be openly communicated so users can ponder alternatives. And if it's not possible to release specific high profile/impact updates in a timely fashion for some reason then users should be informed too so they can deal with the situation in other ways.
Yes, QA'ing and releasing a package may be time consuming but sending out an email is not and would do a great deal to at least aid users in their decision making.
Regards, Dennis
The one thing I don't understand is this: AFAIK, apache release not a server update, but an update to the certificate chain, yanking Digitar's CA. This isn't a binary compatibility issue, it's, as we said when I was programming, just data. Can't that be pushed through, or are there code updates in addition?
mark
On 9/23/2011 1:21 PM, m.roth@5-cent.us wrote:
The one thing I don't understand is this: AFAIK, apache release not a server update, but an update to the certificate chain, yanking Digitar's CA.
What, pray tell, are you talking about?
I assume you mean "DigiNotar", the defunct Dutch CA?
What does the complete collapse of a once-trusted CA have to do with Apache? All this noise about DigiNotar is about bogus server-side certs, and how they impact browsers and other client-side SSL users. I have heard nothing about any resulting threat to Apache. The only one I can conceive is something to do with bogus client-side certs, which seems pretty unlikely, given how rarely they are used.
Additionally:
- "grep -Ris diginotar /etc/pki" returns nothing. Ditto for "vasco", DigiNotar's parent organization. This file you are worried about...it apparently lives somewhere else, or does not contain these words?
- Googling "diginotar site:mail-archives.apache.org" also returns nothing. So there's a threat to Apache, but no one on any of the Apache mailing lists is talking about it?
Warren Young wrote:
On 9/23/2011 1:21 PM, m.roth@5-cent.us wrote:
The one thing I don't understand is this: AFAIK, apache release not a server update, but an update to the certificate chain, yanking Digitar's CA.
What, pray tell, are you talking about?
I assume you mean "DigiNotar", the defunct Dutch CA?
Yeah, then. I thought they had several versions of their name, btw.
What does the complete collapse of a once-trusted CA have to do with Apache? All this noise about DigiNotar is about bogus server-side certs, and how they impact browsers and other client-side SSL users. I have heard nothing about any resulting threat to Apache. The only one I can conceive is something to do with bogus client-side certs, which seems pretty unlikely, given how rarely they are used.
First, I thought that some websites had a CA on the server side, and I thought I read that apache was pushing out a fix that merely removed the CA from the chain. That you don't have one doesn't necessarily mean that some other release might have one, or that some site installed it.
Also, I don't think I've seen the Mozilla update same for browsers, which I'd *really* like to push to everybody on our subnet.
mark
On Sep 23, 2011, at 12:21 PM, m.roth@5-cent.us wrote:
The one thing I don't understand is this: AFAIK, apache release not a server update, but an update to the certificate chain, yanking Digitar's CA. This isn't a binary compatibility issue, it's, as we said when I was programming, just data. Can't that be pushed through, or are there code updates in addition?
---- the Apache update has nothing whatsoever to do with issues presented by the (now defunct) DigiNotar Certificate Authority.
That would be handled by updates to browser applications and/or OS Root Certificate store (ca-certificates) which is significant if you have users on the system but again, this all has nothing to do with security updates released for apache (httpd)
Craig
On Friday, September 23, 2011 03:17:07 PM Dennis Jacobfeuerborn wrote:
On 09/23/2011 07:57 PM, Lamar Owen wrote:
Have you pondered the moral implications of knowlingly installing insecure software and placing it on the public internet? Oh, wait, it's not a moral issue, since there is no such thing as secure software.
It is a moral issue if you know that you cannot provide timely updates.
You cannot know how long an update will take until the update is done, thanks to the iterative process of insuring binary compatability.
"Fun" doesn't enter into it. Apparently there existed an updated httpd package on Sept. 1st that was ready to go and yet here we are three weeks later with no release but more importantly no timely message that it will in fact not be released as planned.
I don't think you understand. The process is iterative; if QA fails it's all the way back up to building it again. A package may have existed three weeks ago in terms of being built; if that package had passed binary testing and QA it would have been released by now.
As to 'fun' entering into it, you also realize these guys are volunteers, right? Make a volunteer's life too hard, and that volunteer stops volunteering. These volunteers *owe* the users of CentOS *nothing*. I'm just glad they've done what they've done.
Again if it's not possible for the project to keep up with the updates then this should be openly communicated so users can ponder alternatives.
I disagree. The project has no obligation to communicate *anything* to me; I'll watch the announcements, and when it's announced, I'll get it. I cannot expect any more than that from any volunteer project. If the project chooses to communicate that's great and fine, but I cannot expect it when I am not entitled to it by some means. Sure, that's inconvenient to users of the project's distribution; but users of any free, volunteer-run project need to understand what they're getting themselves into before they install it.
Perhaps the project should more adequately communicate during installation that timely updates, bug-free opeeration, and security fixes are not guaranteed, and require the user to agree to that before installation proceeds.
The CentOS project has done a fantastic job over the years, and it's easy to get spoiled to being a freeloader. But updates don't build and QA themselves.
And if it's not possible to release specific high profile/impact updates in a timely fashion for some reason then users should be informed too so they can deal with the situation in other ways.
Again, it is impossible to know how long a package release will take when you start, or even when you've built it for the twentieth time. Full 100% binary compatibility may mean packages have to be built in a particular order, and it may mean a set of updates has to be built together in order to pass binary compatibility. Once it has passed the binary check it still has to be QA'd, and if it fails you are at square one in ways, building again in a slightly different way to a slightly different buildroot, correcting what QA found. And the fix for one QA issue could easily cause another.
A package as important as httpd must pass muster. A broken update is worse than no update at all.
Yes, QA'ing and releasing a package may be time consuming but sending out an email is not and would do a great deal to at least aid users in their decision making.
Karanbir sent out an e-mail with his best estimate of the time; the estimate was incorrect, but due to the nature of the beast it is impossible to know how long it really will take.
Perhaps the QA process could be more open; perhaps it should be. Perhaps it shouldn't be, too. I'm not in a position to judge that.
Rosman, NC 28772 http://www.pari.edu
On 9/24/11, Lamar Owen lowen@pari.edu wrote:
I don't think you understand. The process is iterative; if QA fails it's all the way back up to building it again. A package may have existed three weeks ago in terms of being built; if that package had passed binary testing and QA it would have been released by now.
I think most of us already understand this part due to the discussions during the pre 6.0 release. The whole point is about the communication.
As to 'fun' entering into it, you also realize these guys are volunteers, right? Make a volunteer's life too hard, and that volunteer stops volunteering. These volunteers *owe* the users of CentOS *nothing*. I'm just glad they've done what they've done.
I appreciate what the CentOS team has done. Certainly I wouldn't had been able to offer the typical budget-constrained clients I get, the equivalent of RHEL they are using now. That said, just because we're doing volunteer work, does not mean we can be totally irresponsible. I did and still do pro bono work for certain non-profit organisations in my country. They understand perfectly that they aren't paying a cent and have no right to make demands. Nevertheless they do have general timelines and decisions that have to be made based on whether certain features are ready or not. It is my responsibility to tell them if something comes up and I cannot expect to implement certain things within the original estimated time. They aren't going to get pissed, they will either change their plans or seek additional help and be thankful that I didn't kept mum until it's too late to do anything constructive.
Similarly, I think that's what most of the people screaming are expecting as the bare minimum. If a build goes to QA, just post an update. If the build fails QA, post an update, we will understand that probably means at least 2~3 weeks of delay, no biggie, there is info, we can make plans and decisions. Everybody's cool. For just a 3 minute effort, the devs won't have to waste time on replies when negativity build up spills over.
On 09/23/2011 12:29 PM, Dennis Jacobfeuerborn wrote:
On 09/23/2011 06:57 PM, Johnny Hughes wrote:
On 09/23/2011 09:06 AM, Stefan Held wrote:
Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes:
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Your "Customers" are not unhappy because they don't like what you do. Your "Customers" are unhappy because they don't know what you do.
The Release and QA Process seems recently to have become a mirracle. There is nothing discussed where your Problems are in getting things done.
So if nobody knows where you are stuck. (Who are the persons anyway hidden in the secret labs?!) Nobody can step up and help out.
Where is this discussion maintained anyway? The Currents process is untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem this fact is not acceptable.
We know that the big boys at RH changed the whole system, but the community accepted that you need time for 6.0 to adept to these changes.
Since then we all thought the issues would have been solved. So what now? What exactly is holding of the release of 6.1 and where can we as a community step in and help?
If you aren't happy, well then we would recommend "something else" that does make you happy.
Or give us the possibility to help becoming happy again. But doing it like Dumbledore in secret regions of the Centos-Hogwards Terrertory is an bad option as it seems.
Happy is important ... don't go through life unhappy because of an OS.
You seem very unhappy at the moment ;)
We just want you to be happy Les.
see my above text.
Are we going to start this again ... we are doing the best we can and we are building things as we go along to take care of issue when we hit a snag.
There is a whole channel of RPMs that we are not allowed to look at from upstream now. They do not release them on any ISOs and we can't pull things directly off RHN (the only way to get the optional channel) and use it. This is just one of many issues we are having right now.
If you can do it better, then do it.
If you can not do it better, great, neither can we ... if we could have been done by now, we would have been by now.
You can, as always, pay Red Hat for RHEL if you have servers where CentOS does not meet your update requirements.
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems. Have you pondered the moral implications of your statement? Does that mean that the centos project is perfectly fine with knowingly distributing a system that insecure and a danger not only to its users but to others as well?
Absolutely ... BINGO ... NOW YOU GET IT.
If you want "point releases" on the day they are released by Red Hat, then you need RHEL ... CUT AND DRY.
We will release things as fast as we can. If it is not fast enough for you personally, then yes, you need something else.
If as you also seem to suggest the project is so severly understaffed have the people in charge considered shutting down the project? This might be the more responsible option compared to having a lot of unsecured systems out there for long periods of time.
Another issue are the priorities of the project. So apparently you are busy working on 6.0/cr and 6.x which is fine. But there is a major but in the current apache packages with a known and released fix upstream. Why can nobody make a manual build sign it and upload it to vault.centos.org?
I told you why .. what else, besides apache needs to be updated?
Can you tell me everything that httpd links against and everything that links against it?
I'll give you a head start start, In order to build, I need these to be updated before I build httpd:
autoconf perl pkgconfig findutils zlib-devel libselinux-devel apr-devel >= 1.2.0 apr-util-devel >= 1.2.0 pcre-devel >= 5.0 openssl-devel
Now, I also need to upgrade anything that provides those packages before I build them ... for example, lets just take openssl:
mktemp krb5-devel perl sed zlib-devel /usr/bin/cmp /usr/bin/rename
So, if each of those need to be verified, and if each of the pre-reqts have 5 or 10 packages, now I need to rebuild up to 20 or so packages.
So, once I build all of the pre-reqts, if required, then I can build httpd. Then we need to verify everything that uses httpd is updated or works OK with the this version.
Can you tell me how using the 6.0 version of php or the mod_* stuff might react in this scenario? Where we have built a new httpd with the 6.1 gcc and glibc and against the new 6.1 libraries, but now want to install it in the 6.0 tree?
Can you tell me how custom modules built by other users might react with this mix and match approach?
All the packages are built in a specific order, what they build against, and what is available in the tree is important.
The fact that apparently people are busy with other stuff but this important update is not considered worthy of anyone's attention is not a problem that can be solved by adding more people but only by the current people making better decisions. Drop whatever 6.x related things you are doing, build the package, put it online, make an announcement and then get back to the regular schedule.
It is not just build 1 package and push it.
If there are issues that prevent this then
make an announcement to that effect so that people at least know that they have to take matter in their own hands. Writing such an email would take 5 minutes and there are not technical hurdles preventing you from doing so. This alone would already be a big improvement over the current situation.
Quoting Johnny Hughes mailing-lists@hughesjr.com:
Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 09/23/2011 12:29 PM, Dennis Jacobfeuerborn wrote:
On 09/23/2011 06:57 PM, Johnny Hughes wrote:
On 09/23/2011 09:06 AM, Stefan Held wrote:
Am Donnerstag, den 22.09.2011, 07:28 -0500 schrieb Johnny Hughes:
No matter what we try to do ... some kind of rolling updates for people who do not want to wait ... or whatever the next thing is ... well you do not seem to be happy.
Your "Customers" are not unhappy because they don't like what you do. Your "Customers" are unhappy because they don't know what you do.
The Release and QA Process seems recently to have become a mirracle. There is nothing discussed where your Problems are in getting things done.
So if nobody knows where you are stuck. (Who are the persons anyway hidden in the secret labs?!) Nobody can step up and help out.
Where is this discussion maintained anyway? The Currents process is untransparent. And for a "C"OMMUNITY "E"nterperise "O"perating "S"ystem this fact is not acceptable.
We know that the big boys at RH changed the whole system, but the community accepted that you need time for 6.0 to adept to these changes.
Since then we all thought the issues would have been solved. So what now? What exactly is holding of the release of 6.1 and where can we as a community step in and help?
If you aren't happy, well then we would recommend "something else" that does make you happy.
Or give us the possibility to help becoming happy again. But doing it like Dumbledore in secret regions of the Centos-Hogwards Terrertory is an bad option as it seems.
Happy is important ... don't go through life unhappy because of an OS.
You seem very unhappy at the moment ;)
We just want you to be happy Les.
see my above text.
Are we going to start this again ... we are doing the best we can and we are building things as we go along to take care of issue when we hit a snag.
There is a whole channel of RPMs that we are not allowed to look at from upstream now. They do not release them on any ISOs and we can't pull things directly off RHN (the only way to get the optional channel) and use it. This is just one of many issues we are having right now.
If you can do it better, then do it.
If you can not do it better, great, neither can we ... if we could have been done by now, we would have been by now.
You can, as always, pay Red Hat for RHEL if you have servers where CentOS does not meet your update requirements.
What you are suggesting here is that people should expect centos systems to be insecure and go the RHEL if they want secure systems. Have you pondered the moral implications of your statement? Does that mean that the centos project is perfectly fine with knowingly distributing a system that insecure and a danger not only to its users but to others as well?
Absolutely ... BINGO ... NOW YOU GET IT.
If you want "point releases" on the day they are released by Red Hat, then you need RHEL ... CUT AND DRY.
We will release things as fast as we can. If it is not fast enough for you personally, then yes, you need something else.
or someone else
If as you also seem to suggest the project is so severly understaffed have the people in charge considered shutting down the project? This might be the more responsible option compared to having a lot of unsecured systems out there for long periods of time.
or accepting money to pay devs?
Another issue are the priorities of the project. So apparently you are busy working on 6.0/cr and 6.x which is fine. But there is a major but in the current apache packages with a known and released fix upstream. Why can
.....
On 09/23/2011 09:58 PM, Johnny Hughes wrote:
On 09/23/2011 12:29 PM, Dennis Jacobfeuerborn wrote:
[SNIP]
If there are issues that prevent this then
make an announcement to that effect so that people at least know that they have to take matter in their own hands. Writing such an email would take 5 minutes and there are not technical hurdles preventing you from doing so. This alone would already be a big improvement over the current situation.
What about this point? I already acknowledged that the build/release may me impossible for various reasons but that doesn't change the fact that people rely on the information given by the project and I have yet to hear a reason as to why writing an email is such an insurmountable task.
Regards, Dennis
On 09/23/2011 04:51 PM, Dennis Jacobfeuerborn wrote:
On 09/23/2011 09:58 PM, Johnny Hughes wrote:
On 09/23/2011 12:29 PM, Dennis Jacobfeuerborn wrote:
[SNIP]
If there are issues that prevent this then
make an announcement to that effect so that people at least know that they have to take matter in their own hands. Writing such an email would take 5 minutes and there are not technical hurdles preventing you from doing so. This alone would already be a big improvement over the current situation.
What about this point? I already acknowledged that the build/release may me impossible for various reasons but that doesn't change the fact that people rely on the information given by the project and I have yet to hear a reason as to why writing an email is such an insurmountable task.
Yes, I suck at communication. Just ask my 1st wife.
On 9/24/11, Johnny Hughes johnny@centos.org wrote:
Yes, I suck at communication. Just ask my 1st wife.
Does that mean that the whole dev team are just going to chalk it up to poor communications, shrug and not do anything about the communication channel, despite the existence of the qaweb and that it probably takes less than 3 minutes each time to post something like "Latest build going for QA", "14 packages failed QA, back to respin"?
Probably a lot less time wasted with those short updates than just reading the flare up mails.
On Friday, September 23, 2011 12:57:31 PM Johnny Hughes wrote:
There is a whole channel of RPMs that we are not allowed to look at from upstream now. They do not release them on any ISOs and we can't pull things directly off RHN (the only way to get the optional channel) and use it. This is just one of many issues we are having right now.
Just for clarification, this is to check binary compatibility, correct? The source RPM's are in the regular location on the ftp.redhat.com site, at least the few I looked at in the optional channel are.
I think many here simply do not understand the degree of meticulousness required to check binary compatibility at the level the CentOS team has historically checked binary compatibility.
To the best of my knowledge, checking binary compatibility requires having a copy of the target binary package from a subscribed system (ideally, you'd likely want to do the checking, or generating a compatability 'signature' of some sort, on a subscribed system to prevent running afoul of the subscription terms of service). To do this for all channels requires multiple licensed and subscribed systems, as far as I can tell from looking at the set of packages I see from my duly subscribed RHEL 6.1 box (duly as in I have paid for the subscription). But I reserve the right to be wrong.
RHEL 6.1 also made significant anaconda installer improvements; to do a full-up 6.1 requires dealing with that, too. The current setup upstream that I can see appears to have made things drastically more difficult, at least from my point of view. And the intended targets weren't CentOS and SL; rather, other commercial competitors providing their own support were the intended targets, IMHO.
While I have asked myself this question (and I think I have it answered privately to my own satisfaction), I really don't think it's appropriate in this list to ask 'well, why has SL been able to release a 6.1 if it is so hard?' since the two projects are different and have different goals, different infrastructure (particularly on the build side), and different teams; no, I'm not going to share my own private answer with anyone, don't even ask. Suffice to say that I will have some SL boxes, and I'll continue to have some CentOS boxes, and I have an RHEL box in my most critical point, and will use each distribution in the role(s) it is most suited to as appropriate to the resources available to support those roles.
On Sat, 17 Sep 2011, Karanbir Singh wrote:
To: CentOS mailing list centos@centos.org From: Karanbir Singh mail-lists@karan.org Subject: Re: [CentOS] This doesn't make sense
Hi,
On 09/17/2011 02:52 AM, Thomas Dukes wrote:
It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0.
Can you expand a bit on the 'wont boot', actually expand quite a lot. Run the installer in debug mode and turn off all rhgb, quiet etc and see what point and how far the system gets.
Faulty burn media?
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Sat, Sep 17, 2011 at 11:57 PM, Always Learning centos@u61.u22.net wrote:
On Sat, 2011-09-17 at 16:50 +0100, Keith Roberts wrote:
Faulty burn media?
I use a lot to record television news, among my many other activities, and estimate about 4% to 5% of DVDs are bad.
Bad media is one high possibility. If you have any other 64bit OS, i.e. Windows (yuk), Ubuntu, etc. Try them. If they boot, then your Centos media is faulty.
On 09/17/2011 04:50 PM, Keith Roberts wrote:
Can you expand a bit on the 'wont boot', actually expand quite a lot. Run the installer in debug mode and turn off all rhgb, quiet etc and see what point and how far the system gets.
Faulty burn media?
This is the sort of message that is really unhelpful. You are stating opinion, with no relation to the actual email posted by the OP, and provide nothing to work with to prove or disprove the situation. Unless ofcourse, you travelled over to the OP's place, went through a diagnostic cycle and arrived at that conclusion. If you did so, please state it so we dont end up wasting everyone else's time trying to go down other routes.
Just want to remind everyone that this isn't a social chatter list, or a LUG free for all. Lets try and actually be productive and lets try to help people in a tangible manner. If you don't have anything relevant to say or contribute to a conversation, its perfectly fine to not say anything at all.
- KB
Just want to remind everyone that this isn't a social chatter list, or a LUG free for all. Lets try and actually be productive and lets try to help people in a tangible manner. If you don't have anything relevant to say or contribute to a conversation, its perfectly fine to not say anything at all.
- KB
KB,
we know.
please do something about the S/N ratio
- rh
On Sun, Sep 18, 2011 at 1:27 AM, Karanbir Singh mail-lists@karan.org wrote:
Faulty burn media?
This is the sort of message that is really unhelpful. You are stating opinion, with no relation to the actual email posted by the OP, and provide nothing to work with to prove or disprove the situation. Unless ofcourse, you travelled over to the OP's place, went through a diagnostic cycle and arrived at that conclusion. If you did so, please state it so we dont end up wasting everyone else's time trying to go down other routes.
Just want to remind everyone that this isn't a social chatter list, or a LUG free for all. Lets try and actually be productive and lets try to help people in a tangible manner. If you don't have anything relevant to say or contribute to a conversation, its perfectly fine to not say anything at all.
That's pretty harsh say. We're not rocket scientists, but from experience we know that to troubleshoot something we should try the easiest and most probable thing first. A lot of people responded related to media, and that's because it happens. As in the end the OP confirms that.
On Sun, 18 Sep 2011, Karanbir Singh wrote:
To: CentOS mailing list centos@centos.org From: Karanbir Singh mail-lists@karan.org Subject: Re: [CentOS] This doesn't make sense
Hi,
On 09/18/2011 12:39 AM, Fajar Priyanto wrote:
A lot of people responded related to media, and that's because it happens. As in the end the OP confirms that.
That is true, and I apologise. Guess I must just be really lucky not having had a media issue in many years now.
- KB
That's accepted by me Karanbir. Thanks for being brave enough to apologize in public. It was not a statement of opinion, but a very terse and concise question to point the OP in what I considered to be a possibility.
Reason being I had a very similar experience with the Fedora Electronics Lab respin Live CD earlier this year.
Kind Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Sun, 2011-09-18 at 08:29 +0100, Keith Roberts wrote:
Reason being I had a very similar experience with the Fedora Electronics Lab respin Live CD earlier this year.
I always buy 386 and x64 DVDs of each Centos sub-version. About 3-4 months ago I tried to install Centos from DVDs and the disks had read errors. I then tried to install from the DVDs of the previous Centos version but those DVDs also had read errors. Luckily I successfully installed Centos from the previous, previous version.
Then I changed my supplier of Centos DVDs and ordered fresh DVDs. Now Centos 5.7 is out, I shall be ordering 386 and x64 DVDs from the new supplier despite upgrading via KB's CR repository.
Regards,
Paul.
-
Alain Péan -
Always Learning -
Christopher Chan -
Craig White -
Craig White -
Dave Stevens -
Dennis Jacobfeuerborn -
Devin Reade -
Digimer -
Emmanuel Noobadmin -
Fajar Priyanto -
John R Pierce -
Johnny Hughes -
Johnny Hughes -
Karanbir Singh -
Keith Roberts -
Kenneth Godee -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
R - elists -
Ross Walker -
Stefan Held -
Thomas Dukes -
Warren Young