Bug 430102 - kerneloops should allow the user to review what information gets submitted
kerneloops should allow the user to review what information gets submitted
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kerneloops (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 439282 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-24 10:17 EST by John Ellson
Modified: 2011-12-13 17:29 EST (History)
4 users (show)

See Also:
Fixed In Version: 0.11-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-08 22:53:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Ellson 2008-01-24 10:17:17 EST
Description of problem:
There is a man page in the package, but it is misnamed and so "man 8 kerneloops"
doesn't work.

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):
kerneloops-0.10-1.fc9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. man 8 kerneloops
2.
3.
  
Actual results:
man page not found

Expected results:
display man page

Additional info:
ln -s /usr/share/man/man8/kerneloops.1.gz /usr/share/man/man8/kerneloops.8.gz
provided a workaround
Comment 1 Chuck Ebbert 2008-01-24 13:24:19 EST
Fixed the filename in 0.10-2
Comment 2 Chuck Ebbert 2008-01-24 13:26:05 EST
What additional documentation would you like to see?
Comment 3 John Ellson 2008-01-24 13:59:29 EST
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?
Comment 4 Chuck Ebbert 2008-03-04 14:49:44 EST
(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
the oopses.
Comment 5 Chuck Ebbert 2008-03-28 12:06:50 EDT
*** Bug 439282 has been marked as a duplicate of this bug. ***
Comment 6 Need Real Name 2008-03-28 14:13:47 EDT
> 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.
Comment 7 Arjan van de Ven 2008-03-28 19:37:58 EDT
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 
etc.
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 
information/education.

What do the people on this bug think?
Comment 8 Need Real Name 2008-03-28 20:02:57 EDT
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)
Comment 9 Arjan van de Ven 2008-03-29 01:21:48 EDT
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.


Comment 10 Thorsten Leemhuis 2008-04-06 14:27:37 EDT
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?"
Comment 11 Bug Zapper 2008-05-14 00:52:22 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Michael Ploujnikov 2008-05-22 23:27:01 EDT
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
submitted information:

/var/log/messages:3846:May 21 23:29:44 localhost kerneloops: Submitted 1 kernel
oopses to www.kerneloops.org

(kerneloops-0.10-11.fc9.i386)
Comment 13 Fedora Update System 2008-06-17 15:01:41 EDT
kerneloops-0.11-1.fc9 has been submitted as an update for Fedora 9
Comment 14 Fedora Update System 2008-06-20 15:09:17 EDT
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
Comment 15 Fedora Update System 2008-07-08 22:53:16 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.