I noticed another bug in vvfat disk image generation. Applying the patch I attached earlier made testing easier. I'm less sure what the actual problem is.
Steps to reproduce (you'll need to have cpio, md5sum and GNU GRUB 2.x installed): 0. Apply the patch and build qemu-img. 1. Create a directory, cd into it and unpack the attached cpio file. 2. Run: qemu-img convert fat:. ../xxx.img 3. Run: for fname in $(grub-fstest ../xxx.img ls '(loop0,msdos1)/'); do grub-fstest ../xxx.img cat "(loop0,msdos1)/$fname" | md5sum | sed -e "s,-,$fname,"; done | md5sum -c 4. Observe how almost all checksum tests fail. Alternatively, the image can be tested inside a virtual machine. You probably get the idea. (File names and data have been changed for the sake of anonymity and better compressibility) ** Attachment added: "Bug-triggering file structure" https://bugs.launchpad.net/qemu/+bug/1599539/+attachment/4707220/+files/xxx.cpio.xz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1599539 Title: 2.6.0: vvfat driver generates bad FAT entries Status in QEMU: New Bug description: The vvfat driver sometimes generates entries about which file system checking utilities generate complaints. For example, dosfsck will complain that the volume label entry has non-zero size. ScanDisk from Windows 9x complains about invalid dot (".") and dot-dot ("..") entries in directories and also about invalid long file name entries. MS-DOS ScanDisk also often manages to find "lost clusters" on the drive. Tangentially: qemu-img convert fat:test test.img doesn't seem to work -- it generates an 504MiB of zero bytes and hangs. qemu-img map fat:test generates an assertion failure. Having qemu-img working might have helped with debugging the above issue. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1599539/+subscriptions
