Bug 814594
| Summary: | too strict check for tainted kernel | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | David Jaša <djasa> | ||||
| Component: | abrt | Assignee: | Jiri Moskovcak <jmoskovc> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Lukáš Zachar <lzachar> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.3 | CC: | dfediuck, dkutalek, dvlasenk, jmoskovc, mnowak, nobody+abrt-devel-list, rvokal | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 6.3 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | abrt-2.0.8-7.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-21 07:53:29 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
David Jaša
2012-04-20 07:37:14 UTC
Created attachment 578911 [details]
dmesg
Looking into dmesg once more and better, it seems that:
1. kernel throws the initial warning
2. kernel throws the same warning again and declares itself tainted
3. abrt merges the two warnings
4. abrt chooses to ignore the warnings because one of them is tainted
given this, I'd opt for "not tainted is higher priority of duplicate reports" approach and offer user to submit/debug that.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. I think this one is fixed by this commit in rhel6 git branch:
commit 8b0956286967e92bd68c04eb4e051225f00fce44
Author: Jiri Moskovcak <jmoskovc>
Date: Thu Jul 12 11:24:39 2012 +0200
oops: don't create oops dir in reverse rhbz#814594
when kernel starts printing oops, only very first one is not tainted.
If we start in reverse, it will firstly create direcotry with tainted oops
and others will be deleted as dup of first one (if there are same), thus
we loose NOT tainted oops.
Signed-off-by: Nikola Pajkovsky <npajkovs>
During the searching how to reproduce the problem the fix itself was questioned. Here is the IRC log of the communication with Denys: lzachar: I've managed to reproduce it once - but I can't do it again. When I run abrt-dump-oops -D dmesg both old and new make three ooops-dirs lzachar: I remember that on that one "successful" reproduction it was just one oops directory lzachar: old version is abrt-2.0.8-5.el6.x86_64 (same as in that bug report) dvlasenk: abrt-dump-oops does not refise to create problem dirs if it sees a tainted oops dvlasenk: It just adds kernel_tainted_short and kernel_tainted_long elements to the problem dir lzachar: ah. any tips how can reproduce the problem then? dvlasenk: You can check whether these elements (files) are properly created in the problem dirs. lzachar: well, there are - 2 tainted and 1 not tainted lzachar: but the same holds true for the old version as well dvlasenk: And the problem is ... ? lzachar: according to the bug report, there was a case when tainted made the not tainted one to be lost lzachar: so the user was not allowed to report lzachar: I would like to be able to reproduce that, so I can see that is was fixed lzachar: there is a difference in the order of writing the oopses dvlasenk: Understood dvlasenk: abrt-dump-oops doesn't do dup elimination lzachar: (which was your patch I believe) lzachar: any service I could run? lzachar: so it will do that dvlasenk: It is done on the post-create step IIRC (that is, by abrtd) dvlasenk: This part of the config triggers it in koops_event.conf: dvlasenk: EVENT=post-create analyzer=Kerneloops dvlasenk: # >> instead of > is due to bugzilla.redhat.com/show_bug.cgi?id=854266 dvlasenk: abrt-action-analyze-oops && dvlasenk: dmesg >>dmesg && dvlasenk: abrt-action-generate-core-backtrace dvlasenk: abrt-action-save-kernel-data dvlasenk: hmm dvlasenk: I'm not sure we in fact check for that case, and it still can happen dvlasenk: (It wasn't happening because in the past post-creates were never running concurrently) dvlasenk: Perhaps you need to repoen that bug :( My mistake, it can be (easily) reproduced. Moving back to ON_QA. Cause When a multiple kernel oops happens in a short period of time ABRT only the first one is relevant, because the later oopses might be just consequences of the first problem. ABRT was wrongly sorting the processed oopses, so it saved the last oops instead of the first one. Consequence The most important first oops never got into problem report. Fix Fixed the processing order. Result In case of processing more oops at the same time the first one is correctly saved NOTE: this is the CCFR as for 808721, because these bzs have actually the same fix Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0290.html |