Bug 827369 - v7/kdump still report PASS if reboot took more than limited time
v7/kdump still report PASS if reboot took more than limited time
Status: CLOSED ERRATA
Product: Red Hat Hardware Certification Program
Classification: Red Hat
Component: Test Suite (tests) (Show other bugs)
1.5
All All
high Severity high
: ---
: ---
Assigned To: Caspar Zhang
Guangze Bai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 05:05 EDT by Caspar Zhang
Modified: 2015-02-08 16:38 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-01 13:20:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kdump patch fixing pass/fail handling (668 bytes, patch)
2012-10-12 12:23 EDT, Greg Nichols
czhang: review+
Details | Diff

  None (edit)
Description Caspar Zhang 2012-06-01 05:05:51 EDT
Description of problem:

If a reboot takes more than 10 minutes, kdump test will display this error, but the whole test still PASS:

<output name="verify">
reboot took 00:16:00
method: panic
kernel: 2.6.32-276.el6.x86_64
Error: reboot took longer that 10 minutes
Attempting to mount net setting gnichols.usersys.redhat.com:/var/www/v7/export as nfs.
Looking for vmcore image directories under v7-net/var/crash
...
Found kdump image: v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore
      KERNEL: /usr/lib/debug/lib/modules/2.6.32-276.el6.x86_64/vmlinux
    DUMPFILE: v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore  [PARTIAL DUMP]
        CPUS: 8
        DATE: Fri Jun  1 04:13:36 2012
      UPTIME: 00:06:34
LOAD AVERAGE: 0.83, 0.50, 0.22
       TASKS: 252
    NODENAME: ibm-ls22-01.rhts.eng.nay.redhat.com
     RELEASE: 2.6.32-276.el6.x86_64
     VERSION: #1 SMP Tue May 29 17:38:19 EDT 2012
     MACHINE: x86_64  (1899 Mhz)
      MEMORY: 16 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
kdump image v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore verified
</output>

....

v7 print --last

....
Test Run 1
----------------------------------------------------------------
....                                                 - 
kdump   nfs                                          - PASS
kdump   local                                        - PASS
....

Version-Release number of selected component (if applicable):
V7-1.5 R25

How reproducible:
always

Steps to Reproduce:
1. make your kdump test reboot longer than 10 minutes
2.
3.
  
Actual results:


Expected results:


Additional info:

Related code:

379     def run(self):
380         PASSED = 0
381         FAILED = 1
382                  
383         if self.incomplete and self.continuation.isInitialized():
384             self.markOutput("verify")
385             result = self.continuation.verify(marker=self.Name()) <--
386             self.continuation.removeInitConfig()
387             if self.continuation.getMethod() == Constants.panic:
388                 result = self.verifyKDumpImage()                  <--
389             self.closeOutput()
390         else:    
391             result = self.panic()
392                  
393         if result: return PASSED


I don't think it will blocker v7-1.5, the log still puts out "FAIL", it just cause some confusion those who needs to check return values... (return value not work in V7-1.4, but no customer complained...)
Comment 1 Greg Nichols 2012-10-12 12:23:26 EDT
Created attachment 626110 [details]
kdump patch fixing pass/fail handling
Comment 7 errata-xmlrpc 2013-02-01 13:20:25 EST
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-0222.html

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