whats this new exploit then? (2009/11/03)
Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- - Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks. Beekeeper - The Apiary Project, KB - www.bees.ed.ac.uk - I grabbed at spannungsbogen before I knew I wanted it. (x(x_(X_x(O_o)x_x)_X)x) The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
RAID configuration problem
Hi, I'm trying to configure a RAID box with 12 x 1 Tb disks on an SL 5.0 system running kernel 2.6.18-8.1.8.el5 through this controller: 04:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08) However, whenever I configure more than 3 of the disks in a LUN I get SCSI errors. For 4 disks in a RAID5 configuration:- Nov 4 10:36:29 terra kernel: Vendor: transtec Model: PV610S12R1A Rev: 347G Nov 4 10:36:29 terra kernel: Type: Direct-Access ANSI SCSI revision: 05 Nov 4 10:36:29 terra kernel: sdq : very big device. try to use READ CAPACITY(16). Nov 4 10:36:29 terra kernel: SCSI device sdq: 5858973696 512-byte hdwr sectors (2999795 MB) Nov 4 10:36:29 terra kernel: sdq: Write Protect is off Nov 4 10:36:29 terra kernel: SCSI device sdq: drive cache: write back Nov 4 10:36:29 terra kernel: sdq : very big device. try to use READ CAPACITY(16). Nov 4 10:36:29 terra kernel: SCSI device sdq: 5858973696 512-byte hdwr sectors (2999795 MB) Nov 4 10:36:29 terra kernel: sdq: Write Protect is off Nov 4 10:36:29 terra kernel: SCSI device sdq: drive cache: write back Nov 4 10:36:29 terra kernel: sdq: unknown partition table Nov 4 10:36:29 terra kernel: sd 5:0:0:1: Attached scsi disk sdq Nov 4 10:36:29 terra kernel: sd 5:0:0:1: Attached scsi generic sg16 type 0 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: printk: 16 messages suppressed. Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:32 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:32 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 ... Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 ... For a LUN with 3 disks it's OK:- Nov 4 10:33:26 terra kernel: Vendor: transtec Model: PV610S12R1A Rev: 347G Nov 4 10:33:26 terra kernel: Type: Direct-Access ANSI SCSI revision: 03 Nov 4 10:33:26 terra kernel: target5:0:0: Beginning Domain Validation Nov 4 10:33:26 terra kernel: target5:0:0: Ending Domain Validation Nov 4 10:33:26 terra kernel: target5:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127) Nov 4 10:33:26 terra kernel: SCSI device sdp: 3905982464 512-byte hdwr sectors (1999863 MB) Nov 4 10:33:26 terra kernel: sdp: Write Protect is off Nov 4 10:33:26 terra kernel: SCSI device sdp: drive cache: write back Nov 4 10:33:26 terra kernel: SCSI device sdp: 3905982464 512-byte hdwr sectors (1999863 MB) Nov 4 10:33:26 terra kernel: sdp: Write Protect is off Nov 4 10:33:26 terra kernel: SCSI device sdp: drive cache: write back Nov 4 10:33:27 terra kernel: sdp: unknown partition table Nov 4 10:33:27 terra kernel: sd 5:0:0:0: Attached scsi disk sdp Nov 4 10:33:27 terra kernel: sd 5:0:0:0: Attached scsi generic sg15 type 0 So, am I restricted to configuring this with sets of three disks? Would moving to a later kernel or release of SL help? Thanks. -- Mark Whidby Infrastructure Coordinator (Unix) - Physics/Chemistry/EAES/Mathematics Team Information Systems Faculty of Engineering and Physical Sciences
Re: RAID configuration problem
Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: printk: 16 messages suppressed. Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:32 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:32 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 ... Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 It's looking horribly like a disk error: have you checked it? Try badblocks. John
Re: RAID configuration problem
John Rowe wrote: Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: printk: 16 messages suppressed. Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:32 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:32 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 ... Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 It's looking horribly like a disk error: have you checked it? Try badblocks. That's what I thought originally but no matter which combination of 4 disks I try to configure I always get these errors. Unless the box has been populated with a whole batch of bad disks, I suppose. -- Mark Whidby Infrastructure Coordinator (Unix) - Physics/Chemistry/EAES/Mathematics Team Information Systems Faculty of Engineering and Physical Sciences
Re: RAID configuration problem
On Wed, 2009-11-04 at 11:01 +, Mark Whidby wrote: John Rowe wrote: Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: printk: 16 messages suppressed. Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:32 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:32 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 ... Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 It's looking horribly like a disk error: have you checked it? Try badblocks. That's what I thought originally but no matter which combination of 4 disks I try to configure I always get these errors. Unless the box has been populated with a whole batch of bad disks, I suppose. I thought that might be too easy, but it was worth a try. Does it follow any particular disk controller? Cable? John
Re: RAID configuration problem
John Rowe wrote: On Wed, 2009-11-04 at 11:01 +, Mark Whidby wrote: John Rowe wrote: Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: printk: 16 messages suppressed. Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:31 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:31 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 Nov 4 10:36:31 terra kernel: Buffer I/O error on device sdq, logical block 732371696 Nov 4 10:36:32 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:32 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 ... Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973688 Nov 4 10:36:33 terra kernel: sd 5:0:0:1: SCSI error: return code = 0x000b Nov 4 10:36:33 terra kernel: end_request: I/O error, dev sdq, sector 5858973568 It's looking horribly like a disk error: have you checked it? Try badblocks. That's what I thought originally but no matter which combination of 4 disks I try to configure I always get these errors. Unless the box has been populated with a whole batch of bad disks, I suppose. I thought that might be too easy, but it was worth a try. Does it follow any particular disk controller? Cable? I haven't been able to test anything like that at the moment. It just seems very odd that with any 4 or more disks configured I get the problem. I'm going to have to try it (and the controller) on another system to try my kernel/SL release possibilities if the owner is amenable. Thanks for your input anyway. -- Mark Whidby Infrastructure Coordinator (Unix) - Physics/Chemistry/EAES/Mathematics Team Information Systems Faculty of Engineering and Physical Sciences
Re: whats this new exploit then? (2009/11/03)
Email from Troy yesterday indicated that SL will have this patch available soon, within the next couple of days. Steve On Wed, 4 Nov 2009, Faye Gibbins wrote: Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
Re: whats this new exploit then? (2009/11/03)
Recent RHEL releases? No, not recent ... all We already have the kernels all built, and are working on the dependencies. Troy Faye Gibbins wrote: Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: whats this new exploit then? (2009/11/03)
On Wed, Nov 4, 2009 at 1:14 AM, Faye Gibbins fgibb...@staffmail.ed.ac.uk wrote: Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? The vulnerability has been there for a long time. It has only just been found by someone who works on the kernel. The finders comments are a bit off.. he first states that its a Red Hat problem and then mentions that people who are going to be using various applications would have to turn it off anyway. My guess is that the SL people will have the updated kernels out as soon as they are tested. http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- - Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks. Beekeeper - The Apiary Project, KB - www.bees.ed.ac.uk - I grabbed at spannungsbogen before I knew I wanted it. (x(x_(X_x(O_o)x_x)_X)x) The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning
SL 4.6 and SL5.2 with Sun fire x4170
Hi all, I'd like to know if I can install a Sun fire x4170 machine with SL4.6 or SL5.3. does anybody know about it? We are using Sun Fire x4150 machine and there is not a problem, but x4170 is not tested. thanks for all. Juanjo -- Juan Jose Pardo Navarro e-mail: juanjo.pa...@uam.es Dpto Fisica Teorica. C-XI. Laboratorio de Altas Energias Universidad Autonoma de Madrid.Phone: 34 91 497 4541 Cantoblanco, 28049 Madrid, Spain. Fax: 34 91 497 3936
Re: whats this new exploit then? (2009/11/03)
Hi Troy, On Nov 4, 2009, at 16:24, Troy Dawson wrote: Recent RHEL releases? No, not recent ... all right. But for SL4 with the latest kernel (-98.0.15), it's just DOS *if* vm.mmap_min_addr is set to, say, 4096. Which, unfortunately, is not the default. SL5 with SELinux *dis*abled is safe as well, but if SELinux is enforcing or permissive it's not, and nor is SL3. If you have trouble getting all those kernels modules dependencies out today, could your try to do SL5 first, then SL3, and then SL4? Thanks, Stephan We already have the kernels all built, and are working on the dependencies. Troy Faye Gibbins wrote: Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __ -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
Re: whats this new exploit then? (2009/11/03)
Stephan Wiesand wrote: Hi Troy, On Nov 4, 2009, at 16:24, Troy Dawson wrote: Recent RHEL releases? No, not recent ... all right. But for SL4 with the latest kernel (-98.0.15), it's just DOS *if* vm.mmap_min_addr is set to, say, 4096. Which, unfortunately, is not the default. SL5 with SELinux *dis*abled is safe as well, but if SELinux is enforcing or permissive it's not, and nor is SL3. If you have trouble getting all those kernels modules dependencies out today, could your try to do SL5 first, then SL3, and then SL4? Well, the building isn't the hard part, that's all done now for all of them, and I believe I'll be able to get SL3 and SL4 out today. SL5 is going to go into testing today, with the expectation that it will go into the main update on monday. Why wait that long? We're updating openafs to version 1.4.11 with this kernel change. We're using RedHat's Fuse with this kernel change For x86_64 we're using RedHat's XFS with this kernel change We're replacing madwifi with the proper atheros driver, with this kernel change. (maybe) We're replacing ipw3945 with iwlwifi-3945 with this kernel change. (maybe) For the maybies (madwifi and ipw3945), I'm not sure the infrastructure is in place on the older SL 5 releases. So we might just keep providing those kernel-modules, which will probrubly be the easy way to do things. I might be able to be persuaded to move the time frame up, but it definitely is going into testing today, and will be there at least one day, no shorter. Troy Thanks, Stephan We already have the kernels all built, and are working on the dependencies. Troy Faye Gibbins wrote: Hi, Any comment from the SL5 distro maintainers on this exploit apparently in recent RHEL releases? http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ Faye -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __ -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
SL_enable... solution for serial ports and SL4.4
Thanks for the help. You probably have SL_enable_serialconsole-3.1-4.noarch installed. Try removing it, This solved the problem. Bill Lutter
Scientific Linux 5.4 i386 is officially released
November 4, 2009 Scientific Linux 5.4 i386 is now officially released and available. We want to thank everyone who has contributed, tested, and given us feedback. We say that every time, but we really mean it. Without everyone's help and testing, this release wouldn't be as good as it is. There are CD and DVD iso images available at http://ftp2.scientificlinux.org/linux/scientific/54/iso/i386/ http://ftp1.scientificlinux.org/linux/scientific/54/iso/i386/ http://ftp.scientificlinux.org/linux/scientific/54/iso/i386/ ftp://ftp.scientificlinux.org/linux/scientific/54/iso/i386/ -Connie Sieh -Troy Dawson --SL 5.4 i386 release notes -- Scientific Linux SL 5.4 for i386 November 4, 2009 Items marked with a * indicate changes since 5.3 See SL.documentation for Upstream vendor release notes. Send comments/issues/test reports to scientific-linux-de...@fnal.gov -- Table of contents DOWNLOAD INFO ADDED compared to Enterprise 5 UPDATED compared to Enterprise 5 Installer/legal modifications CHANGED by Upstream Vendor /contrib SRPMS HARDWARE REQUIREMENTS LIMITATIONS INFO ERRATA _ DOWNLOAD INFO _ ftp://ftp.scientificlinux.org/linux/scientific/54/i386 ftp://ftp.scientificlinux.org/linux/scientific/54/iso/i386 - ADDED compared to vendor - 915resolution-0.5.3-6.el5.i386.rpm 915resolution is a tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets. This includes the 845G, 855G, and 865G chipsets, as well as 915G, 915GM, and 945G chipsets. This modification is necessary to allow the display of certain graphics resolutions for an Xorg or XFree86 graphics server. 915resolution's modifications of the BIOS are transient. There is no risk of permanent modification of the BIOS. This also means that 915resolution must be run every time the computer boots inorder for it's changes to take effect. 915resolution is derived from the tool 855resolution. However, the i code differs substantially. 915resolution's code base is much simpler.i 915resolution also allows the modification of bits per pixel. alpine Alpine is a tool for reading, sending, and managing electronic messages. Alpine is the successor to Pine and was developed by Computing Communications at the University of Washington. Our version of alpine 2.00 has the following changes compared to our 1.0 version An /etc/alpine/pine.conf.sample file is installed, no longer overwriting an existing pine.conf Therefore an existing pine.conf in /etc/alpine will be left untouched even after the upgrade. For an installation from scratch it is advantageous to copy the sample conf file to pine.conf, but alpine works also without it. Users are now able to use a .alpine.passfile This version of alpine when it writes to a large old Unix mailbox format email area can be very slow. The best solution to this is to convert your old Unix mailbox files to mix format mail files. More info can be obtained from Evaluation of file formats: http://mailman2.u.washington.edu/pipermail/alpine-info/2008-July/000971.html Problem description: http://mailman2.u.washington.edu/pipermail/alpine-info/2009-February/thread.html#1658 Conversion : http://www.phwinfo.com/forum/comp-mail-imap/198358-mailutil-mix-file-size.html alpine-2.00-2.el5.i386.rpm AUFS Aufs is a stackable unification filesystem such as Unionfs, which unifies several directories and provides a merged single directory. Aufs is an entirely re-designed and re-implemented Unionfs. aufs-0.20090202.cvs-6.sl5.i686.rpm * kernel-module-aufs-2.6.18-164.2.1.el5-0.20090202.cvs-6.sl5.i686.rpm * kernel-module-aufs-2.6.18-164.2.1.el5PAE-0.20090202.cvs-6.sl5.i686.rpm * kernel-module-aufs-2.6.18-164.2.1.el5xen-0.20090202.cvs-6.sl5.i686.rpm cfitsio CFITSIO is a library of C and FORTRAN subroutines for reading and writing data files in FITS (Flexible Image Transport System) data format CFITSIO is widely used in the astronomical community. cfitsio-3.100-1.el5.i386.rpm cfitsio-devel-3.100-1.el5.i386.rpm *dkms * This package contains the framework for the Dynamic Kernel Module Support (DKMS) method
Scientific Linux 5.4 x86_64 is officially released
November 4, 2009 Scientific Linux 5.4 x86_64 is now officially released and available. We want to thank everyone who has contributed, tested, and given us feedback. We say that every time, but we really mean it. Without everyone's help and testing, this release wouldn't be as good as it is. There are CD images available at http://ftp2.scientificlinux.org/linux/scientific/54/iso/x86_64/ http://ftp1.scientificlinux.org/linux/scientific/54/iso/x86_64/ http://ftp.scientificlinux.org/linux/scientific/54/iso/x86_64/ ftp://ftp.scientificlinux.org/linux/scientific/54/iso/x86_64/ -Connie Sieh -Troy Dawson --SL 5.4 x86_64 release notes -- Scientific Linux SL 5.4 for x86_64November 4, 2009 Items marked with a * indicate changes since 5.3 See SL.documentation for Upstream vendor release notes. Send comments/issues/test reports to scientific-linux-de...@fnal.gov -- Table of contents DOWNLOAD INFO ADDED compared to Enterprise 5 UPDATED compared to Enterprise 5 Installer/legal modifications CHANGED by Upstream Vendor /contrib SRPMS HARDWARE REQUIREMENTS LIMITATIONS INFO ERRATA RPMS that have not built yet _ DOWNLOAD INFO _ http://ftp.scientificlinux.org/linux/scientific/54/x86_64/ http://ftp1.scientificlinux.org/linux/scientific/54/x86_64/ ftp://ftp.scientificlinux.org/linux/scientific/54/x86_64/ - ADDED compared to vendor - 915resolution 915resolution is a tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets. This includes the 845G, 855G, and 865G chipsets, as well as 915G, 915GM, and 945G chipsets. This modification is necessary to allow the display of certain graphics resolutions for an Xorg or XFree86 graphics server. 915resolution's modifications of the BIOS are transient. There is no risk of permanent modification of the BIOS. This also means that 915resolution must be run every time the computer boots inorder for it's changes to take effect. 915resolution is derived from the tool 855resolution. However, the i code differs substantially. 915resolution's code base is much simpler.i 915resolution also allows the modification of bits per pixel. 915resolution-0.5.3-6.el5.x86_64.rpm alpine Alpine is a tool for reading, sending, and managing electronic messages. Alpine is the successor to Pine and was developed by Computing Communications at the University of Washington. Our version of alpine 2.00 has the following changes compared to our 1.0 version An /etc/alpine/pine.conf.sample file is installed, no longer overwriting an existing pine.conf Therefore an existing pine.conf in /etc/alpine will be left untouched even after the upgrade. For an installation from scratch it is advantageous to copy the sample conf file to pine.conf, but alpine works also without it. Users are now able to use a .alpine.passfile This version of alpine when it writes to a large old Unix mailbox format email area can be very slow. The best solution to this is to convert your old Unix mailbox files to mix format mail files. More info can be obtained from Evaluation of file formats: http://mailman2.u.washington.edu/pipermail/alpine-info/2008-July/000971.html Problem description: http://mailman2.u.washington.edu/pipermail/alpine-info/2009-February/thread.html#1658 Conversion : http://www.phwinfo.com/forum/comp-mail-imap/198358-mailutil-mix-file-size.html alpine-2.00-2.el5.x86_64.rpm AUFS Aufs is a stackable unification filesystem such as Unionfs, which unifies several directories and provides a merged single directory. Aufs is an entirely re-designed and re-implemented Unionfs. aufs-0.20090202.cvs-6.sl5.x86_64.rpm * kernel-module-aufs-2.6.18-164.2.1.el5-0.20090202.cvs-6.sl5.x86_64.rpm * kernel-module-aufs-2.6.18-164.2.1.el5xen-0.20090202.cvs-6.sl5.x86_64.rpm cfitsio CFITSIO is a library of C and FORTRAN subroutines for reading and writing data files in FITS (Flexible Image Transport System) i data format. CFITSIO is widely used in the astronomical community. cfitsio-3.100-1.el5.x86_64.rpm cfitsio-devel-3.100-1.el5.x86_64.rpm dropit dropit's intended purpose is to remove directories entries from
TESTING - kernel for SL5
Hello, The new security update for SL5 has been built and is currently being tested. This has an important security fix. But it is also the first kernel since Update 4 that we plan on pushing out, and as such, we are being cautious. We plan on pushing this kernel out on Monday, November 9, 2009 at the latest, possibly sooner. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __
TESTING - openafs for SL5
Hello, In Scientific Linux 5.4 we have updated openafs to version 1.4.11. In keeping with our OpenAFS strategy, we are going to push this update out with the first kernel released after the distribution release. We plan on pushing this openafs update out when we push out the kernel update. That is currently planned for Monday, November 9, 2009 at the latest, possibly sooner. To test or update SL5 --- yum --enablerepo=sl-testing update *openafs* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/ Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __
Re: bug report for yum package
Hello,
Thanks for reporting this, especially with a solution.
We'll work on getting this fixed.
Thanks
Troy
Yannick Perret wrote:
Hello,
I got some troubles with 'yum' on SL5x 64bit. In some cases (seems to
depend of the order of packages) yum fail to install kernel with a crash
message:
# yum install kernel
Loaded plugins: downloadonly, kernel-module
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
-- Running transaction check
--- Package kernel.x86_64 0:2.6.18-164.el5 set to be updated
-- Finished Dependency Resolution
Beginning Kernel Module Plugin
Traceback (most recent call last):
File /usr/bin/yum, line 29, in ?
yummain.user_main(sys.argv[1:], exit_code=True)
File /usr/share/yum-cli/yummain.py, line 229, in user_main
errcode = main(args)
File /usr/share/yum-cli/yummain.py, line 145, in main
(result, resultmsgs) = base.buildTransaction()
File /usr/lib/python2.4/site-packages/yum/__init__.py, line 649, in
buildTransaction
self.plugins.run('postresolve', rescode=rescode, restring=restring)
File /usr/lib/python2.4/site-packages/yum/plugins.py, line 176, in run
func(conduitcls(self, self.base, conf, **kwargs))
File /usr/lib/yum-plugins/kernel-module.py, line 253, in
postresolve_hook
removekernels = remove_kernels(conduit)
File /usr/lib/yum-plugins/kernel-module.py, line 115, in remove_kernels
if txmbr.name in KERNELS and txmbr.ts_state in ('e'):
TypeError: 'in string' requires string as left operand
The problem seems to come from /usr/lib/yum-plugins/kernel-module.py.
Just changing the ('e') for ('e',) at line 115 solved the problem.
Of course we do activate that plugin in our configuration, but the
problem seems to occur or not depending of when the kernel package is
installed (upgraded).
Here is the exact package/version:
# rpm -qf /usr/lib/yum-plugins/kernel-module.py
yum-3.2.19-25.sl.noarch
Best regards,
--
Yannick Perret
CC-IN2P3
--
__
Troy Dawson daw...@fnal.gov (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__
