Red Hat Bugzilla – Bug 235621
Dellsysidplugin crashes yum
Last modified: 2007-11-30 17:12:01 EST
Description of problem:
The Dellsysidplugin plugin crashes yum with the error below.
Version-Release number of selected component (if applicable):
Always. Regardless of the arguments to yum, loading the plugin crashes it.
Python crashes with the following:
$ yum update
Loading "installonlyn" plugin
Loading "dellsysidplugin" plugin
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
File "/usr/share/yum-cli/yummain.py", line 82, in main
File "/usr/share/yum-cli/cli.py", line 206, in getOptionsConfig
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 141, in
File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run
func(conduitcls(self, self.base, conf, **kwargs))
File "/usr/lib/yum-plugins/dellsysidplugin.py", line 26, in init_hook
sysid = getSystemId()
File "/usr/lib/python2.4/site-packages/biosHdr.py", line 34, in getSystemId
output = cmdFactory_getSystemId()
File "/usr/lib/python2.4/site-packages/biosHdr.py", line 27, in
raise PermissionDenied("Failed to get System ID: %s" % output)
biosHdr.PermissionDenied: Failed to get System ID: Libsmbios: 0.13.5
Error getting the System ID : Could not instantiate SMBIOS table.
Error getting the Service Tag : Could not instantiate SMBIOS table.
Error getting the Product Name: Could not instantiate SMBIOS table.
Error getting the BIOS Version: Could not instantiate SMBIOS table.
Error getting the Vendor : Could not instantiate SMBIOS table.
Is Dell: 0
the sysid plugin needs to be root to access the system id. I'll add an exception
check to zero out this information if it cannot access system id.
Checking sources, this bug was fixed in the already-released 1.2.10 version.
Looking at this, I based on proposed fedora policy, I switched to arch-specific
packages for this version, and it doesnt look like yum is upgrading from noarch
I've documented the yum bug in:
I've also created a noarch upgrade package with the latest codebase in order to
fix this problem for people who might have the older package installed.
This will be fixed in the next fedora extras push. I recommend that you remove
and re-install in order to get the .i386|x86_64 package, though.
1.2.10 is now available in Fedora Extras, and the bug is resolved. However, the
noarch (1.2.6) version is also in Fedora Extras... is this intended?
The fedora scripts dont automatically remove old noarch pkgs when the pkg is
converted to arch-specific. I'll have to submit a request to have it removed. In
the meantime, I've built an upgrade to 1.2.11 for the noarch version so that
nobody else accidentally hits this. It is currently waiting to be signed and
should be in the repo shortly.