Bug 687990 - FV_CORE INFO test fails because sosreport expects user response
Summary: FV_CORE INFO test fails because sosreport expects user response
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Hardware Certification Program
Classification: Retired
Component: Test Suite (tests)
Version: 1.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Greg Nichols
QA Contact: Guangze Bai
URL:
Whiteboard:
Depends On:
Blocks: 767775 773757
TreeView+ depends on / blocked
 
Reported: 2011-03-15 23:28 UTC by Gary Smith
Modified: 2015-02-08 21:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In v7 1.5, a bug has been fixed that `sosreport` command will not be blocked when running `info` test in HVM guests.
Clone Of:
Environment:
Last Closed: 2012-06-05 21:35:40 UTC


Attachments (Terms of Use)
info test patch adding --batch to sosreport (768 bytes, patch)
2012-03-14 15:39 UTC, Greg Nichols
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0711 0 normal SHIPPED_LIVE v7 bug fix and enhancement update 2012-06-06 01:26:37 UTC

Description Gary Smith 2011-03-15 23:28:18 UTC
Description of problem:

During running of the INFO test for FV_CORE on an HVM guest, for some reason sosreport reports that:

"* one or more processes are in state D (sosreport might hang)" 
...
One or more plugins have detected a problem in your configuration.
Please review the following messages:


Are you sure you would like to continue (y/n) ? Are you sure you would like to continue (y/n) ? Are you sure you would like to continue (y/n) ? Traceback (most recent call last):
File "/usr/sbin/sosreport", line 780, in ?
sosreport()
File "/usr/sbin/sosreport", line 596, in sosreport
yorno = raw_input( _("Are you sure you would like to continue (y/n) ? ") )
EOFError: EOF when reading a line

..which leads to a FAIL:

<summary>FAIL</summary>
</output>
...finished running ./info.py, exit code=1
</output>

Whilst it's questionable as to why there are processes in D state, this shouldn't FAIL the successful FV_CORE test itself.

Version-Release number of selected component (if applicable):
v7-1.2-25

Comment 1 Rob Landry 2011-03-16 15:42:55 UTC
What guest image are they using on which RHEL?

Comment 2 Gary Smith 2011-03-16 15:53:17 UTC
Apologies, I should have added this info:

host:      Red Hat Enterprise Linux Server release 6.0 (Santiago)
guest:     Red Hat Enterprise Linux Server release 5.3 (Tikanga)
HCL:       https://hardware.redhat.com/show.cgi?id=681490
info fail: https://hardware.redhat.com/results.cgi?cert_id=681490&id=225891

sysreport from FV_CORE that subsequently passed INFO:
https://hardware.redhat.com/sysreport.cgi?cert_id=681490&id=205276

I'm requesting FJ confirm exactly which guest image they used.

Comment 3 Rob Landry 2011-07-01 17:05:43 UTC
Gary, any update on this.  If there is something we need to fix I'd like to get it scheduled into a release.  If not, it'd be nice to clean up the queue ;-)

Comment 4 Gary Smith 2011-07-01 17:25:45 UTC
(In reply to comment #3)
> Gary, any update on this.  If there is something we need to fix I'd like to get
> it scheduled into a release.  If not, it'd be nice to clean up the queue ;-)

Let me dig through my notes and come back to you on Monday.

Comment 5 Gary Smith 2011-07-04 10:32:47 UTC
@rob


FTS stated that the were the same guest images as used for all other cert runs before, and always from the same internal server.

Server listing:

1190685   8516 -rw-r--r--. 1 root root   8716660 Nov 30 11:47 v7data.img.tar.bz2
1190686 240948 -rw-r--r--. 1 root root 246727651 Nov 30 11:47 v7i386.img.tar.bz2
1190687      4 -rw-r--r--. 1 root root       438 Nov 30 11:47 v7i386.tar.bz2
1190688 275080 -rw-r--r--. 1 root root 281679995 Nov 30 11:47 v7x86_64.img.tar.bz2
1190689      4 -rw-r--r--. 1 root root       444 Nov 30 11:47 v7x86_64.tar.bz2

From the SUT:

[root@rx600s4 /]# ls -lisa ./var/lib/libvirt/images/v7*.img
4203240  102400 -rwxr-xr-x. 1 root root  104857600 Mar 16 11:22 ./var/lib/libvirt/images/v7data.img
4203249 6291464 -rwxr-xr-x. 1 root root 6442450945 Mar 16 11:22 ./var/lib/libvirt/images/v7x86_64.img

[root@rx600s4 /]# md5sum /var/lib/libvirt/images/*.img
788b71bd90db4ccd768b8fb029347d7a  /var/lib/libvirt/images/v7data.img
287364223f933ee109ed20502fbb9fce  /var/lib/libvirt/images/v7x86_64.img

Comment 6 Gary Smith 2011-09-26 21:45:49 UTC
A quick look at the sosreport code shows that using the "--batch" option would stop it throwing up interactive warnings during the run, but would still log the results of all plugin.diagnose functions.

Line 670 of sosreport.py:

if not GlobalVars.__cmdLineOpts__.batch:
                try:
                    while True:
                        yorno = raw_input( _("Are you sure you would like to " \
                                             "continue (y/n) ? ") )
                        if yorno == _("y") or yorno == _("Y"):
                            print
                            break
                        elif yorno == _("n") or yorno == _("N"):
                            doExit(0)

...which could be added to these lines in info.py:

result = self.__processSystemReport("sosreport -n selinux --no-progressbar")
and
result = self.__processSystemReport("sosreport -n selinux")

Comment 7 Gary Smith 2011-09-26 22:12:15 UTC
The earlier sosreport 1.7-9.16.el5 from RHEL5.3 didn't have the above batch option, but instead used the "isUnattended" value to skip interactive warnings from diagnose_msgs.

For these we could call sosreport with --name and --ticket-number options set to  force 'isUnattended' to be used.

And, as discussed, updating the images to later RHEL5 releases would also help.

Comment 8 Greg Nichols 2012-01-17 20:25:07 UTC
We may want to split of a separate distribution bug for updating the images to a later RHEL5 release.

Comment 9 Greg Nichols 2012-03-14 15:39:25 UTC
Created attachment 570019 [details]
info test patch adding --batch to sosreport

Comment 10 Greg Nichols 2012-03-14 15:40:54 UTC
The above patch will need to be distributed in FV data images in the form the v7 rpm.

Comment 15 Caspar Zhang 2012-06-04 07:08:01 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
In v7 1.5, a bug has been fixed that `sosreport` command will not be blocked when running `info` test in HVM guests.

Comment 17 errata-xmlrpc 2012-06-05 21:35:40 UTC
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-2012-0711.html


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