Hi,
On Mittwoch, 17. November 2021 23:24:14 CET you wrote:
> > I did another test by pinning the bookworm packages (7.6.0-1) and testing
> > those. They exhibit the same behaviour as the patched libvirt, that is: in
> > some cases, virsh destroy will show an error, but the container will be
> > re
On Wed, 17 Nov 2021 16:30:54 +0100 Jonas =?ISO-8859-1?Q?Sch=E4fer?=
wrote:
> Hi again,
>
Hi Jonas.
> I did another test by pinning the bookworm packages (7.6.0-1) and testing
> those. They exhibit the same behaviour as the patched libvirt, that is: in
> some cases, virsh destroy will show an error
Hi again,
I did another test by pinning the bookworm packages (7.6.0-1) and testing
those. They exhibit the same behaviour as the patched libvirt, that is: in
some cases, virsh destroy will show an error, but the container will be
removed cleanly nonetheless.
This is an improvement over the pr
Hi Guido,
Thanks for your reply!
On Wed, 17 Nov 2021 13:11:05 +0100 Guido Günther wrote:
> here's the missing link:
>
> https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/116
I took the artifacts from there and did another test run. At first glance,
everything looked good, but the
Hi,
On Wed, Nov 17, 2021 at 01:06:20PM +0100, Guido Günther wrote:
> Hi,
> On Fri, Oct 22, 2021 at 12:35:17AM +0700, Dio Putra wrote:
> > Hi, this bug just happened right in front of me (see my picture attachment).
> > Fortunately, I was able to create a rebase patch to Debian Bullseye:
> > https:/
Hi,
On Fri, Oct 22, 2021 at 12:35:17AM +0700, Dio Putra wrote:
> Hi, this bug just happened right in front of me (see my picture attachment).
> Fortunately, I was able to create a rebase patch to Debian Bullseye:
> https://listman.redhat.com/archives/libvir-list/2021-April/msg00756.html
>
> Here's
Dear maintainer, dear Dio Putra,
I was hit by this too when upgrading LXC-heavy machines to Debian stable. The
patch proposed by Dio Putra [1] fixes the issue for me (I built libvirt 7.0.0-3
from salsa with that patch applied). The only caveat I found was that if you
previously tried to destroy
Hi, this bug just happened right in front of me (see my picture attachment).
Fortunately, I was able to create a rebase patch to Debian Bullseye:
https://listman.redhat.com/archives/libvir-list/2021-April/msg00756.html
Here's my patch:
>From ea7d0ca37cce76e1327945c4864b996d7fd6d2e6 Mon Sep 17 00:0
With
cgroup_controllers = []
in /etc/libvirt/qemu.conf I could get it back to working
for the 6.9.0-4 version though. That didn’t (seem to) work
with 7.0.0-2 earlier… :/
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.d
Package: libvirt-daemon
Version: 6.9.0-4
Followup-For: Bug #983871
X-Debbugs-Cc: t...@mirbsd.de
Ouch, after a reboot this stopped working again!
-- System Information:
Debian Release: bullseye/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstab
notfound 983871 6.9.0-4
thanks
> Package: libvirt-daemon
> Version: 7.0.0-2
> After an upgrade+reboot I cannot start VMs *again* with some cgroup error:
Downgrading the entire bunch of involved packages fixes this:
tglase@tglase:~/a $ sudo apt-get install $PWD/*.deb
Reading package lists... 0%R
Dixi quod…
> After an upgrade+reboot I cannot start VMs *again* with some cgroup error:
>
> $ wirrsh start Netboot
>
> error: Failed to start domain 'Netboot'
> error: internal error: failed to get cgroup backend for 'pathOf
Package: libvirt-daemon
Version: 7.0.0-2
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
After an upgrade+reboot I cannot start VMs *again* with some cgroup error:
$ wirrsh start Netboot
error: Failed to start domain 'Netbo
13 matches
Mail list logo
