From: carnil@debian.org   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)