Re: ROADMAP - Scientific Linux 4 roadmap
On 27/01/10 17:23, Troy Dawson wrote: Hello, The Scientific Linux development team has put out a roadmap for the future of Scientific Linux 4. http://www.scientificlinux.org/distributions/roadmap Scientific Linux 4 is going to follow the same type of roadmap that we followed for Scientific Linux 3. SL 4.9 will be a legacy release. It will be supported until the time that RedHat no longer supports RHEL 4, which is February 2012. This release will only get minimal support, security updates only. Red Hat calles this Production 3 Life Cycle Phase which is During Production 3, at a minimum, qualified security errata of important or critical impact and selected mission critical bug fixes may be released independent of minor releases. No new functionality, new hardware enablement or updated installation images are planned for release in Production 3 life cycle phase. There are no minor releases planned during this phase. https://www.redhat.com/security/updates/errata/ SL 4.0-4.8 will be obsoleted. Currently that is set to October 10, 2010. That date is flexible. We want to give users at least 6 months to update to SL 4.9. So if SL 4.9 takes too long to be released, we will move the October date back. Summary: SL 4.0-4.8 : Obsolete in October 2010 SL 4.9 : Minimal support (security only) until February 2012 Thank You Scientific Linux Development Team Just wondering what you mean by SL 4.0-4.8 being 'obsolete'? Is it the same as saying that SL4.0-4.7 are currently 'obsolete'? Tim Edwards
Memory limits for Scientific Linux kernels
We're trying to work out memory limits for 32-bit versions of SL4 and 5. Redhat's page (http://www.redhat.com/rhel/compare/) says that the maximums are 64GB or RHEL4 and 16GB for RHEL5 (I guess because they dropped the HUGEMEM kernel RPM in RHEL5). This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Thanks Tim Edwards
Re: ROADMAP - Scientific Linux 4 roadmap
Tim Edwards wrote: On 27/01/10 17:23, Troy Dawson wrote: Hello, The Scientific Linux development team has put out a roadmap for the future of Scientific Linux 4. http://www.scientificlinux.org/distributions/roadmap Scientific Linux 4 is going to follow the same type of roadmap that we followed for Scientific Linux 3. SL 4.9 will be a legacy release. It will be supported until the time that RedHat no longer supports RHEL 4, which is February 2012. This release will only get minimal support, security updates only. Red Hat calles this Production 3 Life Cycle Phase which is During Production 3, at a minimum, qualified security errata of important or critical impact and selected mission critical bug fixes may be released independent of minor releases. No new functionality, new hardware enablement or updated installation images are planned for release in Production 3 life cycle phase. There are no minor releases planned during this phase. https://www.redhat.com/security/updates/errata/ SL 4.0-4.8 will be obsoleted. Currently that is set to October 10, 2010. That date is flexible. We want to give users at least 6 months to update to SL 4.9. So if SL 4.9 takes too long to be released, we will move the October date back. Summary: SL 4.0-4.8 : Obsolete in October 2010 SL 4.9 : Minimal support (security only) until February 2012 Thank You Scientific Linux Development Team Just wondering what you mean by SL 4.0-4.8 being 'obsolete'? Is it the same as saying that SL4.0-4.7 are currently 'obsolete'? Tim Edwards I guess I wasn't clear on that part. I think I was assuming that people were around when we obsoleted SL 301-308, which many people aren't. They will no longer get any security and/or bug fix updates. We will no longer test errata against these releases. We will move them into the obsoletes area. This way if people still want to use them they still can, but your average or beginning SL user won't be confused thinking they are still fully supported. And mirrors will not feel obligated to have to mirror them. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: Memory limits for Scientific Linux kernels
Tim Edwards wrote: We're trying to work out memory limits for 32-bit versions of SL4 and 5. Redhat's page (http://www.redhat.com/rhel/compare/) says that the maximums are 64GB or RHEL4 and 16GB for RHEL5 (I guess because they dropped the HUGEMEM kernel RPM in RHEL5). This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Thanks Tim Edwards Wow, that SL page is old. Three years old. I need to update it and put caveat's on it. The problem is that I can't put a link to RedHat's page even though that is where I get the information. We use RedHat's kernel with no changes, compiling it to be compatible with their kernel. So whatever RedHat has listed for limits is what we have for limits. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: Memory limits for Scientific Linux kernels
On 28 January 2010 15:18, Troy Dawson daw...@fnal.gov wrote: Tim Edwards wrote: This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Wow, that SL page is old. Three years old. I need to update it and put caveat's on it. The problem is that I can't put a link to RedHat's page even though that is where I get the information. Perhaps I may be permitted to mention the CentOS product page -- http://www.centos.org/product.html As the objective of the CentOS Project is to be 100% binary compatible with TUV's product, the information on that page should have some relevance to SL users. :-) Alan.
Re: Memory limits for Scientific Linux kernels
On Thu, Jan 28, 2010 at 7:18 AM, Troy Dawson daw...@fnal.gov wrote: Tim Edwards wrote: This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Wow, that SL page is old. Three years old. I need to update it and put caveat's on it. The problem is that I can't put a link to RedHat's page even though that is where I get the information. We use RedHat's kernel with no changes, compiling it to be compatible with their kernel. So whatever RedHat has listed for limits is what we have for limits. Same is true for CentOS kernels. So, this page may be useful: https://www.centos.org/product.html Akemi
Re: ROADMAP - Scientific Linux 4 roadmap
On Thu, 28 Jan 2010, Troy Dawson wrote: Tim Edwards wrote: On 27/01/10 17:23, Troy Dawson wrote: Hello, The Scientific Linux development team has put out a roadmap for the future of Scientific Linux 4. http://www.scientificlinux.org/distributions/roadmap Scientific Linux 4 is going to follow the same type of roadmap that we followed for Scientific Linux 3. SL 4.9 will be a legacy release. It will be supported until the time that RedHat no longer supports RHEL 4, which is February 2012. This release will only get minimal support, security updates only. Red Hat calles this Production 3 Life Cycle Phase which is During Production 3, at a minimum, qualified security errata of important or critical impact and selected mission critical bug fixes may be released independent of minor releases. No new functionality, new hardware enablement or updated installation images are planned for release in Production 3 life cycle phase. There are no minor releases planned during this phase. https://www.redhat.com/security/updates/errata/ SL 4.0-4.8 will be obsoleted. Currently that is set to October 10, 2010. That date is flexible. We want to give users at least 6 months to update to SL 4.9. So if SL 4.9 takes too long to be released, we will move the October date back. Summary: SL 4.0-4.8 : Obsolete in October 2010 SL 4.9 : Minimal support (security only) until February 2012 Thank You Scientific Linux Development Team Just wondering what you mean by SL 4.0-4.8 being 'obsolete'? Is it the same as saying that SL4.0-4.7 are currently 'obsolete'? Tim Edwards I guess I wasn't clear on that part. I think I was assuming that people were around when we obsoleted SL 301-308, which many people aren't. They will no longer get any security and/or bug fix updates. We will no longer test errata against these releases. We will move them into the obsoletes area. This way if people still want to use them they still can, but your average or beginning SL user won't be confused thinking they are still fully supported. And mirrors will not feel obligated to have to mirror them. Troy The idea is that you should upgrade to SL 4.9 which will get security errata updates. -connie sieh
Re: Memory limits for Scientific Linux kernels
On Jan 28, 2010, at 16:24 , Alan Bartlett wrote: On 28 January 2010 15:18, Troy Dawson daw...@fnal.gov wrote: Tim Edwards wrote: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Wow, that SL page is old. Three years old. I need to update it and put caveat's on it. The problem is that I can't put a link to RedHat's page even though that is where I get the information. Perhaps I may be permitted to mention the CentOS product page -- http://www.centos.org/product.html As the objective of the CentOS Project is to be 100% binary compatible with TUV's product, the information on that page should have some relevance to SL users. :-) But then, it's not completely accurate either ;-) I don't see it mention the largesmp and PAE kernels, for instance. Tim, I think the SL5/32 limit is 4 GB (3 GB usable) with the regular kernel, 16 GB with the PAE one. I guess the PAE kernel doesn't get as much testing in the field as x86_64. Just curious: why would you want to run a 32-bit OS on a machine with that much RAM? Regards, Stephan -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany smime.p7s Description: S/MIME cryptographic signature
Re: Memory limits for Scientific Linux kernels
Stephan Wiesand writes: Just curious: why would you want to run a 32-bit OS on a machine with that much RAM? For me, binary compatability with 32bit machines in the same computing cluster. Users keeping different programs compiled differently based on which box their job happens to run on is chaotic at best, although being careful with condor can help. -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/
Re: Memory limits for Scientific Linux kernels
On Thu, Jan 28, 2010 at 9:00 AM, Stephan Wiesand stephan.wies...@desy.de wrote: http://www.centos.org/product.html But then, it's not completely accurate either ;-) I don't see it mention the largesmp and PAE kernels, for instance. Well, PAE is missing, but largesmp is mentioned in note (5) :-D But, yes, that page needs updating. Akemi
OpenSSL 1.x
Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: OpenSSL 1.x
Hi Larry, I am on the OSG security team. The message also stated that no action is required at this point. If you block openssl updates you might miss important updates before the v1.x comes out. It should be that updated OSG software that can handle openssl 1.x will be out before openssl v1.x comes through the OS distribution channels. Doug On 1/28/2010 11:25 AM, P. Larry Nelson wrote: Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL 1.x
P. Larry Nelson wrote: Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry Scientific Linux, and RHEL are enterprise linux distributions. This means that they do *not* just update to the latest versions of packages. RedHat and SL will *not* just update to the latest version of openssl, just because it was released. SL 4.0 had openssl 0.9.7a SL 4.8 has openssl 0.9.7a Thas is after five years, we still have the same version of openssl. RedHat backports all the security fixes into the 0.9.7a version for RHEL4 (and hense SL4). SL 5.0 had openssl 0.9.8b SL 5.4 has openssl 0.9.8e After 3 years, SL5 is still at version 0.9.8, although we have moved from b to e. I cannot say for 100% certain, because we are not RedHat. But according to all their policies, goals, statements and past history, they are not going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5) Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: OpenSSL 1.x
Hi Doug, Doug Olson wrote on 1/28/2010 1:48 PM: Hi Larry, I am on the OSG security team. The message also stated that no action is required at this point. The email I got did not say that. It did say: We have proposals to fix this issue and you will be notified when we become compatible with OpenSSL. So it was not clear that we did not need to take action at this point. If you block openssl updates you might miss important updates before the v1.x comes out. It should be that updated OSG software that can handle openssl 1.x will be out before openssl v1.x comes through the OS distribution channels. Doug Thanks for the clarification. Maybe a followup email to g...@opensciencegrid.org with that explanation might put some nerves at ease. :-) - Larry On 1/28/2010 11:25 AM, P. Larry Nelson wrote: Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: OpenSSL 1.x
Hi Troy, Troy Dawson wrote on 1/28/2010 1:55 PM: P. Larry Nelson wrote: Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry Scientific Linux, and RHEL are enterprise linux distributions. This means that they do *not* just update to the latest versions of packages. RedHat and SL will *not* just update to the latest version of openssl, just because it was released. SL 4.0 had openssl 0.9.7a SL 4.8 has openssl 0.9.7a Thas is after five years, we still have the same version of openssl. RedHat backports all the security fixes into the 0.9.7a version for RHEL4 (and hense SL4). SL 5.0 had openssl 0.9.8b SL 5.4 has openssl 0.9.8e After 3 years, SL5 is still at version 0.9.8, although we have moved from b to e. I cannot say for 100% certain, because we are not RedHat. But according to all their policies, goals, statements and past history, they are not going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5) Troy Thanks for the info and history lesson. I didn't know and didn't want to assume. As far as I knew, openssl 1.x might have been a big hairy deal security fix that was imminent. - Larry -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: Memory limits for Scientific Linux kernels
On Thu, Jan 28, 2010 at 02:56:31PM +0100, Tim Edwards wrote: We're trying to work out memory limits for 32-bit versions of SL4 and 5. AFAIC, the effective hard limits for 32-bit Linux are 3 GBytes per user process (they may have squeezed it up to 3.5 GBytes) and 4 GBytes of physical RAM for the machine. If your machine has more than 4 Gbytes of physical RAM, you should be running a 64-bit OS. In this case, 32-bit processes are still limited to 3-3.5 Gbytes of memory, there is no way around that. The by the specs paper limits may say that 32-bit Linux kernels can use more memory, and it might even work in practice, but be aware that it requires that the Linux kernel use some page table magic and relies on funny Intel CPU extenstions (PAE co). As I understand, this leads to noticable drop in performance. I am now curious why are you interested in running 32-bit Linux when 64-bit Linux was invented specifically to fix the memory limits. K.O. Redhat's page (http://www.redhat.com/rhel/compare/) says that the maximums are 64GB or RHEL4 and 16GB for RHEL5 (I guess because they dropped the HUGEMEM kernel RPM in RHEL5). This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Thanks Tim Edwards -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL and EPEL experiences?
On Jan 27, 2010, at 18:45, Michael Mansour wrote: The main thing that annoys me about EPEL is their refusal to add a repo tag on their packages, that is, for an RPMforge package (or any other repo like ATrpms, and the myriads of others) I always know their packages from the package name eg: perl-Mail-DKIM-0.37-1.el5.rf.noarch That rf tells me it's from RPMforge. ATRpms is at, other repo's have their own tags. Packages I build personally have my own tags. With EPEL you have little idea what you used from their repo as their package naming is no different to Red Hat's package naming. Scanning for the RPM info (-qi) is little help as that's also non-conclusive. If you want some history on this you can web search for discussion's between Dag/RPMforge and EPEL maintainers on this topic. I like to strictly maintain servers I manage. No single repo will supply every package I need, so for me, it's imperative I know which 3rd party packages I use from which repo. When that is clouded by not properly tagging package filenames then the many servers that I manage become less manageable in my view an trouble-shooting bugs and problems becomes that much harder. There are many ways you can deal with that: * Use ``yum list —-showduplicates $pkgname'' to find out where a package could have originated. * If you just use the binary packages directly from EPEL, inspect their build hosts or GPG signatures. * If you build the binary packages yourself, set the value of %dist to something more to your liking when you build them. * Place packages in subdirectories that correspond to where they came from. createrepo recurses into directories, after all. I once wrote a script that prints which packages are signed by each GPG key on the system. I could dig it out if you would find it helpful. Recent versions of yum keep track of what repositories each package comes from. Hopefully that feature will make it into 6.0. Hope that helps! -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Memory limits for Scientific Linux kernels
Hi Konstantin, -- Original Message --- From: Konstantin Olchanski olcha...@triumf.ca To: Tim Edwards tedwa...@eso.org Cc: scientific-linux-us...@fnal.gov scientific-linux-us...@fnal.gov Sent: Thu, 28 Jan 2010 13:38:59 -0800 Subject: Re: Memory limits for Scientific Linux kernels On Thu, Jan 28, 2010 at 02:56:31PM +0100, Tim Edwards wrote: We're trying to work out memory limits for 32-bit versions of SL4 and 5. AFAIC, the effective hard limits for 32-bit Linux are 3 GBytes per user process (they may have squeezed it up to 3.5 GBytes) and 4 GBytes of physical RAM for the machine. If your machine has more than 4 Gbytes of physical RAM, you should be running a 64-bit OS. In this case, 32-bit processes are still limited to 3-3.5 Gbytes of memory, there is no way around that. The by the specs paper limits may say that 32-bit Linux kernels can use more memory, and it might even work in practice, but be aware that it requires that the Linux kernel use some page table magic and relies on funny Intel CPU extenstions (PAE co). As I understand, this leads to noticable drop in performance. Just asking for some advice based on your comments above. I have several HP ProLiant DL360 G3 servers, their CPU's are 32 bit only (G4 and above are 64bit), as such I run 32 bit Linux on them. However, many of them have more than 4Gb of RAM (2x2Gb modules plus 2x512Mb is typical) and I use the kernel-PAE to access that extra RAM. The servers typically don't use more than 4Gb of RAM, actually, I hardly ever see them do, they typically access 2-3Gb for normal daily operations. Performance isn't an issue either however, are you saying in my situation I would be better off, performance wise, to just keep the 2x 2Gb DIMMs in them, yank the 2x 512Mb and revert back to the standard kernel RPM's without PAE to get a noticeable increase in performance? I wonder if there's some weblinks anywhere which could show performance graphs of with and without PAE's? Thanks. Michael. I am now curious why are you interested in running 32-bit Linux when 64-bit Linux was invented specifically to fix the memory limits. K.O. Redhat's page (http://www.redhat.com/rhel/compare/) says that the maximums are 64GB or RHEL4 and 16GB for RHEL5 (I guess because they dropped the HUGEMEM kernel RPM in RHEL5). This page (http://www.scientificlinux.org/documentation/misc/limits) says that it's 64GB in SL4 but gives no information for SL5. So two questions: Does SL4 i386 have a 'HUGEMEM' kernel build or do you just build those features into the normal -smp kernel build in order to support 64GB RAM? What is the memory limit on SL5 i386? Thanks Tim Edwards -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada --- End of Original Message ---
Re: Memory limits for Scientific Linux kernels
On Thu, Jan 28, 2010 at 9:00 AM, Stephan Wiesand stephan.wies...@desy.de wrote: http://www.centos.org/product.html But then, it's not completely accurate either ;-) I don't see it mention the largesmp and PAE kernels, for instance. Well, PAE is missing, but largesmp is mentioned in note (5) :-D But, yes, that page needs updating. (7) The x86 Hugemem kernel is not provided in CentOS 5. I believe that covered the larger memory installations in releases prior to 5. Regards, Michael. Akemi --- End of Original Message ---
Re: Memory limits for Scientific Linux kernels
On 28/01/10 18:00, Stephan Wiesand wrote: On Jan 28, 2010, at 16:24 , Alan Bartlett wrote: Perhaps I may be permitted to mention the CentOS product page -- http://www.centos.org/product.html As the objective of the CentOS Project is to be 100% binary compatible with TUV's product, the information on that page should have some relevance to SL users. :-) But then, it's not completely accurate either ;-) I don't see it mention the largesmp and PAE kernels, for instance. Tim, I think the SL5/32 limit is 4 GB (3 GB usable) with the regular kernel, 16 GB with the PAE one. I guess the PAE kernel doesn't get as much testing in the field as x86_64. Just curious: why would you want to run a 32-bit OS on a machine with that much RAM? Regards, Stephan Unfortunately we have some internally-developed software which relies strictly on a particular 'certified' OS version, architecture, package versions etc. It takes a long time to get that re-certified for a newer platform, especially an architecture change. In the meantime we're seeing free reporting 32GB of RAM in an SL5.3 i386 Xen virtual machine that's running the normal SMP kernel. This is why I was a bit confused as I can see no evidence of a HUGEMEM kernel even existing for RHEL or SL 5.x. Here's the output: [r...@localhost ~]# lsb_release -a LSB Version: :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch Distributor ID: ScientificSL Description:Scientific Linux SL release 4.3 (Beryllium) Release:4.3 Codename: Beryllium [r...@localhost ~]# free -m total used free sharedbuffers cached Mem: 32503 1405 31097 0230241 -/+ buffers/cache:933 31570 Swap: 1992 0 1992 [r...@localhost ~]# uname -a Linux localhost 2.6.9-89.0.19.ELsmp #1 SMP Fri Jan 8 04:31:36 CST 2010 i686 athlon i386 GNU/Linux Tim Edwards
