On Wed, Sep 07, 2022 at 10:28:17AM -0500, Carlos Bilbao wrote: > On 9/6/22 12:50, Carlos Bilbao wrote: > > So, what I did this time was: > > > > $ ninja -C build clean I would recommend nuking the build/ directory completely if you're going to reconfigure, just to be on the safe side. > > $ meson build --reconfigure --prefix=$HOME/usr -Dsystem=true Passing --prefix along with -Dsystem=true doesn't really make sense. -Dsystem=true tells the build system to set various paths to sane defaults for a system-wide installation, and the value passed to --prefix is used to construct some of those paths. So don't use both at the same time - stick to -Dsystem=true only. As an aside, setting --prefix to a directory under $HOME is unlikely to result in a working configuration anyway. > > $ ninja -C build > > $ sudo ninja -C build install > > $ systemctl stop libvirtd > > $ systemctl start libvirtd Before restarting libvirtd, since you've just installed new unit files as part of the steps above, you should run $ sudo systemctl daemon-reload > > $ systemctl status libvirtd > > ○ libvirtd.service - Virtualization daemon > > Loaded: loaded (/usr/local/lib/systemd/system/libvirtd.service; > > enabled; vendor preset: enabled) Note how the unit file... > > Active: inactive (dead) since Tue 2022-09-06 17:43:53 UTC; 1min 57s > > ago > > TriggeredBy: ● libvirtd-admin.socket > > ● libvirtd-ro.socket > > ● libvirtd.socket > > Docs: man:libvirtd(8) > > https://libvirt.org > > Process: 2272757 ExecStart=/usr/local/sbin/libvirtd $LIBVIRTD_ARGS ... the libvirtd binary... > > (code=exited, status=0/SUCCESS) > > Main PID: 2272757 (code=exited, status=0/SUCCESS) > > Tasks: 2 (limit: 32768) > > Memory: 60.5M > > CPU: 49ms > > CGroup: /system.slice/libvirtd.service > > ├─2760 /usr/sbin/dnsmasq > > --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro > > --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper > > └─2761 /usr/sbin/dnsmasq > > --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro > > --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper > > > > Sep 06 17:41:04 host systemd[1]: Starting Virtualization daemon... > > Sep 06 17:41:04 host systemd[1]: Started Virtualization daemon. > > Sep 06 17:41:53 host libvirtd[2272757]: libvirt version: 8.7.0 > > Sep 06 17:41:53 host libvirtd[2272757]: hostname: host > > Sep 06 17:41:53 host libvirtd[2272757]: Failed to connect socket to > > '/var/local/run/libvirt/virtqemud-sock': No such file or directory ... and the socket are all under /{usr,var}/local. This is not what you want, and using -Dsystem=true should have not resulted in such a setup. Make sure you run 'systemd daemon-reload' after installing unit files, as I've mentioned above, and also look around for leftovers from a previous installation of libvirt that might be interfering with the current one. Regardless of all that, the client is trying to connect to virtqemud but you seem to have the monolithic libvirtd daemon running. I can't remember whether that's expected, but it's looks like a red flag to me. I think the client might have gotten confused about whether split daemons are in use. Please check out https://libvirt.org/daemons.html and ensure you're in one of the two supported deployment scenarios and not a weird mix of the two. > > > Generally the most straightforward way is to build distribution packages > > > from the tree and install them directly in your system because then you > > > avoid issues such as possibly having two libvirtd instances running and > > > such. > > > > Does libvirt have any script or tool to ease such process? > > Answering to myself here, because I have made some progress but still have > to fix some blockings. Decided to use debhelper to build Debian packages > and test libvirt. Did: > > $ sudo apt-get install debhelper dh-make > $ sudo dh_make --createorig -p libvirt-snp_1 > $ dh_auto_configure --buildsystem=meson > $ dpkg-buildpackage -rfakeroot -us -uc -b > > Notice that the option -b for dpkg-buildpackage is to avoid the Debian > package bureaucracy. But still, some checks fail for the package (see below > ). I don't think this errors have anything to do with the code I modified, > but I will be happy to share a patch for reproduction. If you want to build a Debian package, I recommend using the one that's already in the archive as a starting point instead of using dh_make to create one from scratch. It's currently a couple of versions behind upstream, but should be pretty solid otherwise. dh_make is intended to create a very basic skeleton for a package, and you're expected to make significant changes to the files it produces before being able to build a working package. -- Andrea Bolognani / Red Hat / Virtualization
