Search term  M/L Forums
============ === ======
install        0    25
installation   0     7
kernel         0    23
driver(s)      0    22
DNS            3    37
postfix       19    24
sendmail       5    30
selinux        0    23
apache         0    23
httpd          0    40
xen            3    33
kickstart      5    25
crash          2    21
panic          2    27


Google’s tendency to pick up forum posts rather than mailing list posts is much more obvious now than it was last year.  It looks as if Google is fond of the forums better than the mailing lists Or is it simply because there are more posts in the forums?

Regardless of the reason, what this means is that it is important to keep the quality of the forum contents high.  I would say that the current status is quite good; there are a number of forum regulars providing help.  Inappropriate replies, if they appear, get corrected by senior members.  Still, the forums can use more helping hands.  Why don’t you join in and make this CentOS help venue even better?

In the CentOS forums, things are a little more relaxed. After usual warnings, you will receive some (or even extensive) help. As someone put it in a recent post, “… but there are *some* situations, where it [custom kernel] is desirable (usage on notebooks with HW that’s not supported by native kernels – which is e.g. my case or curious minds of young and restless geeks etc. )”.

I am far from ‘young and restless’ and I am not a geek. However, I did compile the latest mainline kernel — in an attempt to help those encountering trouble with installing newer kernels. The error was “mount: could not find filesystem”. I could reproduce it on my CentOS system.

As always, Alan and Ned engaged their brains and we tried several things to find a solution. We were not going anywhere when vanecka posted a fix in this forum thread.

Fix:
Enable CONFIG_SYSFS_DEPRECATED_V2 in the kernel source configuration.
If you run “make menuconfig”, browse to:
General Setup —> enable deprecated sysfs features which may confuse old usersp, and enable this option.
—OR—
Edit your .config file with a text editor and add/modify entry:
CONFIG_SYSFS_DEPRECATED_V2=y

Genius! If you are interested in learning more details about this option, head for this web page.

Recently, it was reported that the centosplus kernel had a problem with certain versions of VMware products as seen in this CentOS forum thread.

Specifically, building the vmnet module on a host fails with the error:

/tmp/vmware-config2/vmnet-only/compat_netdevice.h:273: error: redefinition of ‘struct napi_struct’

Apparently, somewhere in the kernel source that was added in the centosplus kernel, there is that definition and it is conflicting with the VMware code.

It turned out that the problem exists in the VM guest as well: building of the vmxnet modules fails with the same error. The fix, in both cases, is to untar:

/usr/lib/vmware/modules/source/vmnet.tar (host)
/usr/lib/vmware-tools/modules/source/vmxnet.tar (guest)

and comment out the following block in compat_netdevice.h:

struct napi_struct {
int dummy;
};

More details can be found in the CentOS bug tracker.

Steve soon noticed that the machine consumed more power when it was running CentOS compared to when running Fedora. Turns out that, in CentOS, there is no per-core control — meaning when the system needs a higher processor power, all cores will shoot up to the maximum frequency. In Fedora, each core gets attenuated independently.

This issue was noted by a CentOS forum user, AlexAT, here. He not only reported it in the upstream bugzilla but came up with a fix later.

Using the patch provided by AlexAT, we built a kernel module kmod-powernow-k8 and released it through ELRepo. After installing kmod-powernow-k8, Steve saw that the system was now measured drawing ~110W at idle from the wall outlet, similar to the power consumption observed under Fedora 10 and under CentOS 4.7. So without kmod-powernow-k8 installed, the system was consuming ~40W (36%) more power at idle and the core temperature was running 8-10°C hotter than with kmod-powernow-k8 installed, making this a very environmentally friendly kmod.

So, if you have newer Opterons, the Phenoms or Phenoms II (or Kuma core Athlons X2), you should give this driver a try. Also, you would want a backported AMD K10 core temperature monitor driver module (kmod-k10temp) from ELRepo.

Let’s go green!

CentOS, being an Enterprise Class Linux distro, may not have support for new hardware, especially those found in desktops and laptops. CentOS forums get many postings from users who are looking for drivers that are needed for their network device, webcam, etc. In fact, googling for “driver” and “centos” yields much more hits from the forums than the mailing list as shown in my earlier blog.

Alan Bartlett who has been actively helping in the forum has strong background in the kernel and its modules and has been building, whenever possible, a driver module each time he sees a cry for help. In a fairly short period of time, quite an impressive number of such kernel modules were built this way and it was growing.

Because these drivers were designed to be independent of the kernel version (kABI-tracking, kABI = kernel application binary interface), they survive kernel updates. Also, they can be used in RHEL and all its rebuilds, not just CentOS. So, it was a good idea to make them available to wider communities. NedSlider proposed to establish a repository for that purpose. The ELRepo project was thus started by five members of the CentOS / Scientific Linux community.

A little more details of ELRepo can be found in the Ned’s recent blog.

Often times, we want to know how they set up the priority scores but there is no easy way to display them. yum repolist all does not include this info. A forum helper jlehtone posted a one-liner that does just that:

cat /etc/yum.repos.d/*.repo | sed -n -e "/^\[/h; /priority *=/{ G; s/\n/ /; s/ity=/ity = /; p }" | sort -k3n

The output may look like this:

priority = 10 [base]
priority = 10 [updates]
priority = 30 [extras]
priority = 50 [centosplus]
priority = 60 [c5-testing]
priority = 70 [rpmforge]
priority = 75 [kbs-CentOS-Testing]
priority = 90 [kbs-CentOS-Misc-Testing]
priority = 94 [epel]

Almost immediately after the above post, Alan the perfectionist, a cat person himself, opposed the use of over-working cats and came up with his version of the one-liner:

sed -n -e "/^\[/h; /priority *=/{ G; s/\n/ /; s/ity=/ity = /; p }" /etc/yum.repos.d/*.repo | sort -k3n

Personally … I want to see the cats working for the community …

As it turned out, it didn’t work because the repository in question was disabled by default.  The man page for yum clearly states:

Note that "all files" in the commands below means "all files in currently enabled repositories".   If you  want  to  also clean  any  (temporarily)  disabled  repositories you need to use --enablerepo=’*’ option.

After struggling for the next few minutes, I gave up and rebooted the machine to come out of the suspended state.

The Suspend option should not have been there to begin with.  Anyway, it was time to remove it.  Fortunately, that was as easy as typing [1]:

gconftool-2 --type boolean --set /apps/gnome-power-manager/can_suspend false

Likewise, if you want to get rid of the Hybernate option,

gconftool-2 --type boolean --set /apps/gnome-power-manager/can_hibernate false