Horked-up system, Fedora 11

[Ed]

On Tue, Oct 13, 2009 at 2:22 PM, Vaughn Treude <vltreude at deru.com> wrote:
> Hello again:
> This is kind of embarrassing, but I found the problem.
> I'd had scads of disk space before, so I hadn't thought of checking
> that. The root partition was 100% full! There were gigantic message log
> files under /var/cache/logwatch. For the time being I have disabled
> SELinux since it was responsible for a good portion of these messages.
> Guess I better figure out what it's supposed to be doing. :-)
> Vaughn
>

It is usually a good idea to set up /var as it's own partition for
this very reason - other reasons include mounting /var noexec and even
nodev for security.
Disabling SELinux is just a kludge - if DRM is the problem, you might
try a different video driver - what does your CentOS use? Is the video
hardware OK with DRM? and are any of the capacitors on the card
swollen - I've seen some with the same problems as mobos. It really
presents when they are being driven hard.

I have found SELinux to be much better in Fedora 11 that the problem
that it was in F10. Eventually you want to try running with it
enforcing.

Ed

> Ryan Rix wrote:
>> Hello Vaughn,
>> Please see my comments and suggestions below...
>>
>> Vaughn Treude wrote:
>>
>>> Hello all:
>>> Recently I upgraded my main Linux desktop to Fedora 11. Everything was
>>> great, until a couple nights ago I was woken by a frantic beeping coming
>>> from my office. It was my Fedora machine, which was spewing out weird
>>> "SELinux troubleshoot" messages. I rebooted the machine, and it was
>>> running very slowly, so I shut it down.
>>> Today I got time to look at it. The first thing I encountered was an
>>> ominous error at login, something about "Gnome power management
>>> configuration" being invalid. Then I discovered X would not start; it
>>> went to a black screen and appeared to be hung. I could, however, log in
>>> in console mode.
>>> The first thing I noticed was that my "messages" file in /var/log had
>>> become humungous.
>>> About the time of the incident, there were several thousand messages of
>>> this form:
>>>
>>> Oct  8 07:41:48 vaughn kernel: [drm:r128_cce_stop] *ERROR* r128_cce_stop
>>> called
>>> without lock held, held  0 owner f50efd20 f50efd20
>>> Oct  8 07:41:48 vaughn kernel: [drm:r128_cce_reset] *ERROR*
>>> r128_cce_reset called without lock held, held  0 owner f50efd20 f50efd20
>>> Oct  8 07:41:48 vaughn kernel: [drm:r128_cce_start] *ERROR*
>>> r128_cce_start called without lock held, held  0 owner f50efd20 f50efd20
>>> Oct  8 07:41:48 vaughn kernel: [drm:r128_cce_idle] *ERROR* r128_cce_idle
>>> called
>>> without lock held, held  0 owner f50efd20 f50efd20
>>>
>>
>> oh noes! This sounds like a problem with the DRM kernel module... NOTE that
>> it has nothing to do with Digitial Rights (or restrictions :-) ) management.
>> It's Direct Rendering Modules for graphics.
>>
>>
>>> I googled this problem and discovered that (duh!) r128_cce refers to my
>>> ATI Rage 128 driver. I wondered if this card was getting ready to give
>>> up the ghost. (Previously I'd had occasionally lockups when in the
>>> screensaver which I decided were probably video-related - when I turned
>>> of the screen saver, the problems went away.) So I decided to try
>>> rebooting the machine and logging in under my old Centos install
>>> (luckily I'd saved that partition.) Centos booted OK, I logged in, and X
>>> came up fine. So apparently the card is still working, though perhaps
>>> the driver (in Fedora) got hosed.
>>>
>>
>> This is how it sounds to me...
>>
>>
>>> So once again I checked out the /var/log/message file in the Fedora root
>>> partition. In today's entry, the message file contains a bunch of error
>>> messages of this type:
>>> Oct 10 20:09:43 vaughn gdm-simple-greeter[4745]: WARNING: could not get
>>> gconf key '/apps/gdm/simple-greeter/recent-languages': Failed to contact
>>> configuration server; some possible causes are that you need to enable
>>> TCP/IP networking for ORBit, or you have stale NFS locks due to a system
>>> crash. See http://projects.gnome.org/gconf/ for information. (Details -
>>> 1: Could not send message to gconf daemon: Process /usr/libexec/gconfd-2
>>> received signal 6)
>>>
>>> Followed by some of these:
>>> Oct 10 20:09:56 vaughn setroubleshoot: SELinux is preventing
>>> console-kit-dae (consolekit_t) "sys_resource" consolekit_t. For complete
>>> SELinux messages. run sealert -l 20147317-bf50-4d55-819f-465501e5db55
>>> Oct 10 20:10:22 vaughn sedispatch: AVC Message for setroubleshoot,
>>> dropping message
>>>
>>> and then a whole boat load of these:
>>> Oct 10 20:31:49 vaughn kernel: Xorg:3937 freeing invalid memtype
>>> e0196000-e019a000
>>>
>>> So I don't know if I have a video problem, a network problem, a security
>>> problem, an X problem, or if the machine's just totally hosed.
>>> Interestingly enough, I had just tried to run a security update on the
>>> system the night before the Incident. For some unknown reason, it
>>> aborted. I saved the bug report but it appears to be mostly memory dumps
>>> which mean nothing to me.
>>>
>>
>> Please either attach that to a post here, pastebin it, or mail it to me
>> offlist. This is probably the root of your issue. If it aborted during the
>> install phase (which it most likely wouldn't do, but you never know) you
>> have a good chance of hosing your system.
>>
>> Also a copy of /var/log/yum.log would help as well
>>
>>
>>> Unfortunately I usually don't bother to back up the root partition on a
>>> new install until I've gotten everything configured just right. I'd
>>> finally gotten there a few days before, but hadn't gotten around to
>>> actually doing the backup.
>>>
>>> So, any suggestions? Does it sound like it's so badly hosed I have to
>>> reinstall?
>>> I suppose I could try the "repair" utility on the Fedora install disk,
>>> but haven't had much luck with it in the past.
>>> I guess I could go back to the console login and try to do a yum update
>>> manually. (Yum was working fine for configuring all my media players, so
>>> I don't know why the recommended security update failed.)
>>> I'd appreciate any suggestions on the best course of  action!
>>> Thanks!
>>>
>>
>> Please try a Yum update. If that doesn't fix your system, at least we will
>> have some more information about what is incorrect.
>>
>> Ryan Rix
>> Fedora KDE-Ambassadors-News
>>
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>