| Summary: | FV_CORE INFO test fails because sosreport expects user response | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Hardware Certification Program | Reporter: | Gary Smith <gasmith> | ||||
| Component: | Test Suite (tests) | Assignee: | Greg Nichols <gnichols> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Guangze Bai <gbai> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 1.2 | CC: | czhang, gbai, rlandry, yshao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-06-05 21:35:40 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 767775, 773757 | ||||||
| Attachments: |
|
||||||
What guest image are they using on which RHEL? 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. 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 ;-) (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. @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 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")
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. We may want to split of a separate distribution bug for updating the images to a later RHEL5 release. Created attachment 570019 [details]
info test patch adding --batch to sosreport
The above patch will need to be distributed in FV data images in the form the v7 rpm.
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.
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 |
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