Bug 460940 - 'hts discover' is using the BIOS manufacturer name for the system manufactuer
'hts discover' is using the BIOS manufacturer name for the system manufactuer
Status: CLOSED ERRATA
Product: Red Hat Hardware Certification Program
Classification: Red Hat
Component: Test Suite (harness) (Show other bugs)
5.2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Greg Nichols
Lawrence Lim
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-02 14:36 EDT by Mike Carvin
Modified: 2014-03-25 20:55 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: ======= BIOS manufacturer might not always be the machine manufacturer. Consequence: ============ Test suite reports in-correct machine manufacturer. Fix: ==== Changed the vendor key from "Vendor" to "Manufacturer". Result: ======= Correct machine manufacturer will be reported.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-27 12:34:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hardwaretest.py patch changing the vendor key from "Vendor" to "Manufacturer" (570 bytes, patch)
2009-06-12 17:27 EDT, Greg Nichols
no flags Details | Diff

  None (edit)
Description Mike Carvin 2008-09-02 14:36:00 EDT
(See also Issue-Tracker #216956)

Description of problem: 
Running 'hts discover' seems to assume that the BIOS manufacturer is also the system manufacturer, as that is what gets put into the config.xml.

How reproducible:
Happens every time

Steps to Reproduce:
1. Run 'hts discover' on a Stratus ftServer (or presumably any system with a different manufacturer than the BIOS)

Actual results:
For the Stratus ftServer, the system manufacturer as written to config.xml is "Phoenix Technologies LTD", who isn't actually the system manufacturer.

Expected results:
I would have expected the system manufacturer to be "Stratus Technologies"

Additional info
Comment 1 Greg Nichols 2008-09-08 12:45:48 EDT
Would it be better if we changed it to have the user verify the information 
after we get it from BIOS?
Comment 2 Rob Landry 2008-09-08 12:51:39 EDT
Possibly both.  I understand the question of the BIOS maker is almost never the same as the system maker; however most vendors change that field when they build their BIOS from the kit.  We should investigate if there is a better product field provided by dmidecode (there may not be).  For the best user experience we're probably best off using the dmidecode data to pre-populate a confirmation field which would be the same as the one where dmidecode isn't present on the arch?
Comment 5 Greg Nichols 2009-06-12 17:27:02 EDT
Created attachment 347671 [details]
hardwaretest.py patch changing the vendor key from "Vendor" to "Manufacturer"
Comment 8 Yan Tian 2009-08-13 05:21:10 EDT
v7-1.0-14.el5 doesn't include discover option.
Comment 11 YangKun 2009-08-20 23:28:13 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Cause:
=======
BIOS manufacturer might not always be the machine manufacturer.

Consequence:
============
Test suite reports in-correct machine manufacturer.

Fix:
====
Changed the vendor key from "Vendor" to "Manufacturer".

Result:
=======
Correct machine manufacturer will be reported.
Comment 12 errata-xmlrpc 2009-08-27 12:34:08 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1234.html

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