Discuss April 2008

discuss@lists.centos.org

252 participants
275 discussions

last resort before hard reboot
by Joshua Frankamp 22 Apr '08

22 Apr '08

Is there a resource for CentOS for things to do before a hard reboot? My situation is apparently an out of memory condition where I am seeing fatal 'oops' output all over the place, Ctrl-Alt-F3 (for example) new console login attempts will accept credentials and then never get to a login prompt. Remoting in is just as useless. I cannot therefore use any of the standard restart commands, since I cannot enter commands. By default in CentOs (and on my machine) Alt- SysRq is disabled. Do I have any other options before hard resetting the box? Thanks, - Joshua

2 1

Odd behaviour with modules; looking for some theories
by Miskell, Craig 22 Apr '08

22 Apr '08

Hi all, Recently, after doing some maintenance on one of my servers (Centos 5), I rebooted. On reboot, it didn't find the SAN disks at all, and after some poking around in maintenance mode, I discovered that it couldn't find the Qlogic module. It turns out that /lib/modules/<kernel-version>/modules.alias, modules.dep and such were all empty or just had their header comment lines. moddep -a fixed things up quickly enough once I figured out what was going on. However, I'm kinda stumped as to how these files got nuked in the first place. It wasn't files being deleted completely, it's like they were regenerated incorrectly. Checking backups showed these files were last changed (to their short form) on Feb 11; yum.log doesn't show any sign of updates on that date, so presumably it wasn't something like a kernel installation running amok. Does anyone have any theories as to what happened? Random logical guesses is fine ;-) Thanks, Craig Miskell, Technical Support, AgResearch Invermay 03 489-9279 "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind- boggling amounts of excrement when you least expect it." -- Gene "spaf" Spafford (1992) ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================

1 0

rejecting I/O to offline device (PERC woes)
by Curtis H. Wilbar Jr. 22 Apr '08

22 Apr '08

Haven't gotten any tips on a solution to the problem below. It happened again this weekend. My next test steps (order not determined): 1. Downgrade to CentOS 4 2. Swap out PERC controller with a spare I have never had a problem with the PERC4/DC controllers on our other machines (RHEL3/4, CentOS 4). Although, I've no other machine that has 5 300G Fujitsu SCSI drives either. Any suggestions on the below, or which order on the above to try ? Thanks, -- Curt ------------------------------- I have a 6650 with a PERC4/DC running CentOS5. After 1 to 3 weeks of operation (running VMWare Server) it 'dies' (raid array gets taken offline) and you get rejecting I/O to offline device. When this system was setup late last year, the 6650 was given all the latest firmware along with the PERC4/DC. using linttylog, the last entries from when the system must have 'checked out' last night, I see the data attached below. Some time back I thought I had cured this problem by adding noapic to the kernel boot parameters in boot.conf. It had gone away for a long time... but is now back. according to lintty, it reports controller firmware is: T0: Firmware version 352D build on Mar 19 2007 at 17:43:23 T0: MegaRAID Series 518 firmware version 352D using strings tty.log | grep 'MedErr on pd' | cut -c17- | sort | uniq -c | sort -n I see: 163 REC:log MedErr on pd[1] #retries=0 165 REC:log MedErr on pd[4] #retries=0 168 REC:log MedErr on pd[2] #retries=0 If I am to believe this, Patrol read is finding media errors on physical drives 1, 2, and 4 ! ? These drives are not even a year old, and to have an almost even distribution of errors across 3 drives seems far fetched (unless patrol read is reading past the end of drive ?, but then it would be doing that with all 5 drives). Is the PERC busted ? driver issue ? I'm running CentOS 5 with kernel 2.6.18-53.1.13.el5PAE from dmesg, megaraid related driver versions: megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Anyone seen this behavior before ? Anyone have a solution ? We have several Dells in a hosting environment with PERC4/DC running RHEL3, RHEL4.X, and CentOS4.X. We have not had this issue on any of them (though they do not have 5 300G Fujitsu SCSI drives in a RAID 5 config either (as this one does)). Hoping someone can shed some light on this... so far I keep coming up short on finding a solution. Here is the full content of the last lines recorded in the PERC as pulled by linttylog: 03/24 21:43:41: Next PR scheduled to start at 03/25 0:00:00 03/25 3:47:41: REC:log MedErr on pd[4] #retries=0 03/25 3:47:41: LogSense: pd=04, cdb=2f 00 14 30 03 12 00 ff ff 00 03/25 3:47:41: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:47:41: REC: MedErr on LD[4] BadLba=143014e6 03/25 3:47:41: prCallback: Medium Error on pd=04, StartLba=14300312, ErrLba=143014e6 03/25 3:47:42: prRecQueue: starting pd=04 recovery - blocking host commands 03/25 3:47:42: prRecGo: Ready to attempt recovery errLBA=143014e6 on pd=04 03/25 3:47:42: prGetLDInfo: MediaErr in ld=0, span=0, arm=4 03/25 3:47:42: prRecGo: dataErr found on ld 0 span 0 arm 4 03/25 3:47:42: prRecGo: data NOT in cache; cacheLn=ffffffff, row=143014, stripe=50c052, refBlk=e6, type=1 03/25 3:47:42: prRecGo: R5-get cacheLn=133, c_ptr=d0dc1045 mem=d0daf9a4 & setup cInx=1db c=d0d26ee6 03/25 3:47:42: RtnFrmPrcRcyRd for arm=1 mem=d0db23f1 stripe=143014 type=2 i=0 status=ffff 03/25 3:47:42: RtnFrmPrcRcyRd for arm=2 mem=d0db2402 stripe=50c050 type=1 i=1 status=ffff 03/25 3:47:42: RtnFrmPrcRcyRd for arm=3 mem=d0db2413 stripe=50c051 type=1 i=2 status=ffff 03/25 3:47:42: RtnFrmPrcRcyRd for arm=0 mem=d0db23e0 stripe=50c053 type=1 i=4 status=ffff 03/25 3:47:43: REC:log MedErr on pd[1] #retries=0 03/25 3:47:43: LogSense: pd=01, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:47:43: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:47:43: REC: MedErr on LD[1] BadLba=143014e6 03/25 3:47:43: REC:log MedErr on pd[2] #retries=0 03/25 3:47:43: LogSense: pd=02, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:47:43: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:47:43: REC: MedErr on LD[2] BadLba=143014e6 03/25 3:47:43: org resgnBlk=e6 03/25 3:47:43: org resgnBlk=ffff 03/25 3:47:43: PatrolReadStart: Log MedErr pd=04 errLBA=143014e6 in NVRAM_EVENT_LOG 03/25 3:48:06: REC:log MedErr on pd[2] #retries=0 03/25 3:48:06: LogSense: pd=02, cdb=2f 00 14 2f a7 92 00 ff ff 00 03/25 3:48:06: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:06: REC: MedErr on LD[2] BadLba=143014e6 03/25 3:48:06: prCallback: Medium Error on pd=02, StartLba=142fa792, ErrLba=143014e6 03/25 3:48:06: prRecQueue: starting pd=02 recovery - blocking host commands 03/25 3:48:06: prRecGo: Ready to attempt recovery errLBA=143014e6 on pd=02 03/25 3:48:06: prGetLDInfo: MediaErr in ld=0, span=0, arm=2 03/25 3:48:06: prRecGo: dataErr found on ld 0 span 0 arm 2 03/25 3:48:06: prRecGo: data NOT in cache; cacheLn=24a, row=143014, stripe=50c050, refBlk=e6, type=1 03/25 3:48:06: prRecGo: R5-get cacheLn=24a, c_ptr=d0dcc646 mem=d0d945e2 & setup cInx=10e c=d0d1f9fc 03/25 3:48:06: RtnFrmPrcRcyRd for arm=1 mem=d0d98e11 stripe=143014 type=2 i=0 status=ffff 03/25 3:48:06: RtnFrmPrcRcyRd for arm=3 mem=d0d98e33 stripe=50c051 type=1 i=2 status=ffff 03/25 3:48:06: RtnFrmPrcRcyRd for arm=4 mem=d0d98e44 stripe=50c052 type=1 i=3 status=ffff 03/25 3:48:06: RtnFrmPrcRcyRd for arm=0 mem=d0d98e00 stripe=50c053 type=1 i=4 status=ffff 03/25 3:48:07: REC:log MedErr on pd[1] #retries=0 03/25 3:48:07: LogSense: pd=01, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:48:07: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:07: REC: MedErr on LD[1] BadLba=143014e6 03/25 3:48:07: REC:log MedErr on pd[4] #retries=0 03/25 3:48:07: LogSense: pd=04, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:48:07: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:07: REC: MedErr on LD[4] BadLba=143014e6 03/25 3:48:07: org resgnBlk=e6 03/25 3:48:07: org resgnBlk=ffff 03/25 3:48:07: PatrolReadStart: Log MedErr pd=02 errLBA=143014e6 in NVRAM_EVENT_LOG 03/25 3:48:09: REC:log MedErr on pd[1] #retries=0 03/25 3:48:09: LogSense: pd=01, cdb=2f 00 14 30 00 d2 00 ff ff 00 03/25 3:48:09: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:09: REC: MedErr on LD[1] BadLba=143014e6 03/25 3:48:09: prCallback: Medium Error on pd=01, StartLba=143000d2, ErrLba=143014e6 03/25 3:48:10: prRecQueue: starting pd=01 recovery - blocking host commands 03/25 3:48:10: prRecGo: Ready to attempt recovery errLBA=143014e6 on pd=01 03/25 3:48:10: prGetLDInfo: MediaErr in ld=0, span=0, arm=1 03/25 3:48:10: prRecGo: dataErr found on ld 0 span 0 arm 1 03/25 3:48:10: prRecGo: data NOT in cache; cacheLn=99, row=143014, stripe=143014, refBlk=e6, type=2 03/25 3:48:10: prRecGo: R5-get cacheLn=99, c_ptr=d0dbabcf mem=d0d92c51 & setup cInx=102 c=d0d1f324 03/25 3:48:10: RtnFrmPrcRcyRd for arm=2 mem=d0d9d002 stripe=50c050 type=1 i=1 status=ffff 03/25 3:48:10: RtnFrmPrcRcyRd for arm=3 mem=d0d9d013 stripe=50c051 type=1 i=2 status=ffff 03/25 3:48:10: RtnFrmPrcRcyRd for arm=4 mem=d0d9d024 stripe=50c052 type=1 i=3 status=ffff 03/25 3:48:10: RtnFrmPrcRcyRd for arm=0 mem=d0d9cfe0 stripe=50c053 type=1 i=4 status=ffff 03/25 3:48:11: REC:log MedErr on pd[2] #retries=0 03/25 3:48:11: LogSense: pd=02, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:48:11: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:11: REC: MedErr on LD[2] BadLba=143014e6 03/25 3:48:11: REC:log MedErr on pd[4] #retries=0 03/25 3:48:11: LogSense: pd=04, cdb=28 00 14 30 14 e6 00 00 01 00 03/25 3:48:11: sense=f0 00 03 14 30 14 e6 28 00 00 00 00 11 01 00 00 00 3f 03/25 3:48:11: REC: MedErr on LD[4] BadLba=143014e6 03/25 3:48:11: org resgnBlk=e6 03/25 3:48:11: org resgnBlk=ffff 03/25 3:48:11: PatrolReadStart: Log MedErr pd=01 errLBA=143014e6 in NVRAM_EVENT_LOG Any help is greatly appreciated, -- Curt

2 1

init script numbers
by Joseph L. Casale 21 Apr '08

21 Apr '08

How does chkconfig determine what number to give to a link when you turn a service on? Thanks! jlc

4 3

enable bootsplash
by David Hláčik 21 Apr '08

21 Apr '08

Hi, how do i enable boot splash (graphical boot) in CentOs5.1 ? I am in init 5, i have updated from minimal install to GNOME using yum groupinstall. Thanks in advance! David

3 6

rpmforge problem
by Anne Wilson 21 Apr '08

21 Apr '08

For several days now I've been trying to update clamav from rpmforge without success. Does anyone know what's likely to be the problem? Anne

6 10

Good news for virtual EL-4.x boxes
by Stephen John Smoogen 21 Apr '08

21 Apr '08

Currently, if you are running CentOS-4.x on a Vmware box you end up with time skew problems. The main fix has been using a set of recompiled kernel that has a HZ that is more fitting with what Vmware expects (eg 100 hz). The 4.7 kernels look like they will not need this: http://jons-thoughts.blogspot.com/2008/04/rhel-and-vmware-time-skew-problem… Well, I've gotten quite the number of questions over the last few days about time skew problems in RHEL4 and VMWare, so figured that I would write this. In RHEL4.7, there will be a kernel feature that allows you to pass 'divider=' on the command line in grub. The number must be a divisor of 1000, and the most common value is 10 (yielding an effective timer interrupt rate of 100Hz). I'm expecting the 4.7 beta to become available Real Soon Now(TM), though I have no information as to when that will occur. In the meantime, this change is available as a hotfix from Red Hat's Global Support Services. What this does is take the kernel tick rate (which defaults to 1000Hz) and divides it by the value of divider, to come up with an effective interrupt rate. You can verify that this is working by: Before making the change, use 'watch --interval=1 cat /proc/interrupts' and you'll notice that the timer interrupt is incrementing by 1000 every second. After you make the change, you you notice with the same command that it is incrementing via 1000/ every second. The vlaue of HZ that is exposed to modules is still 1000, thus not breaking module ABI. This same change is already present in RHEL5.1 today. In recent Fedora's, this is unnecessary due to the advent of the tickless kernel (which is useful for other reasons, including reduced power consumption on laptops). It is likely that RHEL6 will also be based on a tickless kernel. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

2 1

GUI
by hamood Iqbal 21 Apr '08

21 Apr '08

Hi, i am happy user of Centos 5.1 . i have installed Zimbra , Zenoss and webmin for testing purposes. Everything was going fine until yesterday when ever i want to go to yumex Gui it does not open, same with add and remove software when i click it , it does not open. also when i go to "services" gui same is happening. Yesterday i updated the system and rebooted still the problem remains. everything is fine if i do it through the terminal. but when i want to access services , network , yumex , add & remove software they dont start. other programs like Ooffice work. if i check in the terminal they are working. So what is happening ? please help in this matter. i am using centos 5.1 on vmware server 1.0.3. will install on a production server soon. Thanks

4 5

vmware free on Centos5.1 clock sync
by David Hláčik 21 Apr '08

21 Apr '08

Hi, i am running virtual machines on vmware free , both with Windows Server Enterprise 2003. Problem is with clock, they are allways goinng forward faster then should. dmesg informs about : dev/vmmon[21623]: host clock rate change request 83 -> 1043 /dev/vmmon[21623]: host clock rate change request 1043 -> 83 /dev/vmmon[21623]: host clock rate change request 83 -> 1043 /dev/vmmon[21623]: host clock rate change request 1043 -> 83 /dev/vmmon[21623]: host clock rate change request 83 -> 1043 /dev/vmmon[21623]: host clock rate change request 1043 -> 83 all the time. I found on centos wiki information ,about vmware kernel running inside linux virtual machines to change frequency to 100hz. Is there any workaround for this issue? Thanks! David

2 1

CentOS-announce Digest, Vol 38, Issue 10
by centos-announce-request＠centos.org 21 Apr '08

21 Apr '08

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2008:0223 Critical CentOS 4 x86_64 firefox - security update (Johnny Hughes) 2. CESA-2008:0222 Critical CentOS 4 i386 firefox - security update (Johnny Hughes) 3. CESA-2008:0223 Critical CentOS 4 i386 seamonkey - security update (Johnny Hughes) 4. CESA-2008:0222 Critical CentOS 4 x86_64 firefox - security update (Johnny Hughes) 5. CESA-2008:0145 Moderate CentOS 4 x86_64 Imagemagick - security update (Johnny Hughes) 6. CESA-2008:0145 Moderate CentOS 4 i386 Imagemagick - security update (Johnny Hughes) 7. CESA-2008:0235 Important CentOS 4 x86_64 speex - security update (Johnny Hughes) 8. CESA-2008:0235 Important CentOS 4 i386 speex - security update (Johnny Hughes) 9. CESA-2008:0238 Important CentOS 4 x86_64 kdegraphics - security update (Johnny Hughes) 10. CESA-2008:0238 Important CentOS 4 x86_64 kdegraphics - security update (Johnny Hughes) 11. CESA-2008:0240 Important CentOS 4 x86_64 xpdf - security update (Johnny Hughes) 12. CESA-2008:0240 Important CentOS 4 i386 xpdf - security update (Johnny Hughes) 13. CESA-2008:0175 Important CentOS 4 i386 openoffice.org2 - security update (Johnny Hughes) 14. CESA-2008:0175 Important CentOS 4 x86_64 openoffice.org2 - security update (Johnny Hughes) 15. CESA-2008:0176 Important CentOS 4 i386 openoffice.org - security update (Johnny Hughes) 16. CESA-2008:0176 Important CentOS 4 x86_64 openoffice.org - security update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Sun, 20 Apr 2008 09:01:13 -0500 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2008:0223 Critical CentOS 4 x86_64 firefox - security update To: CentOS-Announce <centos-announce(a)centos.org> Message-ID: <480B4CA9.70902(a)centos.org> Content-Type: text/plain; charset="iso-8859-1" CentOS Errata and Security Advisory 2008:0223 https://rhn.redhat.com/errata/RHSA-2008-0223.html The following updated files have been uploaded and are currently syncing to the mirrors: x86_64: seamonkey-1.0.9-16.el4.centos.x86_64.rpm seamonkey-chat-1.0.9-16.el4.centos.x86_64.rpm seamonkey-devel-1.0.9-16.el4.centos.x86_64.rpm seamonkey-dom-inspector-1.0.9-16.el4.centos.x86_64.rpm seamonkey-js-debugger-1.0.9-16.el4.centos.x86_64.rpm seamonkey-mail-1.0.9-16.el4.centos.x86_64.rpm seamonkey-nspr-1.0.9-16.el4.centos.i386.rpm seamonkey-nspr-1.0.9-16.el4.centos.x86_64.rpm seamonkey-nspr-devel-1.0.9-16.el4.centos.x86_64.rpm seamonkey-nss-1.0.9-16.el4.centos.i386.rpm seamonkey-nss-1.0.9-16.el4.centos.x86_64.rpm seamonkey-nss-devel-1.0.9-16.el4.centos.x86_64.rpm src: seamonkey-1.0.9-16.el4.centos.src.rpm

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2008