Bug 1384195
Summary: | dmidecode failing with rhel7.3 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Frank Ramsay (HPE) <framsay> | ||||||||
Component: | dmidecode | Assignee: | Petr Oros <poros> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Mike Gahagan <mgahagan> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 7.3 | CC: | framsay, framsay, gbeshers, gbeshers, gcase, jherrman, jkachuck, jszczype, lknipper, massimiliano.torromeo, mgahagan, poros, randerso, rja, tee | ||||||||
Target Milestone: | rc | Keywords: | OtherQA, Regression, ZStream | ||||||||
Target Release: | 7.4 | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | dmidecode-3.0-3.el7 | Doc Type: | Bug Fix | ||||||||
Doc Text: |
Previously, the dmidecode utilities failed to extract hardware information from the BIOS or the Extensible Firmware Interface (EFI). This update fixes the underlying source code, and dmidecode now work as expected.
|
Story Points: | --- | ||||||||
Clone Of: | |||||||||||
: | 1401905 (view as bug list) | Environment: | |||||||||
Last Closed: | 2017-08-01 17:53:36 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 1366034, 1394638, 1401905, 1404314, 1446211 | ||||||||||
Attachments: |
|
Description
Frank Ramsay (HPE)
2016-10-12 19:10:05 UTC
Created attachment 1209734 [details]
Patch that resolves issue.
this looks like a regression; because 7.2 returns this: [root@grommit ~]# dmidecode -s chassis-type Rack Mount Chassis [root@grommit ~]# dmidecode -s system-serial-number UV3000------ [root@grommit ~]# rpm -q dmidecode dmidecode-2.12-9.el7.x86_64 [root@grommit ~]# uname -a Linux grommit.engr.sgi.com 3.10.0-327.100hz.el7.x86_64 #1 SMP Wed Dec 16 10:27:50 EST 2015 x86_64 x86_64 x86_64 GNU/Linux [root@grommit ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo) And 7.3 returns this. [root@cb13 ~]# dmidecode -s chassis-type Main Server Chassis Invalid entry length (16). Fixed up to 11. [root@cb13 ~]# Hi Frank, Please, can you provide full output from latest dmidecode and binary dump of your dmi table by these commands: $ dmidecode $ dmidecode --dump-bin Thanks, -Petr Created attachment 1218013 [details]
output from dmidecode dump-bin
attached output from dmidecode dump-bin
Created attachment 1218014 [details]
output from dmidecode
attached full output from dmidecode.
providing QA ack as an OtherQA bug. Hey guys, is there any update on this? -frank Hello, This bug has been copied as 7.3 z-stream (EUS) bug #1401905 Thank You Joe Kachuck Getting ready for OnBoarding first week of January. Tested on multiple machines inside SGI. Sorry for the noise. Its much improved but the serial number field still has an issue. Just to add to George's comment. on sgi-uv300-02.rhts # rpm -qa | grep dmidecode python-dmidecode-3.10.13-11.el7.x86_64 dmidecode-3.0-3.el7.x86_64 chassis-type returns good # dmidecode -s chassis-type Rack Mount Chassis but system-serial-number is wrong. # dmidecode -s system-serial-number UV3-------- # cat /proc/sgi_uv/system_serial_number UV300-00000233 I'll leave this system up if you want to test this. pwd 100yard- Marking "FailedQA" as per comment 20 (system serial number is not being reported correctly) #comment 21: This is not bug in dmidecode poros@holly$ ./dmidecode -t1 --from-dump /maintain/dmidecode-bin/UV300.bin # dmidecode 3.0 Reading SMBIOS/DMI data from file /maintain/dmidecode-bin/UV300.bin. SMBIOS 2.7 present. Handle 0x0028, DMI type 1, 27 bytes System Information Manufacturer: SGI Product Name: UV300 Version: SGI Serial Number: UV3-------- ^^^^^^^^^^^^^^^WRONG SERIAL NUMBER^^^^^^^^^^ UUID: 8B2C9555-5C8E-4221-BF48-DFF302443042 Wake-up Type: Power Switch SKU Number: Not Specified Family: Server poros@holly$ ./dmidecode -t2 --from-dump /maintain/dmidecode-bin/UV300.bin # dmidecode 3.0 Reading SMBIOS/DMI data from file /maintain/dmidecode-bin/UV300.bin. SMBIOS 2.7 present. Handle 0x0029, DMI type 2, 17 bytes Base Board Information Manufacturer: Silicon Graphics International Product Name: UV300 Version: 5 Serial Number: UV300-00000233 ^^^^^^^^^^^^^^^RIGHT SERIAL NUMBER^^^^^^^^^^ Asset Tag: Base Board Asset Tag Features: Board is a hosting board Board is replaceable Location In Chassis: Part ComponentEnglish Chassis Handle: 0x0000 Type: Unknown Contained Object Handles: 0 poros@holly$ hexdump -C /maintain/dmidecode-bin/UV300.bin | grep UV3 00000cb0 df f3 02 44 30 42 06 05 06 53 47 49 00 55 56 33 |...D0B...SGI.UV3| 00000cc0 30 30 00 53 47 49 00 55 56 33 2d 2d 2d 2d 2d 2d |00.SGI.UV3------| 00000d10 6e 61 74 69 6f 6e 61 6c 00 55 56 33 30 30 00 35 |national.UV300.5| 00000d20 00 55 56 33 30 30 2d 30 30 30 30 30 32 33 33 00 |.UV300-00000233.| For command "dmidecode -s system-serial-number": dmidecode using Type1 -> system serial number UV300-00000233 is baseboard serial number (Type2) That means, dmidecode doing proper work, bogus is dmi data on system In light of comment 23 I'd say this is good to go in HPE's (was SGI) view. 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. https://access.redhat.com/errata/RHBA-2017:1858 It's fine to consider this as an issue with the dmi data but shouldn't the error message be printed on stderr? The current behaviour is causing other tools using dmidecode to stop working correctly as they pick up the error message as part of the system informations. |