Hello,
I upgraded to CentOS 5.1 and everything went smoothly (Thanks for the
awesome work!). But after rebooting, I get the following error:
EDAC MC: Ver: 2.0.1 Nov 30 2007
EDAC e7xxx: error reporting device not found:vendor 8086 device
0x2541 (broken BIOS?)
I found http://edacbugs.butter
On Jan 28, 2008, at 2:46 AM, Peter Kjellstrom wrote:
It's safe to not load EDAC at all, but also safe to leave it loaded
and ignore
the error (I'd actually call it a warning). If the functionality is
very
important to your then you might want to do as EDAC suggests and
investigate
BIOS upgr
On Oct 30, 2009, at 9:29 AM, Niki Kovacs wrote:
Now here's what I have on the local backup server :
[r...@grossebertha:~] # crontab -l
24 17 * * * /usr/local/bin/sauvegarde.sh
You may have checked already, but make sure that crond is running,
i.e. /sbin/service crond status. I get crond (pid
On Oct 30, 2009, at 8:43 AM, Adriano Frare wrote:
Dear Friends,
Today , I ran command yum update and I received follow error below.
=== BEGIN =
Loaded plugins: fastestmirror
Determining fastest mirrors
Traceback (most recent call last):
File "/usr/bin/yum", line 2
On Jan 8, 2010, at 4:54 PM, James Rankin wrote:
> For anyone else finding this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=553492
>
Here's a stupid question, can we install the rpm provided on the link above
(see comment 12)? Or is the correct way to modify the local policy?
Thanks,
Di
On Apr 18, 2008, at 10:05 AM, Tony Mountifield wrote:
Hi, I want to take a SRPM that is available for various versions of
Fedora
and rebuild it on a CentOS 4 system.
I read from somewhere that RHEL 4 is based on Fedora Core 3, but
can't find the article now. Somebody will correct me though
Hello everyone,
I was hoping to get recommendations on the proper way to test a RAID
1 hardware configuration. The controller is an Adaptec 2200S. I
found an article, but not for this controller, that suggests to power
off the system, pull one of the drives, boot the OS and power off
aga
Thanks for the help Karanbir and Rainer.
> That sounds quite silly - also going through reboots means downtime,
> isnt that the sort of thing that raid1 was designed to protect against
> anyway.
I guess it would be silly :). I just wanted to make sure it was doing
what it ought too.
>> Have yo
Thanks Scott and Guy, I appreciate the advice/warning.
I can't download it at the moment because the Adaptec site requires
the serial number. I have to reboot and get it from the SMOR (Storage
Manager on ROM) utility. Then I'll have to see if it's worth the
trouble to install and run :)
Wou
On May 28, 2009, at 1:00 PM, Phil Schaffner wrote:
> If you feel you must test the functionality of the ability of the
> RAID1
> to recover from a failed drive, the power down, remove drive, boot,
> power down, replace drive, boot process will test the ability of the
> system to re-sync the driv
On May 28, 2009, at 1:22 PM, Karanbir Singh wrote:
what sort of license is this distributed under ?
I'm sorry but I'm not sure. It's software that supposedly comes with
it when you buy it. But the server was assembled by somebody else and
they probably neglected to include the CD when they
On May 28, 2009, at 2:01 PM, Les Mikesell wrote:
> The thing you need to know about RAIDs at runtime is whether or not
> one
> or more of the drives have already failed since their job is to hide
> this fact from you but you still need to replace it before you lose
> the
> other one and your d
Dan Mensom wrote:
Does anyone know what these accesses are?
Also, on a related note, is it normally best practices to
'setenforce 0'
during a 5.x upgrade?
I also got these type of messages. I just did a yum update from
5.2. Output from audit2allow are as follows:
allow useradd_t rpm_
Hello,
I'm getting the same thing on one of our servers since upgrading to CentOS 5.5:
INFO: task pdflush:21249 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
pdflush D 1EE1 3540 21249 11 21226 (L-TLB)
On Jun 8, 2010, at 12:08 PM, Dianne Yumul wrote:
> Hello,
>
> I'm getting the same thing on one of our servers since upgrading to CentOS
> 5.5:
>
> INFO: task pdflush:21249 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs
15 matches
Mail list logo
