RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
The python-dmidecode returns empty dicts instead of the expected information and raises some odd warnings on exit. The dmidecode itself works well.

Version-Release number of selected component (if applicable):
python-dmidecode-3.12.2-1.el7.aarch64

How reproducible:
Always

Steps to Reproduce:
python
Python 2.7.5 (default, May  3 2017, 08:00:59) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import dmidecode
>>> dmidecode.bios()

Actual results:
{}
>>> 

** COLLECTED WARNINGS **
/sys/firmware/efi/systab: SMBIOS entry point missing
No SMBIOS nor DMI entry point found, sorry.
Permission denied to memory file/device (/dev/mem)
Permission denied to memory file/device (/dev/mem)
** END OF WARNINGS **

Expected results:
dict with the data available from `dmidecode`

Additional info:
The `dmidecode` works well on that machine:

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x4FF79E0000.

Handle 0x0000, DMI type 7, 19 bytes
Cache Information
        Socket Designation: L1-Cache
        Configuration: Enabled, Socketed, Level 1
...

This would be due to access to /dev/mem is only allowed on x86. I think /sys/firmware/dmi is the proper pseudofile to use.

The /sys/firmware/dmi tree is actually a series of files, one per DMI type, that make parsing much easier.  For example:

[root@hp-moonshot-03-c01 ~]# strings /sys/firmware/dmi/entries/1-0/raw
\jKY
ProLiant m400 Server
CN7506VB0T
721717-B21
ProLiant


[root@hp-moonshot-03-c01 ~]# strings /sys/firmware/dmi/entries/4-0/raw
`	`	A
Proc 1
AppliedMicro
X-Gene

see bug 1456956, "/dev/mem" is disabled for aarch64. It doesn't try to read "/sys/firmware/dmi/tables/DMI" and "/sys/firmware/dmi/tables/smbios_entry_point".

(In reply to lijiang from comment #4)
> see bug 1456956, "/dev/mem" is disabled for aarch64. It doesn't try to read
> "/sys/firmware/dmi/tables/DMI" and
> "/sys/firmware/dmi/tables/smbios_entry_point".

In addition, Our previous submission of patch has never responded, and it looks like the upstream doesn't maintain the project(python-dmidecode). So i recommend dmidecode.