Hi Roland, I'm CC'ing Ben Hutchings directly as well as he takes care of the Debian LTS kernel updates. Idellly we make this as well a proper bug for easier tracking.
On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote: > Hi there, > > after upgrading to the latest kernel on Debian 11 > (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm > virtual machines and macvtap networking. When a machine is shut down, > libvirt can not delete the corresponding macvtap device. Thus, starting the > machine again is not possible. After manually removing the macvtap device > using `ip link delete` the vm can be started again. > > In the journal the following message is shown: > > Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device > macvtap0: Operation not supported > > After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem > disappears. I tested this on a fresh minimal install of Debian 11 - to > exclude that anything else on my production machines is causing this issue. > > Since the older kernel does not have this issue, I assume this is related to > the kernel and not to libvirt? > > I tried to check for bug reports of the kernel package, but the bug tracker > finds no reports and even states that the package does not exist (I used the > "Bug reports" link on > https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This left > me a bit puzzled. Since I don't have experience with the debian bug > reporting process, I had no other idea than writing to this list. You would need to search for in https://bugs.debian.org/src:linux , but that said I'm not aware of any bug reports in that direction. Would you be in the position of bisecting the problem as you can say that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do that that would involve compiling a couple of kernels to narrow down where the problem is introduced: git clone --single-branch -b linux-5.10.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git checkout v5.10.244 cp /boot/config-$(uname -r) .config yes '' | make localmodconfig make savedefconfig mv defconfig arch/x86/configs/my_defconfig # test 5.10.244 to ensure this is "good" make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package and confirm it successfully boots / problem does not exist # test 5.10.247 to ensure this is "bad" git checkout v5.10.247 make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package and confirm it fails to boot / problem exists With that confirmed, the bisection can start: git bisect start git bisect good v5.10.244 git bisect bad v5.10.247 In each bisection step git checks out a state between the oldest known-bad and the newest known-good commit. In each step test using: make my_defconfig make -j $(nproc) bindeb-pkg ... install, try to boot / verify if problem exists and if the problem is hit run: git bisect bad and if the problem doesn't trigger run: git bisect good . Please pay attention to always select the just built kernel for booting, it won't always be the default kernel picked up by grub. Iterate until git announces to have identified the first bad commit. Then provide the output of git bisect log In the course of the bisection you might have to uninstall previous kernels again to not exhaust the disk space in /boot. Also in the end uninstall all self-built kernels again. Regards, Salvatore
