Bug 138140 - Discovery does not create valid HARDWARE.conf
Discovery does not create valid HARDWARE.conf
Status: CLOSED DUPLICATE of bug 118154
Product: Red Hat Ready Certification Tests
Classification: Retired
Component: backend (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Rob Landry
Depends On:
  Show dependency treegraph
Reported: 2004-11-04 17:06 EST by Robert Griswold
Modified: 2007-04-18 13:14 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:06:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Griswold 2004-11-04 17:06:00 EST
Description of problem:
After installing Redhat Ready in both AS V3 U2 and ES V3 U2, I have 
discovered that the Discovery phase of the program is not consistent 
in creating a valid HARDWARE.conf file, in the /etc/rhr directory.

This problem results in testing that fails, or testing that passes 
due to no parameters being passed to the tests 
in /usr/share/rhr/test.  Most notably, I have reproduced, three 
times, a HARDWARE.conf file with nothing in it but the "disclaimer".  
In running the NETWORK tests, with no ethX entries to pass, all those 
tests fail.  Furhter, in one instance where the HARDWARE.conf file 
was populated, an erronous "N/A" was added to the descriptor line for 
the STORAGE tests.  This resulted in the storage tests failing 
the "badblocks" test, as one of the passed /dev/$device arguments 
was "N/A".

I was able to debug to the HARDWARE.conf file "un-population" as the 
culprit by stepping through the tests in the /usr/share/rhr/tests 
directory, and seeing that the tests were either being passed nothing 
as arguments (in the NETWORK case), or they were being passed invalid 
arguments (as in the STORAGE case).

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

How reproducible:
Most of the time (sometimes the HARDWARE.conf file is empty, 
sometimes it has bad data in it)

Steps to Reproduce:
1.Install AS, or ES V3 Update 2, with Everything
2.Install Redhat Ready, prep machine for testing (gathering files, 
CDs, blank floppies, etc.)
3.After pre-execution services started (Apache, NFS), start RHR, run 
Discovery, and check HARDWARE.conf in the /etc/rhr directory for 
completeness.  No third-part RPMs are installed in this test scenario.
Actual results:
As described above, the HARDWARE.conf file in the /etc/rhr directory 
is populated with nothing, or has bad data for devices under test.

Expected results:
The HARDWARE.conf file should actually contain the correct number of 
devices found; or if the discovery doesn't work, inform the user that 
issues were found in creating the file.

Additional info:
In trying to debug both failures (in NETWORK and STORAGE), I found 
the lack of reporting capabilities in to the cooresponding error.log 
and output.log files to be agrivating.  Given this is a set of tests 
for use by technicians who are trying to "certify" thier HW with the 
RH products, I would like to see more debug style statments put into 
the test files and scripts.  For instance, the STORAGE tests could 
easily have the $device, $beginning_block, and $ending_block entered 
into one of the above mentioned files, providing the tester valuable 
information for troubleshooting.
Comment 1 Rob Landry 2004-11-10 10:30:45 EST
Problem is hardware.py (used by discovery to describe the
hardware/provided by up2date) requires connection to
xmlrpc.rhn.redhat.com; satisfy this http request (doesn't need
specific info; simply an http server responding will do).

A work around has been committed in a later release (beta available on 
http://people.redhat.com/rlandry/rhr2/updates/ [NOT FOR USE ON REAL
HWCERTS] ).  In addition, a sample hardware.conf has been included in
the docs as discovery is to make things easier not required, manual
generation of hardware.conf is acceptable (and possibly required) in
cases where discovery does not detect everything.

In addition, "-d" is available for debug logging (though it has the
side effect of causing all tests to report failed).

*** This bug has been marked as a duplicate of 118154 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:06:48 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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