This is an F18 system, which is getting the whole new abrt/gnome-abrt/libreport clump as updates from updates-testing. With the newer libreport - 2.1.3 from updates-testing, or 2.1.4 from koji - trying to report any of my existing reports except the very latest seems to give this kind of result:
[root@vaioz adamw]# abrt-cli report /var/tmp/abrt/oops-2013-03-12-14\:26\:53-2663-2/
Error: no processing is specified for event 'report-cli'
The very latest I have 'works' better (I dunno why my kernel is tainted, but eh):
[root@vaioz adamw]# abrt-cli report /var/tmp/abrt/oops-2013-04-08-15\:00\:19-3824-1/
('report_uReport' completed successfully)
A kernel problem occurred, but your kernel has been tainted (flags:GW). Kernel maintainers are unable to diagnose tainted reports.
jmoskovc says this is a bug in libreport.
Kernel is tainted after the first oops, flags:GW means that there was already oops before this one. So to translate this - only the first oops after the reboot is reportable.
This line: Error: no processing is specified for event 'report-cli' menas that there is actually no action defined for oops when reporting from cli, which IS a bug.
I can't reproduce it, can you please send me the problem directory holding this kernel oops? I have a feeling it's the same cause as the '??' problem - the oops has been detected while the machine was shutting down, so the data is incomplete.
Created attachment 743299 [details]
Note gnome-abrt does detect some oopses as incomplete and print a message to that effect in its GUI, but it does not do so for this one. This one shows up in gnome-abrt as "This problem hasn't been reported to Bugzilla yet, our developers..." and the Report button is active, but clicking it causes nothing to happen.
Ok, after closer look - the problem is incomplete but it seems like it's not because it wasn't fully written (which ABRT is capable of detecting), but it's partially deleted, any idea how this could happen (tmp clean, out of the quota..)
I have 18GB of space available in the / partition, and I don't think any kind of 'cleaning' is done on /var/tmp (I think that's kinda the point of /var/tmp ). So I can't see any my-side explanations of why the report is incomplete, no. Regardless of how it got that way, isn't this an indication that abrt's 'this report is incomplete' check needs to be better?
The problem described in comment #1 is caused by missing type element in the problem directory, I just sent a patch which makes abrt to detect it and prevent user from running the report event on such problem data.
fixed in git
Author: Jiri Moskovcak <email@example.com>
Date: Wed Aug 21 16:13:40 2013 +0200
ignore directories without type element - rhbz#958968
Signed-off-by: Jiri Moskovcak <firstname.lastname@example.org>
Signed-off-by: Jakub Filak <email@example.com>
gnome-abrt-0.3.1-1.fc19,abrt-2.1.7-1.fc19,libreport-2.1.7-1.fc19,satyr-0.9-1.fc19 has been submitted as an update for Fedora 19.
Package gnome-abrt-0.3.1-1.fc19, abrt-2.1.7-1.fc19, libreport-2.1.7-1.fc19, satyr-0.9-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-abrt-0.3.1-1.fc19 abrt-2.1.7-1.fc19 libreport-2.1.7-1.fc19 satyr-0.9-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
gnome-abrt-0.3.1-1.fc19, abrt-2.1.7-1.fc19, libreport-2.1.7-1.fc19, satyr-0.9-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.