Discuss

discuss@lists.centos.org

2 participants
34758 discussions

Re: Centos3 x86 updates
by Rick Graves 14 Nov '04

14 Nov '04

Hey, As was announced recently by Seth, updates are coming. > These updates should be finding their way to your > local mirror shortly. However, now that we are monitoring the mirrors, we know that some mirrors are behind. For the latest on your favorite mirror near you, you might want to check out the mirror montitoring page, http://www.advanced-app.com.hk/caosity/ I expect a link to this page will be added to the cAos web site shortly, but it is not on there yet. So in the meantime, you might want to add the link to your bookmarks. Rick

1 0

Centos3 x86 updates
by seth vidal 13 Nov '04

13 Nov '04

Hi everyone, Updates for 3 sets of packages. For centos 3. These updates should be finding their way to your local mirror shortly. libxml2: https://rhn.redhat.com/errata/RHSA-2004-615.html RPMS/libxml2-2.5.10-7.i386.rpm RPMS/libxml2-devel-2.5.10-7.i386.rpm RPMS/libxml2-python-2.5.10-7.i386.rpm SRPMS/libxml2-2.5.10-7.src.rpm freeradius: https://rhn.redhat.com/errata/RHSA-2004-609.html RPMS/freeradius-1.0.1-1.RHEL3.i386.rpm RPMS/freeradius-mysql-1.0.1-1.RHEL3.i386.rpm RPMS/freeradius-postgresql-1.0.1-1.RHEL3.i386.rpm RPMS/freeradius-unixODBC-1.0.1-1.RHEL3.i386.rpm SRPMS/freeradius-1.0.1-1.RHEL3.src.rpm httpd: https://rhn.redhat.com/errata/RHSA-2004-562.html RPMS/httpd-2.0.46-44.ent.centos.1.i386.rpm RPMS/httpd-devel-2.0.46-44.ent.centos.1.i386.rpm RPMS/mod_ssl-2.0.46-44.ent.centos.1.i386.rpm SRPMS/httpd-2.0.46-44.ent.centos.1.src.rpm All of these updates can be applied by running: yum update Let us know if there is a problem, thanks. -sv

1 0

Re: [Centos] most stable sata raid cards for centos
by C.M. Connelly 12 Nov '04

12 Nov '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm running an array with an Adaptec 2410SA card (two-port SATA). It seems to run fine under CentOS, but I'm not booting from it (I have a separate SCSI drive that has the OS installed on it; the array is used for backups). I have lost the contents of the array once when one of the drives failed (that was under Red Hat Linux 9, with the Adaptec driver package). I haven't been able to get the current Adaptec driver package to install under CentOS, but as the card seems to work fine without it, I haven't tried very hard. I had some issues with the SATA cables included with the Adaptec card and ended up replacing them with cables that seems to seat better and wobble less. One card I would definitely *not* recommend is Adaptec's AAR-1210SA card, a two-port SATA card with a Silicon Image chipset. After having lots of problems under RHL 9, I managed to get it working with a Debian system with a custom 2.6 kernel. Definitely not worth the money. Both of these arrays were meant as quickie solutions to relatively unimportant problems. If I were to do them again, or do a more serious project, I would definitely go with the 3Ware cards over the Adaptec cards. I also had a very bad experience with a Promise external RAID enclosure that has put me off Promise for life. (Actually, I would seriously consider adding disk space via one or more of Apple's Xserve RAID subsystems, as well.) YMMV. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBlRZpB0pE8d7vd8wRAhAtAKCIsuxhinGoRTMqXNdKDXrthX/LiwCeMOwu OyTaL0+Ti6OVMC6WTAVl2bk= =GJZ2 -----END PGP SIGNATURE-----

2 1

CentOS 3.3 x86_64 hang on a nForce3 250 mainboard
by Richard Shao 12 Nov '04

12 Nov '04

hi all: When I install CentOS 3.3 x86_64 on a athlon64 with a Gigabyte K8NS mainboard(nForce3 250 chipset), it hangs after detecting IDE controller. I've tried to pass acpi=no to kernel, but the problem still exists. can anyone help me? thanks!

2 2

SNMP problems
by Peter Farrow 11 Nov '04

11 Nov '04

Dear All, I don't know if this is the right list for this type of question and I am sure I will be told if its not.... I am using Centos 3.3, with a 2.4.20-30.9 kernel on an Amd Opteron box. I am using this kernel because it has matching freeswan modules. I am also using the following net-snmp packages: net-snmp-5.0.9-2.30E.6 net-snmp-devel-5.0.9-2.30E.6 net-snmp-utils-5.0.9-2.30E.6 I find that the values returned for the ethernet traffic (this machine has six ethernet ports) via snmp are bogus and the same for in and out octets, bearing no resembence to the actually network traffic. I have Yummed to the latest of everything, but still no joy, its still wrong, If anyone knows of this problem please could you put me out of my misery.... :-) In the mean time I have written a perl script to grep the rx/tx bytes printed by ifconfig and sent these to mrtg for now, but this is not ideal..... Regards Pete

1 0

most stable sata raid cards for centos
by Imran ＠ Coreix LTD 11 Nov '04

11 Nov '04

Hi, What are the most stable sata raid cards for centos. Looking at sata raid1 setup. Kind Regards, Imran ************************************* This electronic transmission is strictly confidential and intended solely for the addressee. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. *************************************

3 3

kernel swapping bug
by William Warren 07 Nov '04

07 Nov '04

I have been fighting with a kernel swapping bug for some time that was present in RH9 and carried over to RHEL 3 and hence CentOS. There is a beta U$ kernel and i was wondering would i break my system installing this beta U$ kernel? Also how would i go about installing this kernel? Is it a simple RPM command argument? Bugzilla report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132155 kernel File in question: http://people.redhat.com/~lwoodman/.for_sun/ -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape"

1 0

why developers got stuck with huge ISP bill
by Rick Graves 06 Nov '04

06 Nov '04

Lance, Let's go at this from another angle. > I am absolutely certain having analysed the logs > that the excess bandwidth was caused by people > downloading .iso images for centos from our > master mirror(s) .... How could this happen? Here is my explanation: 1) As far as I am aware, the cAos site does NOT ask distro users to download from public mirrors, rather than from the master mirror. 2) On install, yum.conf points to the master mirror. 3) Even if a distro user puts in a custom yum.conf file that points to a public mirror, "yum update" can remove the custom yum.conf file, and put in its place a yum.conf that points to the master mirror. 4) From 2 & 3, I got the impression that it is OK, even encouraged, to download directly from the master mirror. This is supported by the lack of any request not to do so, 1. 5) Maybe lots of other distro users got the same impression as 4. That is my explanation. Does anyone have a better explanation for Lance's analysis of the logs? Rick

1 0

Re: [Centos] Promise raid cards - software raid
by dan1 05 Nov '04

05 Nov '04

Thanks again for those answers which I'm sure will also interest other people. If I understand correctly, I can use software RAID with no disadvantages over hardware RAID as for reliability in cases of power failures (as long as we use journalised filesystem), is that correct ? I'm not in fear about he CPU increase for software RAID, that isn't a problem to me. What else do you think I would loose by using software RAID instead of hardware raid ? Also, sorry to insist about power failures, but here is the reason: my provider allows me to have remote reboot on my server, which is very helpful when the system hangs suddenly as I have no physical access. Curently I must do a hardware reboot 1-2 times per year and the system starts and runs again correctly. These remote reboots are power failure types and are more and more frenquently offered to customers. It avoids us to ask the technician to reboot the machine. Your professionnal experience is very instructive. All you said about the flush problem is thrilling. Do you mean then that having battery bakup RAID will not help much regarding reliability in cases of power failures ? Then many people have been tricked ? Last: is there a mean of knowing what datas have been lost when a power failure happened ? Can we see that in terms of sectors, clusters or in terms of files which are corrupted ? Can we see a list of those ? Thank you a lot, Terrence ! Daniel ----- Original Message ----- From: Terrence Martin To: dan1 Sent: Friday, November 05, 2004 2:01 AM Subject: Re: [Centos] Promise raid cards - software raid dan1 wrote: > Hello, Terrence. > > Thank you for your complete answers. That's very interesting. > > > > I am not sure what you mean about the file system crashing? > > I meant that it becomes unrecoverable, or that some datas are missing. > These are two seperate problems with two seperate solutions. You can have loss of data without the file system having any problems. That is data is missing, perfectly working file system. In fact journaled file systems pick preserving the file system over missing data every time. Eg. You have a database and are writing a query to the database that inerts 1000 records. If you do not insert all 1000 records then you cannot use any of them. That is record 1000 depends on all the previous 999. On record 678 the power fails. When the system comes back what happened to the first 678 inserts? You assume they complete but since you need all 1000 for the data to be valid you basically have to delete the ones you did insert and start again, if you can. Deleting means that you first have to know what records to delete. Depending on the complexity of the inserts (they could touch dozens of tables and interrelationships) you could have a lot of work ahead of you to manually find what is a record that is part of that incomplete set and what records are not. This is where a journal comes in. A journal records when data is written. Basically you record what you write after you finish writing a record so that worst case you can replay that journal of changes to back out of what happened. This is what a journaled file system does. It allows you to more easily back out of the incomplete data problem quickly. This is opposed to the old method of file system consistency checking which was like a manual search of the entire database. If you only have to go over the changes, rather than searching the whole database it is faster. Also the long manual check is complicated and prone to error. For speed and accuracy a journal is better. However journaled file systems do not save the data. In fact journaled file systems will throw away data if it is incomplete. Say in the above example for some reason that you could use the first 678 records, or that there was no other way to recover the 1000 records again so 678 was better than nothing. Well a journal does not care. It simply looks to see if the whole transactions completed of 1000 records. If it didn't it deletes everything up to the failure. Even if 999 of the 1000 records was written it will still delete the 999. The assumption being that it is better to have a consistent file system and protect the good data than have partially written data, that while valuable is inconsistent. If you want to ensure that even partial data is preserved you have to do other things to protect it. A battery protect RAID card is one very very narrow approach that solves one specific type of failure state. Where data is written to the RAID card but not to disk yet. Lets go back to our above example You have a power failure on record 678. The raid card has memory to store 5 records. At the time of the power failure it has only sent the first 673 records to the disks for writting. The other 5 are in the controller cache. If you have a battery on that memory you will save those 5 records. However does it matter? Afterall 678 or 673 they are still not 1000. Also the disks themselves may store in their cache 2 records. So the disk has only written records up to 670 with records 671 and 672 still waiting in volatile RAM with no battery backup attached directly to the disk (write back cache on all PATA drives). The power fails and the system comes back online. The RAID card writes records 673-678 to the disks and they write them. Unfortunately records 671 and 672 are lost because they were in volatile disk cache on the disk itself. So you have records 0-670,637-678. You in fact have a hole in what you have on disk, and who cares anyway because the journaled file system is going to delete all those records when it goes to work to ensure integrity over data preservation. Basically RAID batteries buy you something, but not much, and they buy you even less when they are attached to ATA drives that have write back cache that essentially makes the RAID cache moot. > > I do not recommend ext3 for anything over about 120GB. > > OK, that's interesting. > I work with compute cluster and with file systems that are in the terabytes of size. Basically nothing else has come close to XFS in practice. The guys that admin the really big stuff that we collaborate with will not touch anything but XFS and they have petabytes of storage. If you can go with XFS. Even RHEL4 should finally have XFS standard since fedora core 2 and later has it as an option, even for the root disk. > > My biggest question is why at this point are you even bothering with > PATA drives? Compared to SATA drives they are unreliable and poor > performing for about the same cost. > This is what I get from my ISP (I think). However it doesn't change a > lot my conception and thoughts about raid. The flush problem remains > the same. > Also I am more familiar to PATA. The flush problem as I hope I have demonstrated is not at all addressed by battery backups on RAID card ram. Battery based backup of RAID memory is a good gimmick, but in practice is useless. It covers such a narrow part of the problem space as to be irrelevant. If you are concerned that power failure will loose data get a UPS for the entire system. It is the only thing that will help you because it is the only thing that will allow your entire system, from software to hardware to achieve a consistent state before shutting down. Otherwise you may save a few bytes of data that was in cache on the RAID card but that does not matter since you will still end up with an incomplete file system transaction that the journaled file system is going to delete anyway. The linux journaled file systems are very good at preserving integrity, even in the face of underlying hardware failure in some cases. Choosing a good file system is all you need to do there to ensure that aspect. As far as data loss, aside from backups after the fact the only solution that will work in practice is Uninteruptible Power Supplies that will give you enough time to shutdown the entire system in a consistent way. Terrence > > Thank you for your interesting advices. I appreciate that ! > > Best regards, > > Daniel > > >

1 0

dvd iso's
by William Warren 05 Nov '04

05 Nov '04

I edited the .discinfo file but still the installer does not recognize the dvd as an instllation medium. I have attached the .discinfo file. If i made a mistake let me know..otherwsie it looks like the installation program itself may need a bit of adjusting..no idea. William William Warren wrote: > Well that didn't work. I got a bootable dvd out of it but the centos > installed did not detect the media as having the installation files. It > asked for a cd instead of recognizing the dvd. Winiso cannot handle > dvd's..:( Anyone have a way to make the centos installer realize all > its files are on the dvd instead of looking for three cd's? > > -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" 1095354229.83 update3 i386 1,2,3 RedHat/base RedHat/RPMS RedHat/pixmaps

3 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss