Red Hat Bugzilla – Bug 430102
kerneloops should allow the user to review what information gets submitted
Last modified: 2011-12-13 17:29:03 EST
Description of problem:
There is a man page in the package, but it is misnamed and so "man 8 kerneloops"
And when I did get to read it, it was dissapointing. How can the owner/user
also get to see the oops messages?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. man 8 kerneloops
man page not found
display man page
ln -s /usr/share/man/man8/kerneloops.1.gz /usr/share/man/man8/kerneloops.8.gz
provided a workaround
Fixed the filename in 0.10-2
What additional documentation would you like to see?
I'l like to know how I can see the message thats being sent to the kernel
maintainers. I'd like to know what *kind* of information is being sent. I'd
like to know that its not a privacy concern.
Access to oops messages wourl be very useful. For example. I'm getting a total
system lockup right now that only happens when using secondlife on nvidia
hardware on kernel-2.6.24. 2.6.23 doesn't have the problem. I can't find any
info on the crash, I was hoping for some oops info? I know I'll get no
sympathy if I can't narrow the problem down.
It looks like kerneloops is supposed to have some kind of desktop applet?
Where is it? How do I use it?
(In reply to comment #3)
> I'l like to know how I can see the message thats being sent to the kernel
> maintainers. I'd like to know what *kind* of information is being sent. I'd
> like to know that its not a privacy concern.
Yeah, this should be added, but I'm not a desktop application programmer.
> Access to oops messages wourl be very useful. For example. I'm getting a total
> system lockup right now that only happens when using secondlife on nvidia
> hardware on kernel-2.6.24. 2.6.23 doesn't have the problem. I can't find any
> info on the crash, I was hoping for some oops info? I know I'll get no
> sympathy if I can't narrow the problem down.
The oopses are in the system log.
> It looks like kerneloops is supposed to have some kind of desktop applet?
> Where is it? How do I use it?
The only thing the applet does is pop up the request for permission to submit
*** Bug 439282 has been marked as a duplicate of this bug. ***
> The only thing the applet does
Well it should tell the user what information is being submitted, like smolt does.
This is quite important. Are memory dumps being sent?
Most users won't know what an oops is or what information it contains.
Ok so there's two options, and I'd love to get opinions on these:
Option 1: Show the actual oops data that is being sent.
Note: This is quite hard given how the desktop notification thingies work; I'm
still not entirely sure how to do it in a way that's not a security hole
Option 2: Link to a page on kerneloops.org that shows an example oops and has
some explenation for what the various pieces mean. This link would be in the
notification dialog, and if the user clicks on it, a browser window will open
This is relatively easly to implement, and has no security implications.
Obviously I'd strongly prefer option 2, not only because it's easier (yes I'm
very lazy) but also because it allows for adding explenations and other
What do the people on this bug think?
First questions first..
> Option 1: Show the actual oops data that is being sent.
> This is quite hard
Why is this hard? The applet knows that an oops has happened, does it not have
access to the information that it is asking to send?
Option 2 sounds reasonable, if only to get people asking for option 1 first (but
I'd still be interested in your answers)
There is a few problems with option 1:
* Getting things on the screen. To get the notification window stuff open
other windows is .. more complex code than a busy kernel coder can do :)
* The background daemon runs with root privs, the forground one as user. So
communication by default is limited to a bare minimum
* The way it works right now is that when you click "yes", all oopes in the
queue are sent. There's a race if the tool would show the current oopses,
because new oopses could come in between that time and the time you click yes.
Otoh.. adding a URL to the window is rather easy.
strong +1 for "Option 1" -- I'd actually like to see what I'm precisely going to
submit before I submit it. Not only due to privacy concerns but also due to
"does this make sense to submit?"
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
A modification to the option 2 could be just telling the user to run a simple
command in the terminal to examine the (to be) sent oops(es). I've never used
it, but maybe ksymoops can be used in this case.
(In reply to comment #4)
> The oopses are in the system log.
My system log only shows that a kerneloops has been submitted, not the actual
/var/log/messages:3846:May 21 23:29:44 localhost kerneloops: Submitted 1 kernel
oopses to www.kerneloops.org
kerneloops-0.11-1.fc9 has been submitted as an update for Fedora 9
kerneloops-0.11-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kerneloops'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5496
kerneloops-0.11-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.