On Thu, Oct 13, 2016 at 12:29 PM, David Pinkerton <dpink...@redhat.com> wrote: > Good News. > > I installed the fedora 24 version of python-dmidecode and was able to > successfully add the host to my cluster... > > Thanks you to everyone who looked at this. I owe you a beer or at least > some reward points :-)
You owe us a rhel bug for dmidecode :-) Program received signal SIGSEGV, Segmentation fault. dmi_set_vendor (s=0x0) at src/dmioem.c:45 45 if(strcmp(s, "HP") == 0) s is a null, cannot work with strcmp (gdb) thread apply all bt full Thread 1 (Thread 0x7ffff7feb740 (LWP 6318)): #0 dmi_set_vendor (s=0x0) at src/dmioem.c:45 __s1 = 0x0 __result = <error reading variable __result (Cannot access memory at address 0x0)> #1 0x00007fffead5f66f in dmi_table (logp=logp@entry=0xaa70e0, type=type@entry=1, base=<optimized out>, len=<optimized out>, num=<optimized out>, ver=<optimized out>, devmem=devmem@entry=0x7fffead645e0 "/dev/mem", xmlnode=xmlnode@entry=0x6e5420) at src/dmidecode.c:4902 next = <optimized out> h = {type = 0 '\000', length = 252 '\374', handle = 13, data = 0xa4f4aa ""} It look like the code is trying to get the vendor name from type 0. The fact that this leads to sending null vendor string is a second bug. I believe dmidecode is missing this upstream patch: https://github.com/nirs/dmidecode/commit/6e3a3f3cd36f633a56437b42e40d6769ad8acfe7 Nir > On Thu, Oct 13, 2016 at 7:28 PM, Martin Polednik <mpoled...@redhat.com> > wrote: >> >> On 13/10/16 09:01 +0300, Dan Kenigsberg wrote: >>> >>> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote: >>>> >>>> Nir, >>>> >>>> Looks like its crashing on the dmidecode system call. >>>> >>>> I've attached the output from gbd as well as a dmidecode text dump, >>>> dmidecode binary dump and each keywords run individually. >>>> >>>> >From the keywords it look like my dmi info is corrupted. I have >>>> download a >>>> AMI dmi editor but this only allows access to limited fields. Do you >>>> know >>>> another tools to rewrite the dmi info? >>> >>> >>> I don't. But whatever is inside your dmi, dmidecode must not crash. >>> Which version of python-dmidecode do you have installed? >>> Would you open a bug against it? >> >> >> This is really unfortunate - I've reproduced the issue with the >> attached dump and it's python-dmidecode that crashes. The issue is >> actually fixed upstream, but the version at least in RHEL does not >> contain the fix. >> >> RHEL version: >> python-dmidecode-3.10.13-11.el7.x86_64 >> >> works with (actual upstream): >> python-dmidecode-3.12.2-1.el7.x86_64 >> (actually it's ~6 line change in dmioem.c) >> >> VDSM output: >> # vdsClient 0 getVdsHardwareInfo >> systemFamily = 'To Be Filled By O.E.M.' >> systemManufacturer = 'Supermicro' >> systemProductName = 'H8DM8-2' >> systemSerialNumber = '1234567890' >> systemUUID = '00020003-0004-0005-0006-000700080009' >> systemVersion = '1234567890' >> >> Although the upstream version of python-dmidecode is able to deal with >> improper DMI tables, I can't say what else will/will not behave correctly. >> >> mpolednik >> >> >>> I believe that its maintainers would appriace a simple reproducer, that >>> does not involve ovirt or Vdsm. See if you can simplify the code in >>> >>> def __leafDict(d): >>> ret = {} >>> for k, v in d.iteritems(): >>> if isinstance(v, dict): >>> ret.update(__leafDict(v)) >>> else: >>> ret[k] = v >>> return ret >>> >>> >>> def getAllDmidecodeInfo(): >>> import dmidecode >>> >>> myLeafDict = {} >>> for k in ('system', 'bios', 'cache', 'processor', 'chassis', >>> 'memory'): >>> myLeafDict[k] = __leafDict(getattr(dmidecode, k)()) >>> return myLeafDict >>> _______________________________________________ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users > > > > > -- > > David Pinkerton > Consultant > Red Hat Asia Pacific Pty. Ltd. > Level 11, Canberra House > 40 Marcus Clarke Street > Canberra 2600 ACT > > Mobile: +61-488-904-232 > Email: david.pinker...@redhat.com > Web: http://apac.redhat.com/ > > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users