Created attachment 1020789 [details] Output of "virsh nodedev-dumpxml computer" Description of problem: My motherboard have a mal formated BIOS output and libvirt can't handle it. Attached nodedev and dmi of my computer. Phyton error message: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 230, in _reparse_xml self._xmlobj = self._build_xmlobj(self._get_raw_xml()) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 233, in _build_xmlobj return self._parseclass(self.conn.get_backend(), parsexml=xml) File "/usr/share/virt-manager/virtManager/nodedev.py", line 27, in _parse_convert return NodeDevice.parse(conn, parsexml) File "/usr/share/virt-manager/virtinst/nodedev.py", line 92, in parse tmpdev = NodeDevice(conn, parsexml=xml, allow_node_instantiate=True) File "/usr/share/virt-manager/virtinst/nodedev.py", line 101, in __init__ XMLBuilder.__init__(self, *args, **kwargs) File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 781, in __init__ parent_xpath, relative_object_xpath) File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 683, in __init__ self._parse(parsexml, parsexmlnode) File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 696, in _parse doc = libxml2.parseDoc(xml) File "/usr/lib64/python2.7/site-packages/libxml2.py", line 1325, in parseDoc if ret is None:raise parserError('xmlParseDoc() failed') parserError: xmlParseDoc() failed Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Open virt-manager with debug parameter 2. Python will produce error message related to xmlParsedDoc Actual results: Virt-manager can't add additional virtual hardware Expected results: Virt-manager running normally Additional info: Related to bug #1184131
Created attachment 1020790 [details] Output of dmidecode
Thanks Hansen. Okay, here's the error, it's due to utf-8 data: $ python -c 'import libxml2; libxml2.parseDoc(file("nodedev").read())' Entity: line 4: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0xFF 0xFF 0xFF <product>��������U310����</product> ^ Traceback (most recent call last): File "test.py", line 3, in <module> libxml2.parseDoc(file("nodedev").read()) File "/usr/lib64/python2.7/site-packages/libxml2.py", line 1327, in parseDoc if ret is None:raise parserError('xmlParseDoc() failed') libxml2.parserError: xmlParseDoc() failed
err, that is, it's due to the text _not_ being UTF data (need to find a way to get that error message in the virt-manager logs) this also makes me wonder... I wonder if the ascii sanitizer patches can mangle utf-8 data? maybe we need to look into using glibc's iconv API to sanitize utf-8 instead. example from the command line, hopefully not difficult to map to direct API usage: iconv -f utf-8 -t utf-8 -c file.txt
Thanks for your quick replay. Here is the background story :-) When this laptop is new, everything seems normal, BIOS info is normal, none of the character is garbage. Until I notice there is something wrong with motherboard: CPU usage always busy, being with Fedora or preinstalled Windows 7. I sent this laptop to service center and get motherboard replacement. CPU usage back to normal, but BIOS info get a garbage character, like the one at the attachment. I think it is just me until I'm filling the first report and see another person got the same problem. Maybe this faulty motherboard is common for U310 or U410, and I think this is a small (very very small maybe) case. So, I really apreciate your effort to fix this problem for very very small users :-)
You're welcome :) Even if screwed up hardware fixes this, libvirt shouldn't be generating broken XML, so this highlighted a bigger problem that could bite us in other ways, so it's good to get this fixed
virt-manager has a patch to workaround this, but I forgot to backport it to F21 on the last update. I added a bug to track the backport: https://bugzilla.redhat.com/show_bug.cgi?id=1217912 Hansen, if you want virt-manager to work, you can grab a newer version with the fedora-virt-preview repo that has the workaround: https://fedoraproject.org/wiki/Virtualization_Preview_Repository
Dindn't see update for virt-manager at fedora-virt-preview yet, just update for libvirt, maybe I try letter
(In reply to Hansen Tanjung from comment #7) > Dindn't see update for virt-manager at fedora-virt-preview yet, just update > for libvirt, maybe I try letter What virt-manager version do you have installed?
(In reply to Cole Robinson from comment #8) > What virt-manager version do you have installed? $ virt-manager --version 1.1.0
please provide: rpm -q virt-manager virt-preview should have virt-manager-1.1.0-7.git6dbe19bd8.fc21 which has the workaround patch that I think will fix things for you
(In reply to Cole Robinson from comment #10) > please provide: rpm -q virt-manager > > virt-preview should have virt-manager-1.1.0-7.git6dbe19bd8.fc21 which has > the workaround patch that I think will fix things for you Oh sorry, this from rpm command: $ rpm -q virt-manager virt-manager-1.1.0-8.git310f6527.fc21.noarch Still not fixed. From Koji Changelog: * Mon Apr 20 2015 Cole Robinson <crobinso> - 1.1.0-8.git310f6527 - Fix domcapabilities regression in previous build * Sat Apr 18 2015 Cole Robinson <crobinso> - 1.1.0-7.git310f6527 - Fix 'new vm' regression in the previous build I think not yet incorporated the fix you mention.
oh there's a version number problem here... the version you have is from F21, but even though RPM decodes the version number as being new, the _actual_ latest version is the virt-preview version I mentioned. This will be fixed soon when I push a new virt-manager 1.2.0 to F22, but you can do this in the meantime: sudo yum remove virt-manager-common sudo yum --disablerepo=updates --disablerepo=fedora --enablerepo=fedora-virt-preview install virt-manager virt-install Verify that the second command wants to install the package I in Comment #10, which should hopefully work around your issue
Thanks a lot, that's work :-) Should I close this or wait for your update at regular F21 update channel?
We want this bug to keep tracking the new fix for libvirt (which doesn't exist yet) https://bugzilla.redhat.com/show_bug.cgi?id=1217912 will track backporting the virt-manager fix. So, nothing to do for now
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I believe this is still relevant on upstream libvirt
Still relevant, and yes we need to use iconv or some other API to sanitize the utf-8, since the data we are getting is completely bogus. iconv may error on the bogus data, in which case maybe it's better to just return an empty string Either way, moving to the upstream tracker since this doesn't have much effect these days, with the virt-manager work around
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.