Discuss April 2011

discuss@lists.centos.org

312 participants
283 discussions

use of conntrack-tools
by Eric Doutreleau 27 Apr '11

27 Apr '11

hi i would like to use conntrack_tools on my centos server. i use the rpms from centalt but when i launch conntrack -C I got conntrack v0.9.13 (conntrack-tools): Can't open /proc/sys/net/netfilter/nf_conntrack_count Does someone already succeed in using it? Thanks in advance for any answer

4 12

Cacti rpm for el5.6 with php53
by Pasi Kärkkäinen 27 Apr '11

27 Apr '11

Hello, Does someone know if there's a cacti rpm available that works (=installs and doesn't conflict) when "php53" rpm is installed, instead of the older "php" rpm ? cacti rpms from rpmforge/dag have these requirements: php php-mysql php-snmp So those cacti versions conflict with "php53". I checked cacti-0.8.7g-2.el5.rf -- Pasi

6 7

Re: [CentOS] ACPI: Unable to find RSDP problem with centos 5.5 but not 5.3
by sri 27 Apr '11

27 Apr '11

Two more observations: (adding to my previous below email) 1) Centos 5.6 also showing the same ACPI errors as in CentOS 5.5 2)BIOS-E820 map has a difference in the first line: (0000000000010000 instead of 0000000000000000) ================================ - Centos-5.3 BIOS-E820 memory map is: BIOS-e820: 0000000000000000 - 000000000009e000 (usable) BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fee9000 (usable) BIOS-e820: 000000001fee9000 - 0000000020000000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 0MB HIGHMEM available. 510MB LOWMEM available. ================================ - Centos-5.5 BIOS-E820 memory map is: BIOS-e820: 0000000000010000 - 000000000009e000 (usable) BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fee9000 (usable) BIOS-e820: 000000001fee9000 - 0000000020000000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 0MB HIGHMEM available. 510MB LOWMEM available. ================================ Not sure this is why ACPI's root table is not able to find. Any comment/suggestion/pointers are really needed/appreciated. /Sri On Tue, Apr 26, 2011 at 7:14 PM, sri <bskmohan(a)gmail.com> wrote: > Hi Group, > > I was using centos 5.3 and trying to upgrade to 5.5. While installing 5.5 > it was showing ACPI related errors on the screen causing the installation > could not able to find PCI devices. > The same installation is working with Centos 5.3 without any problems. > Observed few ACPI related patches (amont 4500+ patches ) in the Centos5.5 > (kernel-2.6.18-194.32.1.centosplus.el5). > > Tried to remove those new ACPI patches (assuming they caused the problem) > but the rpmbuild process was throwing some patch dependency errors. > Attached are the config files and traces got while installing Centos5.3 and > Centos5.5 respectively. > > Any help/pointers is highly appreciated as this is showstopper for me. > > -- > -- > Sri > -- -- Krishna Mohan B

1 1

5.6 - SRPM's
by Tom Brown 26 Apr '11

26 Apr '11

Hi Is there any ETA for the SRPM's from the base tree of 5.6? I need to get my hands on the src for the centos-release package as i have to rebuilt it to prevent the repo definitions from being included. I see the src's for the updates RPM's but not the base. many thanks

14 33

glibc-2.5-58.el5_6.2.i686 broken?
by Richard Mollel 26 Apr '11

26 Apr '11

Hi, Please note RHEL has just released a fix for this issue: http://rhn.redhat.com/errata/RHBA-2011-0466.html Lets hope it makes it into centos soon... _Thanks Richard Mollel

2 1

iptables
by mattias 26 Apr '11

26 Apr '11

Can anyone see any errors in this scripts Iptables says Invalid target iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i virbr0 -o eth0 -j ACCEPT

2 2

CentOS 5.6 x86_64 hosting unreachable Virtualbox 4.0.6 bridged guests
by Philippe 26 Apr '11

26 Apr '11

Hi, On a box running CentOS 5.6 x86_64 and Virtualbox 4.0.6, I have configured 2 guests (WinXP x86 + CentOS 5.6 x86_64) in bridged mode. The hosting box and the two guests are dhcp enabled. The hosting box get its address normally, but the 2 hosted systems fail to get theirs. The dhcp server log tells : DHCPDISCOVER from 08:00:xx:xx:xx:xx via em0: network xx.xx/16: no free leases. When changing from dhcp to static ip in the CentOS guest, 'service network restart' does not report any errors, but the guest keeps unreachable from the outside : pinging the guest works some times, but trying to reach the guest with ssh, http, or ftp always fail, with or whitout iptables enabled on the host and/or the guests. Please note that: - Kernel and softwares on the hosting CentOS are up-to-date, the box has an Intel Corporation 82567LM-3 Gigabit Network Connection (rev 02) NIC, does not have an Intel VT compliant CPU (Pentium E5700), but VT/AMD-V enabled in bios. - The host is not configured in bridged mode (does not have a br interface configured), Oracle telling that bridged mode on the host is not required to run Virtualbox guests in bridged mode. - The 2 guests work perfectly in NAT mode, but this mode is not an option for me. - The same 2 guests work perfectly in bridged mode on another same hosting box running Fedora 14. Is anyone experimenting the same difficulties with Virtualbox on CentOS 5.6 ? I don't know where to search to solve this problem. Thanks for your help ! -- Philippe

5 5

random roundoff?
by Michael D. Berger 26 Apr '11

26 Apr '11

On my CentOS 5 box, in a C++ program that does much arithmetic, including numerous matrix multiplications, I have a situation in in which the result depends on the nature of nearby I/O. Thus, with all arithmetic done with type double, and where values are mostly in the range [-1.0e0,+1.0e0] or nearby, I do: cerr << "some stuff" << endl; mat3 = matmult(mat1,mat2); I get a difference of the order 1.0e-15 depending on whether the cerr line does or does not end in "endl" as shown. I am imagining that there is some "randomness" in the roundoff that depends on the I/O situation. Is this credible? Any other suggestions? Thanks for your help, Mike.

3 2

mdraid woes (missing superblock?)
by Jussi Hirvi 26 Apr '11

26 Apr '11

I have a raid1 array which is somehow faulty. There is 1,5 TB of stuff, I would not want to lose it (though I have full backup). The array cannot be mounted on startup (error message was "missing superblock"). I had to boot from DVD with linux rescue and remove the array from fstab. Here is some info - I am a little dumbfounded. [root@a134-224 log]# cat /proc/mdstat (...) md5 : active raid1 sdb1[0] sdd1[1] 1562505856 blocks [2/2] [UU] ## mdadm examine - I believe the following output indicates that there really *is* a superblock [root@a134-224 log]# mdadm --examine /dev/sdb1 /dev/sdb1: Magic : a92b4efc Version : 0.90.00 UUID : 194e7fdc:2a288e87:c03d8b24:c0120803 Creation Time : Sat Apr 23 20:41:08 2011 Raid Level : raid1 Used Dev Size : 1562505856 (1490.12 GiB 1600.01 GB) Array Size : 1562505856 (1490.12 GiB 1600.01 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 5 Update Time : Tue Apr 26 11:48:35 2011 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : 657d7a24 - correct Events : 14 Number Major Minor RaidDevice State this 0 8 17 0 active sync /dev/sdb1 0 0 8 17 0 active sync /dev/sdb1 1 1 8 49 1 active sync /dev/sdd1 # examine the other partition/dev/sdd1: Magic : a92b4efc Version : 0.90.00 UUID : 194e7fdc:2a288e87:c03d8b24:c0120803 Creation Time : Sat Apr 23 20:41:08 2011 Raid Level : raid1 Used Dev Size : 1562505856 (1490.12 GiB 1600.01 GB) Array Size : 1562505856 (1490.12 GiB 1600.01 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 5 Update Time : Tue Apr 26 11:48:35 2011 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : 657d7a46 - correct Events : 14 Number Major Minor RaidDevice State this 1 8 49 1 active sync /dev/sdd1 0 0 8 17 0 active sync /dev/sdb1 1 1 8 49 1 active sync /dev/sdd1 [root@a134-224 log]# mdadm --examine --scan (...) ARRAY /dev/md5 level=raid1 num-devices=2 UUID=194e7fdc:2a288e87:c03d8b24:c0120803 [root@a134-224 log]# mdadm --stop /dev/md5 mdadm: stopped /dev/md5 [root@a134-224 log]# mdadm --assemble /dev/md5 mdadm: /dev/md5 has been started with 2 drives. # but it cannot be mounted: [root@a134-224 log]# mount /dev/md5 /kvbck/ mount: you must specify the filesystem type [root@a134-224 log]# mount -t ext3 /dev/md5 /kvbck/ mount: wrong fs type, bad option, bad superblock on /dev/md5, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so [root@a134-224 log]# tail /var/log/messages Apr 26 17:14:09 localhost kernel: md: unbind<sdb1> Apr 26 17:14:09 localhost kernel: md: export_rdev(sdb1) Apr 26 17:14:09 localhost kernel: md: unbind<sdd1> Apr 26 17:14:09 localhost kernel: md: export_rdev(sdd1) Apr 26 17:14:17 localhost kernel: md: md5 stopped. Apr 26 17:14:17 localhost kernel: md: bind<sdd1> Apr 26 17:14:17 localhost kernel: md: bind<sdb1> Apr 26 17:14:17 localhost kernel: raid1: raid set md5 active with 2 out of 2 mirrors Apr 26 17:14:56 localhost kernel: hfs: unable to find HFS+ superblock Apr 26 17:15:05 localhost kernel: VFS: Can't find ext3 filesystem on dev md5. # Why does the log complain about HFS+ superblock? The fs should be ext3. - Jussi -- Jussi Hirvi * Green Spot Suvilahdenkatu 1 B 78 * 00500 Helsinki * Finland Tel. +358 9 493 981 * Mobile +358 40 771 2098 (only sms) jussi.hirvi(a)greenspot.fi * http://www.greenspot.fi

1 0

FYI - pci_mmcfg_init kernel error after upgrading to 5.6
by Windsor Dave L. (AdP/TEF7.1) 26 Apr '11

26 Apr '11

Just thought I'd pass along an error I received this weekend after upgrading two servers to 5.6. Both are HP Proliant DL380 servers running 64-bit, but one is a G6 model and one is a G7. After the upgrade and the reboot to the 2.6.18-238.9.1.el5 kernel, both servers displayed the following error at boot: "pci_mmcfg_init marking 256MB space uncacheable." Some Googling found me the following link: https://partner-bugzilla.redhat.com/show_bug.cgi?id=581933 There are apparently performance implications due to this issue. Fortunately, the solution is simple: just boot with the kernel parameter acpi_mcfg_max_pci_bus_num=on If everyone is already familiar with this, please ignore. :-) -- Best Regards, Dave Windsor Robert Bosch LLC Team Leader, MES Database Infrastructure Group (AdP/TEF7.1) 4421 Highway 81 North Anderson, SC 29621 USA www.bosch.us Tel: 1 (864) 260-8459 Fax: 1 (864) 260-8422 Dave.Windsor(a)us.bosch.com

4 8

← Newer
1
2
3
4
5
6
7
8
9
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2011