| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| backport/apparmor-let-image-label-setting-loop-over-backing-files.patch | apparmor: let image label setting loop over backing files When adding a rule for an image file and that image file has a chain of backing files then we need to add a rule for each of those files. To get that iterate over the backing file chain the same way as dac/selinux already do and add a label for each. (cherry picked from commit d51ad0008dc2df0257f69e767ab3e3c5fd1457ff) |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2021-01-13 | ||
| backport/meson-Fix-cross-building-of-dtrace-probes.patch | meson: Fix cross-building of dtrace probes dtrace invokes the C compiler, so when cross-building we need to make sure that $CC is set in the environment and that it points to the cross-compiler rather than the native one. Until https://github.com/mesonbuild/meson/issues/266 is addressed, the workaround is to call dtrace via env(1). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980334 (cherry picked from commit 44b348134cd6724e35984a553f8d54d27aa22711) |
Helmut Grohne <helmut@subdivi.de> | no | 2021-01-19 | ||
| backport/Fix-reboot-command-for-LXC-containers.patch | Fix reboot command for LXC containers (Closes: #991773) The virNetDaemonQuit(dmn) command in virLXCControllerSignalChildIO triggers an early close of all clients of lxc_controller. Here, libvirtd itself is a client of this controller, and the client connection is used to notify libvirtd if a reboot of the container is required. However, the client connection was closed before such a status could be sent to libvirtd. To fix this bug, we will immediately send the reboot or shutdown status of the container to libvirtd, and only after client disconnect will we trigger virNetDaemonQuit (Closes: #991773). (cherry picked from commit 93c47e2c39521aba760486f0238458ef1a37490c) In order to cleanly apply to libvirt 7.0.0, this patch needed some minor adjustments, e.g., "virNetDaemon *dmn" vs "virNetDaemonPtr dmn" in libvirt 7.0.0. |
Joachim Falk <joachim.falk@gmx.de> | no | debian | 2021-12-02 | |
| revert/systemd-Revert-remote-Add-libvirtd-dependency-to-virt-gue.patch | systemd: Revert "remote: Add libvirtd dependency to virt-guest-shutdown.target" as it would reintroduce bug 955216 This reverts commit f035f53baa2e5dc00b8e866e594672a90b4cea78. |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2021-01-27 | ||
| forward/Skip-vircgrouptest.patch | Skip vircgrouptest We don't have a mock for nodeGetCPUCount yet so we fail in a chroot without sysfs mounted. |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2014-03-07 | ||
| forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch | Reduce udevadm settle timeout to 10 seconds This isn't a proper fix but it will make virt-manager at least start. |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2012-06-04 | ||
| forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch | Pass GPG_TTY env var to the ssh binary gpg-agent(1) can emulate the OpenSSH Agent protocol (which provides pubkey-authentication using an authentication-capable OpenPGP key, in addition to the usual identity files). However for a console-based password prompt to work, the 'GPG_TTY' environment variable needs to be set to the current TTY. Furthermore, curses-based password prompts also require the 'TERM' environment variable to be set to the terminal type. |
Guilhem Moulin <guilhem@guilhem.org> | no | 2016-12-09 | ||
| debian/Debianize-libvirt-guests.patch | Debianize libvirt-guests | =?utf-8?q?Laurent_L=C3=A9onard?= <laurent@open-minds.org> | no | vendor | 2010-12-09 | |
| debian/Debianize-libvirtd.patch | Debianize libvirtd | Andrea Bolognani <eof@kiyuko.org> | no | 2021-02-14 | ||
| debian/Debianize-systemd-service-files.patch | Debianize systemd service files | =?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2012-06-26 | ||
| debian/apparmor_profiles_local_include.patch | apparmor_profiles_local_include Include local apparmor profile |
Felix Geyer <fgeyer@debian.org> | no | 2015-08-11 | ||
| debian/Set-defaults-for-zfs-tools.patch | Set defaults for zfs tools so we don't have to build-depend on a program in contrib |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2016-08-14 | ||
| debian/Revert-m4-virt-xdr-rewrite-XDR-check.patch | Revert "m4: virt-xdr: rewrite XDR check" This reverts commit d7147b3797380de2d159ce6324536f3e1f2d97e3. Reasoning: The build against libtirpc causes linking errors using the headers of libtirpc but calling into the compat functions of glibc as discussed here: https://www.redhat.com/archives/libvir-list/2020-August/msg00921.html Current glibc 2.31-0ubuntu1 and 2.31-3 for us are built with --enable-obsolete-rpc which then leads to the wrong linking. What happens otherwise is a crash like: [582093.524644] libvirt_lxc[261446]: segfault at 0 ip 0000000000000000 sp 00007ffdd2345598 error 14 in libvirt_lxc[5587e42aa000+8000] [582093.524650] Code: Bad RIP value. The reason is that due to bad linking (should link to 3.0 versions instead): $ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 0x0000000000026820 X86_64_JUMP_SLOT 000000000000000000 +0 xdr_uint64_t 99: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF xdr_uint64_t GLIBC_2 2 5 (4) [ 1c02] xdr_uint64_t It will use the headers and structs of libtirpc but then call ito glibc which breaks badly. As soon as we rebuild agains 2.32 which is about to arrive we can drop this revert and follow upstream as 2.32 dropped the option to enable --enable-obsolete-rpc. |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2020-08-26 | ||
| debian/Use-sensible-editor-by-default.patch | Use sensible-editor by default It is the reasonable default for Debian. |
Andrea Bolognani <eof@kiyuko.org> | no | 2020-08-18 | ||
| backport/vircgroup-Fix-virCgroupKillRecursive-wrt-nested-controlle.patch | vircgroup: Fix virCgroupKillRecursive() wrt nested controllers I've encountered the following bug, but only on Gentoo with systemd and CGroupsV2. I've started an LXC container successfully but destroying it reported the following error: error: Failed to destroy domain 'amd64' error: internal error: failed to get cgroup backend for 'pathOfController' Debugging showed, that CGroup hierarchy is full of surprises: /sys/fs/cgroup/machine.slice/machine-lxc\x2d861\x2damd64.scope/ libvirt dev-hugepages.mount dev-mqueue.mount init.scope sys-fs-fuse-connections.mount sys-kernel-config.mount sys-kernel-debug.mount sys-kernel-tracing.mount system.slice console-getty.service dbus.service system-getty.slice system-modprobe.slice systemd-journald.service systemd-logind.service tmp.mount user.slice For comparison, here's the same container on recent Rawhide: /sys/fs/cgroup/machine.slice/machine-lxc\x2d13550\x2damd64.scope/ libvirt Anyway, those nested directories should not be a problem, because virCgroupKillRecursiveInternal() removes them recursively, right? Sort of. The function really does remove nested directories, but it assumes that every directory has the same controller as the rest. Just take a look at virCgroupV2KillRecursive() - it gets 'Any' controller (the first one it found in ".scope") and then passes it to virCgroupKillRecursiveInternal(). This assumption is not true though. The controllers found in ".scope" are the following: cpuset cpu io memory pids while "libvirt" has fewer: cpuset cpu io memory Up until now it's not problem, because of how we order controllers internally - "cpu" is the first and thus picking "Any" controller returns just that. But the rest of directories has no controllers, their "cgroup.controllers" is just empty. What fixes the bug is dropping @controller argument from virCgroupKillRecursiveInternal() and letting each iteration work pick its own controller. (cherry picked from commit ea7d0ca37cce76e1327945c4864b996d7fd6d2e6) |
Michal Privoznik <mprivozn@redhat.com> | no | 2021-04-16 | ||
| backport/tests-Fix-libxlxml2domconfigtest-with-latest-xen.patch | tests: Fix libxlxml2domconfigtest with latest xen shadow_memkb is populated from a libxl API call, and the value can change. For example: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2c992810854a15b41be920519ce83a4a328d5168 Mock libxl_get_required_shadow_memory to give consistent output (cherry picked from commit 72d4709ab901dd3699d342f15ca3aff9bffddf96) |
Cole Robinson <crobinso@redhat.com> | no | 2022-10-27 | ||
| backport/tests-Fix-libxlxml2domconfigtest.patch | tests: Fix libxlxml2domconfigtest Downstream CI recently encountered failures of libxlxml2domconfigtest when building libvirt packages against Xen 4.17 rc3 packages. The test fails on vnuma_hvm config, where suddently the actual json produced by libxl_domain_config_to_json() contains a 'pnode' entry in the 'vnuma_nodes' list, which is absent in the expected json. It appears the test has thus far passed by luck. E.g. I was able to make the test pass in the failing environment by changing the meson buildtype from debugoptimized to debug. When a VM config contains vnuma settings, libxlMakeVnumaList() checks if the number of requested vnuma nodes exceeds the number of physical nodes. The number of physical nodes is retrieved with libxl_get_physinfo(), which can return wildly different results in the context of unit tests. This change mocks libxl_get_physinfo() to return consistent results. All fields of the libxl_physinfo struct are set to 0 except nr_nodes, which is set to 6 to ensure the vnuma_hvm configuration is properly tested. (cherry picked from commit f81ee7b549242c93bead8c8772bb31047da00415) |
Jim Fehlig <jfehlig@suse.com> | no | 2022-11-10 |