Bug 1315435 Submitted. Let me know if there's anything else I can do to help.
On Mon, Mar 7, 2016 at 12:04 PM, Dan Kenigsberg <[email protected]> wrote: > On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman wrote: > > The SMBIOS settings were indeed indeed the issue that was blocking me. I > > investigated how to configure the SMBIOS settings and now restore-nets > > works, and I'm getting past where I was failing on the hosted-engine > > --deploy. > > > > FYI, I had to download the "Intel Integrator Toolkit" (which is now EOL) > > and create a custom BIOS to add those settings in for my system, which is > > an Intel NUC DN2820FYKH. > > > > I am happy to back this out and test any changes if you'd like, but this > > has gotten me to where I can continue oVirt testing for now. I'll likely > > be reinstalling a few times along the way to polish my documentation, so > > let me know if you want me to revert my BIOS and test anything. > > > > Thanks all! > > -js > > > > On Mon, Mar 7, 2016 at 11:22 AM, Martin Polednik <[email protected]> > > wrote: > > > > > On 07/03/16 11:09 -0500, Jonathan Sherman wrote: > > > > > >> Thanks for your time on this Dan! > > >> > > >> The output from the hostdev looks like it may be unparseable, so I'm > > >> hoping > > >> this is the issue (and that it can be easily remedied). > > >> > > >> I've also create a log of the other items you asked for, available at: > > >> https://www.dropbox.com/s/qh0yw1ptpivpatm/typescript?dl=0 > > >> > > >> [root@ovirt01 vdsm]# vdsm-tool restore-nets > > >> <device> > > >> <name>computer</name> > > >> <capability type='system'> > > >> <product>���������������������������������</product> > > >> <hardware> > > >> <vendor>���������������������������������</vendor> > > >> <version>���������������������������������</version> > > >> <serial>���������������������������������</serial> > > >> <uuid>d6a3e3c1-c5cb-42e9-a54c-ff8d0df91722</uuid> > > >> </hardware> > > >> <firmware> > > >> <vendor>Intel Corp.</vendor> > > >> <version>FYBYT10H.86A.0052.2015.0923.1845</version> > > >> <release_date>09/23/2015</release_date> > > >> </firmware> > > >> </capability> > > >> </device> > > >> > > > > > > That seems to be the issue. Even bigger issue is that we can > > > not skip this device easily, as it is the root of device tree and must > > > be present in database. > > > > > > I can think of logging the exception but letting the call go through > > > and create a hook to fake a (minimal) device tree. Dan, what do you > think? > > > But why isn't this a valid xml, Martin? I suspect that we need to > utf-8-decode nodedev-xml before using them in Vdsm, similar to what we > do with domain-xml? (consider Klingon characters in the <vendor> > element). > > In any case, this issue merits a bug - could you open it, Jonathan, and > attach relevant data to it? > > Regards, > Dan. >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
