Bug 1217687
Summary: | dmidecode can contain non-UTF-8, libvirt generates invalid nodedev XML | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Hansen Tanjung <mht> | ||||||
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | ||||||
Status: | CLOSED DEFERRED | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | unspecified | CC: | agedosier, berrange, clalancette, crobinso, dyuan, itamar, jforbes, laine, libvirt-maint, mzhan, tzheng, veillard, virt-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-11-03 17:12:55 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Hansen Tanjung
2015-05-01 03:17:48 UTC
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. |