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
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 the oopses.
*** 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 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?
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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)
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.