Discuss

discuss@lists.centos.org

1 participants
34753 discussions

Re: [CentOS] Re: Opteron Mobo Suggestions
by Bryan J. Smith <b.j.smith＠ieee.org> 22 Jun '05

22 Jun '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" <thebs413(a)earthlink.net> > Tyan should put the AMD8131 on CPU #2 on the 2891/2892 > so it doesn't contend with the nForce 2200 on CPU #1 and > its slots/peripherals (and there is no 2050). I should have pointed out this is illustrated in Figure 7: http://www.samag.com/documents/s=9408/sam0411b/0411b_f7.htm -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS releases and the new and improved CentOS Vault.
by Johnny Hughes 22 Jun '05

22 Jun '05

There seems to be some confusion over the way we release CentOS, and the release cycle. First, let's define what the upstream provider does. They released RHEL-2.1 (originally RHAS-2.1), RHEL-3 and RHEL-4. Those are specific and unique releases. They have the following Maintenance Phases: Phase 1: Full Support Start Date: General Availability End Date: 2.5 Years from General Availability date Description: During the Full Support phase, new hardware support will be provided at the discretion of the upstream provider via Updates, Additionally, all available and qualified errata will be applied to the Enterprise products via Updates (or as required for Security level errata.) ------ Phase 2: Deployment Start Date: 2.5 years from General Availability (end of Full Support) End Date: 3 Years from General Availability date Description: During the Deployment phase, all available and qualified security and bug fix errata will be applied to the Enterprise products via Updates. Security Errata will be released as necessary independent an Update. ------ Phase 3: Maintenance Start Date: 3 Years from General Availability (end of Deployment) End Date: 4 Years from end of Deployment (7 years from General Availability) Description: During the Maintenance phase, only Security errata and select mission critical bug fixes will be released for the Enterprise products. ------ Phase 1 and 2 products will get Enhancement updates (RHEA), Bugfix updates (RHBA), and Security updates (RHSA), usually released 2-4 times a year. The updates have numbers (ie., Update 1, Update 2, Update 3, etc.) Currently, RHEL 3 is at Update 5, RHEL 4 is at Update 1. Phase 3 products will only get security updates, usually released individually. RHEL 2.1 is in this phase. There will probably be individual security updates released from this point forward on this distro. http://www.redhat.com/security/updates/errata/ http://www.redhat.com/security/updates/ There is no RHEL-3.4 or RHEL-3.5 ... or RHEL-4.1. If you run up2date on RHEL, you get the updates when RedHat releases them. There are separate ISOs for the different Updates ... but only one set (or tree) of updated RPMS for each distro (RHEL-2, RHEL-3, RHEL-4). If you install off any of the ISOs and then run up2date, you are at the latest update. For example, if you install off the RHEL-3 update 1 ISOs, then run up2date from RHN, you are at RHEL-3 update 5 when finished ... not RHEL-3 update 1 ... and all of this is RHEL 3. ---------------- How does this relate to CentOS releases. First thing is this ... the releases are CentOS 2, CentOS 3, and CentOS 4. Both CentOS 3.1 and CentOS 3.5 are CentOS 3 ... both CentOS 4.0 and CentOS 4.1 are CentOS 4. So, unlike moving from Mandriva 10.1 to 10.2, moving from CentOS-3.1 to CentOS-3.5 is not changing to a new major OS release ... you are just doing exactly the same thing as the above upstream example. Moving from Update 1 to Update 5. CentOS provides new ISOs (just like upstream) when an Update X is released. Let me say it again ... moving from CentOS-4.0 to CentOS-4.1 is not changing to a new major release, it is just applying normally released updates ... except, at that point, there are new ISOs, with new hardware supported at install time. So the CentOS release model is very much like the upstream one, if you run an update, you are at the latest versions for your release tree ... exactly like upstream. --------------------- That being said, there are some who want to treat CentOS-3.1 and CentOS-3.5 as a separate release (or CentOS-4.0 and CentOS-4.1) ... and not part of the same tree. That is not how CentOS is maintained, but we have decided to enhance our vault to allow those people access to the individual trees. If you look at http://vault.centos.org/ you will see that there are currently the following directories: 3.1, 3.1-final, 3.3, 3.3-final, 3.4, 3.4-final, and 4.0 In the case of the CentOS 3, the numbered releases are the starting point .. and the 3.x-final is the ending point tree for that version. In the case of CentOS 4, the 4.0 is the ending tree ... the beginning tree was just the os directory under the 4.0 tree. There are no new security updates applied to those hives, and they are a snapshot of the tree at those points. Again, the tree here are _NOT_UPDATED_ any longer ... so don't use them and expect to have an up to date system. The up to date system is the latest trees that are always available via mirror.centos.org or the pblic mirrors. The vault takes up a major amount of disc space, which will grow as we continue to release new trees and it is not replicated to public mirrors. It is also only available on one machine, so bandwidth and access may be much slower than the real CentOS trees. My advice is that you should change your way of thinking so that you maintain your software the way the upstream provider and CentOS provide it, if at all possible. However, if you cannot do this, then the vault will provide limited access to the older trees. Thanks, Johnny Hughes CentOS-4 lead developer

3 2

Re: [CentOS] Centos 3 - yum update error (rpm-libs)
by thorsten＠uni.de 22 Jun '05

22 Jun '05

>># rpm -qa | grep -i rpm- >>rpm-python-4.2.3-21_nonptl >>rpm-libs-4.2.3-13.WB2 >>rpm-python-4.2.3-13.WB2 >>rpm-4.2.3-21_nonptl >>rpm-4.2.3-13.WB2 >>rpm-libs-4.2.3-21_nonptl > > >rpm -Uvh --replacepkgs --replacefiles rpm....rpm rpm-libs....rpm rpm-python....rpm GREAT, this works. Now it is correct: # rpm -qa | grep -i rpm- rpm-4.2.3-21_nonptl rpm-libs-4.2.3-21_nonptl rpm-python-4.2.3-21_nonptl Thanks to all! cheers, Thorsten

1 0

CentOS4 ClamAV reports zlib needs updating
by Nigel kendrick 22 Jun '05

22 Jun '05

I'm just about to update ClamAV to v0.86 on a CentOS4 box having successfully done this on a 3.3 box but... configure: error: The installed zlib version may contain a security bug. Please upgrade to 1.2.2 or later: http://www.zlib.net. You can omit this check with --disable-zlib-vcheck but DO NOT REPORT any stability issues then! Any expected probs with me doing this update from the site - I have tried with yum (including Dag's repository) and it finds no updates. Ta NK

4 3

Centos 3 - yum update error (rpm-libs)
by thorsten＠uni.de 22 Jun '05

22 Jun '05

Hello *, i get following error: Downloading needed headers Resolving dependencies .....Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-13.WB2, this is not available. I switch from WhiteBox to Centos. How can resolve this problem?

3 2

Re: [CentOS] Centos 3 - yum update error (rpm-libs)
by thorsten＠uni.de 22 Jun '05

22 Jun '05

ok, but how do I reinstall rpm-4.2.3-13.WB2.i386.rpm with rpm-4.2.3-21_nonptl.i386.rpm? When I do a 'rpm -e rpm' I can't install rpm's anymore. When I do a 'rpm -Uhv --force rpm-4.2.3-21_nonptl.i386.rpm' I have duplicate rpm-rpms. cheers, Thorsten

1 0

Script for compiling custom kernel modules
by Juan Carlos 22 Jun '05

22 Jun '05

Hello fellow Linux users. So far I have been good about not adding too many third party software on my servers. One exception is that I generally need third party kernel modules for my hardware. Two of the most important being lm_sensors and 3ware 9000 ones. Now Update 5 includes a 3ware 9000 modules so I might not need to build my own in the future although I think the one I mentioned is not the type that automatically updates the firmware on the card after a reboot but that is for another post. I'm sure there are people out there who have to build kernel modules for their hardware as well. But it is a bit of a pain to keep doing that each time there is a newe kernel security update. So is anyone using scripts to automate this process that they would like to share? It's not like each computer has different hardware, it is all the same but not all of them have tools like gcc and kernel source installed. Only one computer where I compile stuff. Easier to maintain this way. What do you think?

2 1

NTFS for CentOS 4.(0|1)
by Rodrigo Barbosa 22 Jun '05

22 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do we have the ntfs kernel module (readyonly is ok) prebuilt avaliable anywhere for the stock CentOS 4.(0|1) kernel ? Any other options ? Maybe some userspace tool. TIA, - -- Rodrigo Barbosa <rodrigob(a)suespammers.org> "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCsxTApdyWzQ5b5ckRAjPiAJ97g2+I6kcIvywIkpj5Vc+xG8iHRgCgwV6c K7dPbe++CuCtp/MakkNuv6E= =N0L3 -----END PGP SIGNATURE-----

5 9

Re: [CentOS] CentOS 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 22 Jun '05

22 Jun '05

From: Dan Pritts <danno(a)internet2.edu> > I read a web page that suggested that in some cases software built for > "i686" would not in fact work on Via C3 processors (this is near & dear > to my heart since i just bought a motherboard based on one). The C3 > is definitely a modern platform - it's not fast by modern standards but it > works well enough for many applications and its heat/power requirements > are wonderful (circa 10 watts). It all depends how you define "modern." The IDT-Centaur team found that it was very easy to build a chip that dedicated more transistors to a larger cache that get into a lot of pipeline optimizations, out-of-order execution, etc... They were able to build the WinChip in 18 months -- instead of 36+ for a traditional design. The first design also ran on standard 3.3V CMOS and was quite a bit more tolerant of variances. Cyrix did similar with the design of the M2/Geode. The C3 is ViA's evolution of the WinChip-M2 line, in a Socket-370 package for Intel GTL+ under official license from Intel. As much as non-x86 platforms promise more performance for lower power, it's hard to best some of the low-power designs of the x86 world at their economies of scale. > The discussion suggested that the "cmov" instruction was the problem. Yes, the "cmov" instruction is an optional i686 instruction in Intel's own documentation. ViA (possibly both Cyrix and IDT-Centaur too) probably thought it was either a waste of transistors or, more likely, a timing nightmare to integrate into the ALU/control. In fact, if it was considered optional, it sounds like an engineer realized that it could have design impact when the i686 ISA was written (probably in advance of the actual release of the Pentium Pro, or in consideration of Intel's own, future i686 designs). <flammage=on> Intel continues to be the poster child for 1970s CS thought when it comes to overbloat of an already CISC pig. Ironically, at one time, they partnered with Digital on the Alpha chip, which is definitely the most over-anal of RISC architectures. I.e., if it could hold up timing, it didn't go in the AXP ISA -- and they were extremely anal on this to the point of not even including an 8 or 16-bit LOAD/STOR (although Digital finally caved in this in 21164 -- but all other 8/16-bit data operations were always left out). </flammage> The GCC i686 target, unfortunately, assumes it always exists. I can semi-understand the logic, because for a run-time to always test would add a a number of bytes to every single program. And the software workaround takes over 100x more clock cycles. > I, of course, had similar upgrade problems to the original poster. > I don't really care about the performance optimizations from "i386" > to "i686" as long as i'll continue to have something that works. i486 was liberally licensed by Intel under reasonable terms after a US court said numbers could not be trademarked (Intel was hoping to make money on trademark licensing in conjunction). i686/GTL+ was only licensed by ViA, although I'll assume the lack of a cmov instruction in Cyrix/IDT-Centaur designs pre-dates that license. > One additional interesting data point. The CentOS 4.0 installer > gave me the "i586" glibc and the "i686" kernel. I would hope that > this would be consistent. That's not what you want. You want to drop down to a i486 instead of running i586. Here's a general guide: --march=i486 Runs well on a non-superscalar i486, obviously. Runs fairly well on a super-scalar ix86 that does i486, although optimizations for the specific architecture should be used. Portions may run like crap oni586 (true Pentium/MMX), especially ALU control. --march=i486 --mtune=i686 Still runs well on a non-superscalar i486 because superscalar optimizations don't affect it. Runs near-optimal on a superscalar ix86 that has at least the same 7-issue core of the Pentium Pro-P3 (2+2+3 ALU+FPU+control). Even more likely to run like crap on i586 because it assumes the ALU is 2-issue and well-designed, and i586's just ain't anywhere near 'dat! --march=i486 --mtune=i586 (or --march=i586) Improves performance of many operations singificantly on i586. On i486 (if --march=i486, --march=i586 will not run) and i686, will use the chip rather inefficently. E.g., (and this is just 1 example) generated machine code will ripple integers through what it assumes is a pipelined FPU. On an i486 or anything but an Athlon clone, this will not only tie up the FPU, but significantly and artifically delay integer loads. On a true Intel i686 or AMD Athlon, it will leave the 2 and 3 ALU pipes, respectively, unused. Worse yet, the original Nx586 (through the Athlon) is 3x faster at ALU loads than i586, and it is a clear "de-optimization" And that's just 1 example. ;-> --march=i686 Offers little performance gain over --march=i486 --mtune=i686, while not running at all on an i486 or i586. --march=i486|i686 --mtune=pentium4 Offers not only improved performance on the Pentium 4, but all Athlons as well. --march=i486|i686 --mtune=athlon This option has been widely debated. It really _kills_ Intel performance because Intel i686's 2+2 (ALU+FPU) is not going to handle optimizations for AMD Athlon's 3+3 (ALU+FPU) and is going to have lots of stalls (especially on Pentium 4, don't get me started ;-). At the same time, the Athlon benefit is debatable for general applications -- although engineering and scientific _will_ see a good boost (40% is not uncommon). The reason why is simple. Intel's 1 complex _or_ 2 ADD FPU only allows 1 MULT at full 64-bit precision (and not SSE "lossy math") whereas AMD's 2 complex _and_ 1 ADD/MULT allows 3 MULT at full 64-bit precision. Plus, today, you're typically going to be running Athlon64/Opteron, and you get such "optimizations for free" on x86-64 targets. SIDE NOTE: -O3 ... _never_ run -O3 with --march=pentium3, pentium4 or athlon. You're asking for "lossy math" in the case of the former, and unstable optmizations in the case of the latter. It should _only_ be used when you developed the application and know what you're doing. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

GD Support
by Jon McCauley 22 Jun '05

22 Jun '05

Hi Everyone, I am building a script for a client and my imagecreatefromjpeg() is throwing a fatal exception, and dying. It seems as my server with CentOS 4, PHP 4.3.9 doesn't have >= GD-1.8 support or better. I did a phpinfo() and I can not find any reference to GD..............Any help on this would be well appricated -- Best Regards, Jon McCauley

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss