FS#67921 - [libvirt] 6.5.0-2 internal error: Unable to find major for device-mapper
Attached to Project:
Community Packages
Opened by Flo (olfx) - Thursday, 17 September 2020, 18:12 GMT
Last edited by Robin Broda (coderobe) - Sunday, 21 March 2021, 05:32 GMT
Opened by Flo (olfx) - Thursday, 17 September 2020, 18:12 GMT
Last edited by Robin Broda (coderobe) - Sunday, 21 March 2021, 05:32 GMT
|
Details
Description:
With the new package version libvirt-6.5.0-2 i am unable to launch my virtual machine when passing-through an entire disk. Here are the libvirtd related logs : sept. 16 21:40:29 $hostname libvirtd[548]: internal error: Unable to find major for device-mapper sept. 16 21:40:29 $hostname libvirtd[548]: Unable to get devmapper targets for /dev/disk/by-id/ata-Hitachi_HUAxxxxxxxxxxx_xxxxxxxxxx: Success The disk "/dev/disk/by-id/ata-Hitachi_HUAxxxxxxxxxxx_xxxxxxxxxx" being the physical NVME disk assigned to the virtual machine like this in the config file : <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/disk/by-id/ata-Hitachi_HUAxxxxxxxxxxx_xxxxxxxxxx'/> <target dev='sdb' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> Rollback to libvirt-6.5.0-1 fixed the issue. There are multiple threads on reddit indicating this impacted multiple users. I can provide links if needed. Steps to reproduce: 1 - Upgrade package to libvirt-6.5.0-2 when passing through an entire physical disk 2 - Launch a virtual machine 3 - It failed with the above error logs |
This task depends upon
Closed by Robin Broda (coderobe)
Sunday, 21 March 2021, 05:32 GMT
Reason for closing: Fixed
Additional comments about closing: libvirt >= 1:7.0.0
Sunday, 21 March 2021, 05:32 GMT
Reason for closing: Fixed
Additional comments about closing: libvirt >= 1:7.0.0
[1] https://bbs.archlinux.org/viewtopic.php?pid=1926534#p1926534
Unfortunately I still got the issue with libvirt-6.6.0-1, here are the logs :
sept. 17 21:11:48 $hostname libvirtd[128123]: libvirt version: 6.6.0
sept. 17 21:11:48 $hostname libvirtd[128123]: hostname: $hostname
sept. 17 21:11:48 $hostname libvirtd[128123]: operation failed: pool 'default' already exists with uuid xxxx-xxxx-xxxx-xxxxx-xxxxxxxxxx
sept. 17 21:11:58 $hostname libvirtd[128123]: Domain id=1 name='win10' uuid=xxxx-xxxx-xxxx-xxxxx-xxxxxxxxxx is tainted: host-cpu
sept. 17 21:11:58 $hostname libvirtd[128123]: internal error: Unable to find major for device-mapper
sept. 17 21:11:58 $hostname libvirtd[128123]: Unable to get devmapper targets for /dev/disk/by-id/ata-Hitachi_xxxxxxxxxxxxxx_xxxxxxxxxxx: Success
There is a libvirt 5.7 PKGBUILD patch that applies on top of 5.5.0-1 attached to [1].
[1] https://bugs.archlinux.org/task/66489#comment192305
Can you please try that. If you need help applying it, I can provide more instructions.
If 5.7.0 has the issue as well then it will probably need to be reported upstream for a fix.
This is working fine with libvirt-6.7.0-1, here is how i applied the patch :
$ git clone git://git.archlinux.org/svntogit/community.git --single-branch --branch "packages/libvirt"
$ cd community/trunk/
$ curl https://raw.githubusercontent.com/archlinux/svntogit-community/3a55bd48facd239bdbe1c9153cd6cd85444571b7/trunk/PKGBUILD -o PKGBUILD #overwrite PKGBUILD w/ libvirt-6.5.0-1 PKGBUILD
$ curl https://bugs.archlinux.org/task/66489?getfile=19050 | git apply -v #apply the libvirt-6.7.0-1 PKGBUILD patch
$ makepkg -rsi
$ sudo systemctl restart libvirtd
FYI got 2 side issues :
- scream with IVSHMEM error : "can't open backing store /dev/shm/scream-ivshmem for guest RAM: Permission denied"
For now i made a quick and dirty workaround : $ chmod o+r /dev/shm/scream-ivshmem
- virt-manager is not working : "libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory"
I did not digged yet, as virsh is working fine.
Edit:
Additional upstream commits included:
34b4b4faf01472377a7e9dc3411efd78e4ed78e1 Remove unused variables
418a7009debc464dc5f53010c0092bdfc9bbb6fa virdevmapper: Don't cache device-mapper major
b024001e0322c6ce58b2c36bbd02addb6ddfe386 virdevmapper: Handle kernel without device-mapper support
928eda2e038d26889683f94ed571a01c839ce36 virdevmapper: Ignore all errors when opening /dev/mapper/control
PKGBUILD.diff (8.7 KiB)
❯ git apply -v PKGBUILD.diff
Checking patch trunk/CVE-2020-14339.patch...
error: while searching for:
_("Unable to get devmapper targets for %s"),
next->path);
diff --git a/src/util/virdevmapper.c b/src/util/virdevmapper.c
index 40a82285f9..a471504176 100644
--- a/src/util/virdevmapper.c
+++ b/src/util/virdevmapper.c
@@ -20,38 +20,67 @@
#include <config.h>
error: patch failed: trunk/CVE-2020-14339.patch:46
error: trunk/CVE-2020-14339.patch: patch does not apply
Checking patch trunk/PKGBUILD...
cd src/trunk
git reset --hard
git checkout origin/packages/libvirt
git apply -v PKGBUILD.diff
To download the source :
git clone git://git.archlinux.org/svntogit/community.git --single-branch --branch "packages/libvirt"
To apply the patch :
cd community/trunk/
curl https://bugs.archlinux.org/task/67921?getfile=19132 | git apply -v
libvirt 6.6+ was not packaged as there was no chain of trust from the old key to the new.
[1] https://bugs.archlinux.org/task/67807#comment192332
[1] https://www.redhat.com/archives/libvirt-announce/2020-July/msg00006.html
[1] https://bugs.archlinux.org/task/65523#comment186477
[2] https://bugs.archlinux.org/task/65523#comment186488
Could an Arch team member simply email the new upstream signatory and verify the chain of trust that way?
Or maybe nudge him to update his home page [1]
This would seem acceptable according to a comment from Allan here [2]
[1] https://mamuti.net/public_key.en.html
[2] http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/#comment-1278
[1] https://libvirt.org/downloads.html#keys
However, libvirt-python was left at upgraded version 6.8.0.
It turns out libvirt-python-6.8.0 has a bug which breaks virt-manager when dealing with VM snapshots [1].
Do we want a separate issue to track this libvirt-python bug? Or do you want to rollback libvirt-python too?
It all seems a bit messy unfortunately.
[1] https://github.com/virt-manager/virt-manager/issues/170
non-maintainer update containing sweeping changes without discussing it with the maintainer.
libvirt-python should therefore be rolled back too...
6.8.0 fixes this problem. And 6.5.0-1 didn't have this problem.
This is the error log with "6.5.0-2" package:
"
Unable to complete install: 'Unable to get devmapper targets for /dev/zvol/vmpool/midea: Success'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/createvm.py", line 2089, in _do_async_install
guest.installer_instance.start_install(guest, meter=meter)
File "/usr/share/virt-manager/virtinst/install/installer.py", line 542, in start_install
domain = self._create_guest(
File "/usr/share/virt-manager/virtinst/install/installer.py", line 491, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python3.8/site-packages/libvirt.py", line 4035, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: Unable to get devmapper targets for /dev/zvol/vmpool/midea: Success'
6.5.0-2 patched with CVE-2020-14339.patch and the 6.7 commits (patch3 and PKGBUILD.diff) seems to work fine with ZFS here.
Definitely not working with ZFS iSCSI LUNs here. The 6.8 update fixed this, the 6.5 rollback was a very nasty surprise and broke this again.
I hope this gets fixed quickly.
You can go to archives.archlinux.org and grab it. I rolled back to 6.8 from there and locked it down. This rollback is a no-go for me.
Perfecto, that's what I've been looking for but was not finding. Thank you.
with "1:6.5.0-3" the same errors occurs:
$systemctl status libvirtd:
libvirtd[56124]: internal error: Unable to find major for device-mapper
libvirtd[56124]: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success
$virt-manager:
Error starting domain: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1330, in startup
self._backend.create()
File "/usr/lib/python3.8/site-packages/libvirt.py", line 1234, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success
Edit: Finally found it, looks like were "Waiting"
I've poked via various means, someone else has poked on the public libvirt ML about it as well, and nothing has come from that thus far as far as i can tell.
I just re-checked, and it still doesn't validate from over here. I'm effectively bound by patching the current libvirt until it breaks even more than it already is, or throwing the security considerations out the window...
Traceback (most recent call last):
File "/usr/bin/virt-manager", line 6, in <module>
from virtManager import virtmanager
File "/usr/share/virt-manager/virtManager/virtmanager.py", line 19, in <module>
from virtinst import BuildConfig
File "/usr/share/virt-manager/virtinst/__init__.py", line 43, in <module>
_set_libvirt_error_handler()
File "/usr/share/virt-manager/virtinst/__init__.py", line 33, in _set_libvirt_error_handler
import libvirt
ModuleNotFoundError: No module named 'libvirt'
And if I use the "current" 1:6.5.0-3 version I am unable to use my disk for VM (original bug report in this thread).
So I can't upgrade and I can't use 6.8.0 version at this point.
By the way Debian has 6.9.0 in their testing and unstable repositories:
https://packages.debian.org/source/bullseye/libvirt
Did they ignore security considerations or they could verify chain of trust?
who knows, go ask
@Stevo, where did find it?
I managed to find the new GPG key in the Qubes OS repository, so here it is: https://raw.githubusercontent.com/QubesOS/qubes-core-libvirt/eb8e668080cdba9e3730dbdc5e28d6e1c7473cdc/redhat-jiri-denemark-key.asc, I can verify libvirt 6.9 with this key.
Hope it could help
$ gpg --keyserver pgp.ocf.berkeley.edu --recv-keys 453B65310595562855471199CA68BE8010084C9C
gpg: key CA68BE8010084C9C: "Jiří Denemark <jdenemar@redhat.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
$ gpg --verify libvirt-6.10.0.tar.xz.asc libvirt-6.10.0.tar.xz
gpg: Signature made Tue 01 Dec 2020 02:55:41 AM CST
gpg: using RSA key 453B65310595562855471199CA68BE8010084C9C
gpg: Good signature from "Jiří Denemark <jdenemar@redhat.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 453B 6531 0595 5628 5547 1199 CA68 BE80 1008 4C9C
"Good signature" establishes that the pubkey with the fingerprint 453B65310595562855471199CA68BE8010084C9C on pgp.ocf.berkeley.edu indeed did sign the latest release. Either you trust the key's authenticity or you don't. If you don't, can you explain the standard you're seeking so we can assist in digging up the appropriate evidence?
Also, keep in mind that there can be no public web of trust to the signer of 6.5.0 because C74415BA7C9C7F78F02E1DC34606B8A5DE95BC1F is only self-signed. You will see the exact same warning for that signature. What is your path of trust to the signer of 6.5.0?
[1] https://libvirt.org/downloads.html#keys
[2] https://www.redhat.com/archives/libvirt-announce/2020-July/msg00005.html
[3]libvir-list@redhat.com/msg208651.html"> https://www.mail-archive.com/libvir-list@redhat.com/msg208651.html
the libvirt people are aware. blowing up all the bugreports with the same stuff does, in fact, not make anyone process it faster.
[1] https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys
keep it to yourself or bring it up elsewhere unless it is related to the bug you're commenting under.
@corerobe to establish a path of trust would require a signed or encryted message from C74415BA7C9C7F78F02E1DC34606B8A5DE95BC1F' Daniel Veillard <veillard@redhat.com>
stating that the new signing key for libvirt is 453B65310595562855471199CA68BE8010084C9C Jiří Denemark <jdenemar@redhat.com> ?
If so how about asking felixonmars if Arch Linux CN can get in contact with Daniel Veillard in Xiamen, China?
Alternate strategy one class libvirt as Redhat / IBM corporation project and ask a corporate officer to state the transfer of signing responsibilities has passed to Jiří Denemark.
Alternate strategy two obtain a majority of libvirt developer key signatures for Jiří Denemark then class 6.6.0 onward as a fork.
FS#63828but that is a different matter.-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Starting from libvirt-6.6.0 the upstream releases will be done by Jiří Denemark
signed with his PGP key:
pub 4096R/10084C9C 2020-07-20 Jiří Denemark <jdenemar@redhat.com>
Fingerprint=453B 6531 0595 5628 5547 1199 CA68 BE80 1008 4C9C
This message is signed by the old signing key which was used for previous
releases.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE20ZoG7ka3OoXD6LUFViLJllr6l0FAl/8H9cACgkQFViLJllr
6l3iVwgAm9n703/QoIfPbxT5qGQzWK6LNriEcG2R9MLgFcW+UuGA9cqIBLhH1RaJ
q7Gc3gK0dgE2HAF6DxuG5+nkDY6LdmonLOVFWQkMCh41JHFrV6tw8y9hc/RNOb/m
gFAl4HpwYisjTRvsTRcpR3ElK6lI0Yu4GY4gJxj5qH4L5exR+kkylwuAxqP+wuyY
b/L/tP76F4+Q9SSPj0M01NRVC7V8m3yvnok5y374vtxvRFome0WMELn81vphxBLx
X7LQ1LyjvRs0HhN5MutJES5FYDzArTYZfZJozJgE465XrHxMMCbXbZ/AgAs/aD+5
x+m2mFplbS57tMEoMBP/ezbbL5wpvA==
=KnaO
-----END PGP SIGNATURE-----
Added early this morning via https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=d9b70d46bb5f71a3edb37f42a470545e21faa8da;hp=e110743d693cc66cf828d5c453653a5cf0a0aec5
A quick review:
- hey, nice use of obscure meson feature to solve the ZFS hack issue :)
- some new config files are missing from the backup() array (etckeeper users will be unhappy):
'etc/libvirt/nwfilter/allow-dhcpv6-server.xml'
'etc/libvirt/nwfilter/allow-dhcpv6.xml'
'etc/libvirt/nwfilter/allow-incoming-ipv6.xml'
'etc/libvirt/nwfilter/allow-ipv6.xml'
'etc/libvirt/nwfilter/no-ipv6-multicast.xml'
'etc/libvirt/nwfilter/no-ipv6-spoofing.xml'
- it appears netcf dep was brought back. Why? As previously mentioned[1], that pkg is completely and utterly pointless on Arch and has even resulted in upstream snark[2]
[1]. https://bugs.archlinux.org/task/66489
[2]. https://www.redhat.com/archives/virt-tools-list/2018-October/msg00049.html
I've just installed "augeas-1.12.0-2 netcf-0.2.8-8 libvirt-1:7.0.0-1" from community-testing and that's it! It started immediately from virt-manager.
Like Enrico, ausgeas and netcf packages were installed (from community). I don't see "ausgeas" listed as a dependency in the libvirt community-testing package listing (on the web page). It sounds like netcf isn't needed but I have not tested removing netcf from the PKGBUILD myself.
I had to install ebtables to use the default network which is an optional dependency for libvirt-7.0.0-1. It looks like libvirt 6.5.0-3 also has ebtables marked as an optional dependency but I did not need it before. (I was using 6.5.0-1 before upgrading.)
The error that I had with the default network was: "Error starting domain: Requested operation is not valid: network 'default' is not active"
To fix the 'default' network issue, I installed ebtables. (My understanding is that packages ebtables iptables dnsmasq are needed. I ran "sudo pacman -Qi ebtables iptables dnsmasq" and saw that ebtables was not installed on my system.)
sudo pacman -S ebtables --asdeps
sudo systemctl restart libvirtd
sudo virsh net-start default
Other notes: Some new files showed up for pacdiff. In addition to "/etc/libvirt/qemu/networks/default.xml", "/etc/libvirt/nwfilter/allow-dhcp-server.xml" and "/etc/libvirt/nwfilter/allow-dhcp.xml" now have pacnew files. The files on my system (not the new files) have "This is an auto-generated file" in them. I don't know the reasoning behind having default.xml default.xml in the package or why the new files are in there now so I can only comment that this is a change that I noticed.
I still needed to install ebtables for default network (as expected). There were more pacnew files under nwfilter than before but I think this is expected now.