Package: qemu-system-x86 Version: 1:4.1-1+b4 This issue is a bit ugly, and the reproduction of it is more convoluted than I'd like, but here's the basic problem that I've hit... I build Debian guest images with qemu for two different hardware targets, x86_64 systems with 512b sector drives and x86_64 systems with 4K native drives. The host I typically build these images from does not, itself, have 4K native drives, so when building the image to be used with on systems that do, I emulate them using a command line similar to:
qemu-system-x86_64 -machine pc,accel=kvm \ -device virtio-blk-pci,drive=blk0,bootindex=1,physical_block_size=4096,logical_block_size=4096 \ -drive id=blk0,file=4k.qcow2,if=none,format=qcow2,cache=none \ "$@" My usual process is: 1. qemu-img create -f qcow2 4k.qcow2 2G 2. run above the qemu commmand which bootstraps and installs a basic Debian system via d-i with a preseed file via dhcp/tftp etc. 3. qemu-img convert -c -O qcow2 4k.qcow2 4k-repack.qcow2 So, basically, make an empty qcow2 image file, install Debian using that file as a backing drive to qemu, then re-compress the resulting qcow2 file to get a smaller base image. This qcow2 file is then used as a base image for new guest virtual servers by using the qemu-img convert command to lay down a copy of the image onto carved off lvm logical volumes. Nothing all that fancy, the only trick really was doing the block size emulation. Up until 4.1 all this worked great, but with 4.1 it's producing subtle corruption in the images, usually visible as binary executables getting mangled and failing to execute with "unsupported version 0 of Verneed record" messages. The 512b sector images still work reliably with 4.1, so I suspect something broke in the block size logic. If I switch back to 3.1+dfsg-8+deb10u3 the corruption vanishes. -- Jamie Heilman http://audible.transient.net/~jamie/
