This bug has been copied from bug #583867 and has been proposed to be backported to 5.5 z-stream (EUS).
Fixed in python-dmidecode-3.10.13-1.el5_5.1
Hi, Looking at output from rhn-client-tools - which takes data from python-dmidecode, there are these info on pogolinux-2***: DMI Info Vendor: To Be Filled By O.E.M. System: To Be Filled By O.E.M. Product: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Chassis: To Be Filled By O.E.M. Board: To be filled by O.E.M. Other machines return more informative data. What should return pogolinux from python-dmidecode?
(In reply to comment #8) > Hi, > > Looking at output from rhn-client-tools - which takes data from > python-dmidecode, there are these info on pogolinux-2***: > > DMI Info > Vendor: To Be Filled By O.E.M. > System: To Be Filled By O.E.M. > Product: To Be Filled By O.E.M. > Asset Tag: To Be Filled By O.E.M. > Chassis: To Be Filled By O.E.M. > Board: To be filled by O.E.M. > > Other machines return more informative data. > What should return pogolinux from python-dmidecode? It should probably return exactly what you are seeing. Those strings are taken out of the DMI tables directly. I'm even guessing you'll find these strings in clear text in the DMI dump from this box, if you use strings or hexdump -C on it. I presume the reason is that this box is a so called 'white label box', kind of like a prototype and not a typical mass-produced sales model. The BIOS on such boxes are therefore not "complete", but "complete enough" to boot a system to be able to test it out.
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-2010-0695.html