On 2025-05-31 14:52, Francesco Poli wrote: > Just after creating the image with 'mmdebstrap-autopkgtest-build-qemu', > before updating it: > > $ file unstable-autopkgtest-amd64.img > unstable-autopkgtest-amd64.img: DOS/MBR boot sector; partition 1 : ID=0xee, > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 52690977 sectors, > extended partition table (last) > > After updating the image with 'sbuild-qemu-update': > > $ file unstable-autopkgtest-amd64.img > unstable-autopkgtest-amd64.img: QEMU QCOW Image (v3), 26977780736 bytes > (v3), 26977780736 bytes
Ah yes. sbuild-qemu-update boots the image, runs apt-get inside, and calls fstrim after to discard no longer used blocks on the root fs. After that, there is a qemu-img convert call, which removes those unused blocks from the image. Otherwise it would keep on growing and growing. That could be the source of the problem, though I still can't reproduce it. However I don't have a pure unstable system at the moment, just tested this on bookworm will all backports. Could you create an image, boot is with sbuild-qemu-boot, and manually run commands found in the update_interaction() function of /usr/bin/sbuild-qemu-boot? I'm particularly interested in whether the remount and fstrim are causing this. If not, it has to be the qemu-img convert after that. Best, Christian
