diff options
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/files')
202 files changed, 4358 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/files/1006655 b/results/classifier/deepseek-2-tmp/output/files/1006655 new file mode 100644 index 000000000..0d7da1a43 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1006655 @@ -0,0 +1,11 @@ + +Can't convert to vmdk with the streamOptimized subformat + +Hi all, +I'm trying to convert a qcow2 image file to the vmdk (on Ubuntu Server 12.04): + +# qemu-img convert -f qcow2 -O vmdk -o Stream spv-2912.qcow2 spv-2912-3.vmdk -o subformat=streamOptimized +VMDK: can't write to allocated cluster for streamOptimized +qemu-img: error while writing sector 65: Input/output error + +Same result with any input format. Others subformats work but the StreamOptimized it is by far the most important one. The only workaround I found is to migrate to raw and then to use VBoxManage (VirtualBox). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1007490 b/results/classifier/deepseek-2-tmp/output/files/1007490 new file mode 100644 index 000000000..e4697f588 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1007490 @@ -0,0 +1,13 @@ + +Missing binfmt string for init script. + +./scripts/qemu-binfmt-conf.sh + +needs + +echo ':armCompiler:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-arm-binfmt:P' > /proc/sys/fs/binfmt_misc/register + +Some executables (specifically compilers like /usr/libexec/gcc/armv7a-unknown-linux-gnueabi/4.5.3/cc1 on gentoo) have unusual headers, and don't get recognized as arm binaries. + +Bug also mentioned on my blog: +http://mirage335.dyndns.org/forums/viewtopic.php?f=4&t=11&sid=01f0ca9cc76c78b6f600fa25cc99d62b \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1012 b/results/classifier/deepseek-2-tmp/output/files/1012 new file mode 100644 index 000000000..c2f60aea3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1012 @@ -0,0 +1,42 @@ + +9p: newfstatat behaves differently than fstat causing ENOENT for here-documents +Description of problem: +After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error. +Steps to reproduce: +1. I have file `a` with: +``` +cat <<EOF +x +EOF +``` +2. User visible error inside VM: +``` +root@x86_64:~# grep 9p /proc/mounts +/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0 +root@x86_64:~# bash a +cat: -: No such file or directory +``` +3. `strace -fyv bash a` shows: +``` + [pid 291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, +st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0 + [pid 291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory) + [pid 291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5 + [pid 291] write(2</dev/ttyS0>, "-", 1-) = 1 + [pid 291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27 + [pid 291] write(2</dev/ttyS0>, "\n", 1 +``` +Additional information: +In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows: +``` + [pid 283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204, +st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0 + [pid 283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */, +st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0 + [pid 283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 + [pid 283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000 + [pid 283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2 + [pid 283] write(1</dev/ttyS0>, "x\n", 2x +``` + +So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently. diff --git a/results/classifier/deepseek-2-tmp/output/files/1025 b/results/classifier/deepseek-2-tmp/output/files/1025 new file mode 100644 index 000000000..3c55b0e24 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1025 @@ -0,0 +1,4 @@ + +qemu-img create will silently overwrite existing image +Description of problem: +If file exists, it is silently overwritten, causing loss of data. oups. diff --git a/results/classifier/deepseek-2-tmp/output/files/1025244 b/results/classifier/deepseek-2-tmp/output/files/1025244 new file mode 100644 index 000000000..a0c622b37 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1025244 @@ -0,0 +1,33 @@ + +qcow2 image increasing disk size above the virtual limit + +Using qemu/kvm, qcow2 images, ext4 file systems on both guest and host + Host and Guest: Ubuntu server 12.04 64bit +To create an image I did this: + +qemu-img create -f qcow2 -o preallocation=metadata ubuntu-pdc-vda.img 10737418240 (not sure about the exact bytes, but around this) +ls -l ubuntu-pdc-vda.img +fallocate -l theSizeInBytesFromAbove ubuntu-pdc-vda.img + +The problem is that the image is growing progressively and has obviously no limit, although I gave it one. The root filesystem's image is the same case: + +qemu-img info ubuntu-pdc-vda.img + image: ubuntu-pdc-vda.img + file format: qcow2 + virtual size: 10G (10737418240 bytes) + disk size: 14G + cluster_size: 65536 + +and for confirmation: + du -sh ubuntu-pdc-vda.img + 15G ubuntu-pdc-vda.img + +I made a test and saw that when I delete something from the guest, the real size of the image is not decreasing (I read it is normal). OK, but when I write something again, it doesn't use the freed space, but instead grows the image. So for example: + 1. The initial physical size of the image is 1GB. + 2. I copy 1GB of data in the guest. It's physical size becomes 2GB. + 3. I delete this data (1GB). The physical size of the image remains 2GB. + 4. I copy another 1GB of data to the guest. + 5. The physical size of the image becomes 3GB. + 6. And so on with no limit. It doesn't care if the virtual size is less. + +Is this normal - the real/physical size of the image to be larger than the virtual limit??? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1027 b/results/classifier/deepseek-2-tmp/output/files/1027 new file mode 100644 index 000000000..f9fc2cd9d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1027 @@ -0,0 +1,16 @@ + +Executables should have embedded plist on macOS +Description of problem: +QEMU binaries on macOS should have an embedded property list (`plist`). + +The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). + +When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier). + +All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary: + +``` +-sectcreate __TEXT __info_plist YourPlistFile.plist +``` + +This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code. diff --git a/results/classifier/deepseek-2-tmp/output/files/103 b/results/classifier/deepseek-2-tmp/output/files/103 new file mode 100644 index 000000000..85b678925 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/103 @@ -0,0 +1,2 @@ + +9pfs does not honor open file handles on unlinked files diff --git a/results/classifier/deepseek-2-tmp/output/files/1074 b/results/classifier/deepseek-2-tmp/output/files/1074 new file mode 100644 index 000000000..b36b01ff7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1074 @@ -0,0 +1,19 @@ + +File under symlink gets corrupted when directory is mounted as FAT32 drive +Description of problem: +When mouting a directory as a FAT32 drive, the symlinked BOOTx64.EFI inside gets corrupted after booting it. +Steps to reproduce: +1. mkdir -p fat_dir/EFI/BOOT/ +2. ln -s BOOTx64.EFI fat_dir/EFI/BOOT/BOOTx64.EFI +3. md5sum BOOTx64.EFI +4. Run qemu with arguments like above. +5. md5sum BOOTx64.EFI should print out different hash, confirming corruption. +Additional information: +[BOOTx64.EFI](/uploads/d0a6e899ec9331461179f8dc82fbc421/BOOTx64.EFI) + +The issue was not visible on earlier versions, but I don't know which one exactly was it.\ +I can only say, it was still working in April and it was possible that I was using Fedora 36 Beta. + +Copying the file instead of using a symlink can be used as a workaround. + +The binary should print some debug stuff, like avaliable memory regions and end with an infinite halt-loop. diff --git a/results/classifier/deepseek-2-tmp/output/files/1090615 b/results/classifier/deepseek-2-tmp/output/files/1090615 new file mode 100644 index 000000000..50e7af8f3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1090615 @@ -0,0 +1,28 @@ + + RFE: More info in qemu-img info/check + +Originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=861375 + +""" +qemu-img info currently give me info like this: + +image: /home/alex/.local/share/gnome-boxes/images/Fedora 16 +file format: qcow2 +virtual size: 11G (11794287616 bytes) +disk size: 4.5G +cluster_size: 65536 + +In order to figure out the "health" of an image there is some more information I would like: + +in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations + +amount of compressed clusters. I.e. "is it useful to re-compress the image". + +Fragmentation estimation. + +This would be useful to both sysadmins in general and for automated things like +what we want to do in gnome-boxes: +https://bugzilla.gnome.org/show_bug.cgi?id=685032 +""" + +As mentioned in the original report, qemu-img check currently has fragmentation stats, but only for QED. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1101 b/results/classifier/deepseek-2-tmp/output/files/1101 new file mode 100644 index 000000000..0cd9c18c9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1101 @@ -0,0 +1,13 @@ + +QEMU 7.0.0 corrupts VHDX and VHD (VPC) files on write. +Description of problem: +QEMU writes to VHDX and VHD (VPC) files produce a corrupt/non-compliant image. +QEMU appears to be able to read VHDX and VHD images correctly. + +This problem manifests in at least two cases +1. When attaching a VHDX/VHD file to a QEMU machine. A previously working OS image created using the Hyper-V and imaging tools boots properly, but writes that normally occur in the running VM are not written out correctly. The image will fail to boot the next time due to corruption. +2. Image conversion operations *TO* VHDX/VHD fail. (note that QEMU correctly converts *FROM* VHDX/VHD assuming a well formed input image). This implies that reads to VHDX/VHD are OK, but writes to VHDX/VHD are NOT OK. +Steps to reproduce: +1. See Above. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/1103868 b/results/classifier/deepseek-2-tmp/output/files/1103868 new file mode 100644 index 000000000..39396747c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1103868 @@ -0,0 +1,47 @@ + +drive_mirror crashes on full disk copy of a resized disk with a backing file + +This bug was discovered using libvirt on ubuntu with a build of qemu 1.3 but it is trivailly reproducible with the curent git version. + +Repro steps: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror -f vda test +Formatting 'test', fmt=qcow2 size=67108864 encryption=off cluster_size=65536 lazy_refcounts=off +qemu-system-x86_64: /build/buildd/qemu-1.3.0+dfsg/block/mirror.c:129: mirror_run: Assertion `n > 0' failed. +Aborted + +Note that the command works just fine if the front image is not resized: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if the backing file is resized as well: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-img resize /home/vishvananda/base 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if we don't use -f when creating the mirror: + +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror vda test +Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off + +although in this final case the mirror is created the same size as the backing file which seems wrong: + +qemu-img info test +image: test +file format: qcow2 +virtual size: 32M (33554432 bytes) +disk size: 196K +cluster_size: 65536 +backing file: base +backing file format: qcow2 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1116 b/results/classifier/deepseek-2-tmp/output/files/1116 new file mode 100644 index 000000000..5acc502f0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1116 @@ -0,0 +1,19 @@ + +qemu/build/qemu-bundle/var/local/run is linked to qemu/qga/run which doesn't exist after building qemu +Description of problem: +A file qemu/build/qemu-bundle/var/local/run is generated after building qemu and this file is linked to qemu/qga/run which doesn't exist. + +[root@b49691d8db1c local]# ls /home/lxy/qemu/build/qemu-bundle/var/local -hl +total 0 +lrwxrwxrwx. 1 root root 22 Jul 22 00:06 run -> /home/lxy/qemu/qga/run +[root@b49691d8db1c local]# ls -hl /home/lxy/qemu/qga/run +ls: cannot access '/home/lxy/qemu/qga/run': No such file or directory +Steps to reproduce: +1. git clone https://gitlab.com/qemu-project/qemu.git +2. cd qemu/ +3. ./configure --target-list=x86_64-softmmu --enable-kvm +4. make -j100 && make install +5. ls ./build/qemu-bundle/var/local -hl +6. ls -hl ./qga/run +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/1123975 b/results/classifier/deepseek-2-tmp/output/files/1123975 new file mode 100644 index 000000000..93785004b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1123975 @@ -0,0 +1,31 @@ + +QEmu 1.3+ cannot restore a 1.1- live snapshot made in qemu-kvm + +I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: + +virsh # snapshot-revert fgtbbuild wtb +error: operation failed: Error -22 while loading VM state + +I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. + + +ipxe-qemu 1.0.0+git-20120202.f6840ba-3 +qemu 1.4.0~rc0+dfsg-1exp +qemu-keymaps 1.4.0~rc0+dfsg-1exp +qemu-kvm 1.4.0~rc0+dfsg-1exp +qemu-system 1.4.0~rc0+dfsg-1exp +qemu-system-arm 1.4.0~rc0+dfsg-1exp +qemu-system-common 1.4.0~rc0+dfsg-1exp +qemu-system-mips 1.4.0~rc0+dfsg-1exp +qemu-system-misc 1.4.0~rc0+dfsg-1exp +qemu-system-ppc 1.4.0~rc0+dfsg-1exp +qemu-system-sparc 1.4.0~rc0+dfsg-1exp +qemu-system-x86 1.4.0~rc0+dfsg-1exp +qemu-user 1.4.0~rc0+dfsg-1exp +qemu-utils 1.4.0~rc0+dfsg-1exp +libvirt-bin 1.0.2-1 +libvirt-dev 1.0.2-1 +libvirt-doc 1.0.2-1 +libvirt-glib-1.0-0 0.1.2-1 +libvirt0 1.0.2-1 +libvirtodbc0 6.1.4+dfsg1-5 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1133668 b/results/classifier/deepseek-2-tmp/output/files/1133668 new file mode 100644 index 000000000..26ef420bd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1133668 @@ -0,0 +1,6 @@ + +Bad validate ELF MIPSel format + +Detail and temporary path: + +http://www.devttys0.com/2011/12/qemu-vs-sstrip/#comment-10161 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1144 b/results/classifier/deepseek-2-tmp/output/files/1144 new file mode 100644 index 000000000..da08785d6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1144 @@ -0,0 +1,14 @@ + +Cannot install on ArcoLinux +Description of problem: +I tried to install with my package manager +``` +paru -S qemu-git +``` +and got these errors +``` +qemu-git: /usr/share/qemu/bios-microvm.bin exists in filesystem (owned by seabios) +qemu-git: /usr/share/qemu/vgabios-ati.bin exists in filesystem (owned by seabios) +``` + +I tried searching around for a solution but I can't seem to find anything relevant to my situation. diff --git a/results/classifier/deepseek-2-tmp/output/files/117 b/results/classifier/deepseek-2-tmp/output/files/117 new file mode 100644 index 000000000..5b94a19c6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/117 @@ -0,0 +1,2 @@ + +nested 9p filesystem with security_model=mapped-xattr diff --git a/results/classifier/deepseek-2-tmp/output/files/1179 b/results/classifier/deepseek-2-tmp/output/files/1179 new file mode 100644 index 000000000..7702ed671 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1179 @@ -0,0 +1,66 @@ + +qemu-img snapshot would break win8.1's system disk data +Description of problem: +`qemu-img snapshot` will cause a damage on windows 8.1 virtual machine +Steps to reproduce: +1.shutdown the virtual machine + +2.exec command +``` +$ qemu-img snapshot -d standard /media/user/SSD_VM/disk/win8_1.qcow2 +... +ERROR cluster 554329 refcount=0 reference=1 +ERROR cluster 554330 refcount=0 reference=1 +ERROR cluster 554331 refcount=0 reference=1 +ERROR cluster 554332 refcount=0 reference=1 +ERROR cluster 554333 refcount=0 reference=1 +ERROR cluster 554334 refcount=0 reference=1 +ERROR cluster 554335 refcount=0 reference=1 +Leaked cluster 557183 refcount=2 reference=1 +Leaked cluster 557472 refcount=2 reference=1 +Leaked cluster 564785 refcount=2 reference=1 +... +Leaked cluster 580393 refcount=2 reference=1 +Leaked cluster 580434 refcount=2 reference=1 +Leaked cluster 580713 refcount=2 reference=1 +Leaked cluster 580718 refcount=2 reference=1 +Leaked cluster 580726 refcount=2 reference=1 +Leaked cluster 580965 refcount=2 reference=1 +Leaked cluster 581268 refcount=2 reference=1 +Leaked cluster 581280 refcount=2 reference=1 +Leaked cluster 581367 refcount=2 reference=1 +Leaked cluster 582743 refcount=2 reference=1 +Leaked cluster 582938 refcount=2 reference=1 +Leaked cluster 583026 refcount=2 reference=1 +Leaked cluster 583027 refcount=2 reference=1 +Leaked cluster 583028 refcount=2 reference=1 +Leaked cluster 583029 refcount=2 reference=1 +Rebuilding refcount structure +Repairing cluster 547917 refcount=1 reference=0 +Repairing cluster 547936 refcount=1 reference=0 +Repairing cluster 547955 refcount=1 reference=0 +Repairing cluster 548069 refcount=1 reference=0 +Repairing cluster 548092 refcount=1 reference=0 +Repairing cluster 548115 refcount=1 reference=0 +Repairing cluster 548125 refcount=1 reference=0 +Repairing cluster 548128 refcount=1 reference=0 +Repairing cluster 548130 refcount=1 reference=0 +Repairing cluster 548144 refcount=1 reference=0 +Repairing cluster 548146 refcount=1 reference=0 +Repairing cluster 548150 refcount=1 reference=0 +Repairing cluster 548199 refcount=1 reference=0 +Repairing cluster 548201 refcount=1 reference=0 +Repairing cluster 548226 refcount=1 reference=0 +Repairing cluster 548234 refcount=1 reference=0 +Repairing cluster 548236 refcount=1 reference=0 +Repairing cluster 557073 refcount=1 reference=0 +Repairing cluster 557074 refcount=1 reference=0 +... + +``` + +3.start the virtual machine , it shows blue screen error: +`UNEXPECTED_STORE_EXCPETION` + +Additional information: +the windows virtual machine will automatically fix the damage that qemu-img caused on next restart . diff --git a/results/classifier/deepseek-2-tmp/output/files/1184089 b/results/classifier/deepseek-2-tmp/output/files/1184089 new file mode 100644 index 000000000..3c588665c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1184089 @@ -0,0 +1,13 @@ + +[Feature request] loadvm snapshot as read-only + +There are many ways to take and manage snapshots in QEMU, but one main feature that's missing is the ability to 'loadvm' a LIVE snapshot and have all future changes redirected to a temporary file. This would effectively be combining the -loadvm and -snapshot switches and make the snapshot read-only. With this feature, users would be provided a "sandbox" and be able to start and restart the same live snapshot without corrupting the image in doing so. + +I found a lot of discussion about this topic on the mailing list years ago, including some patch submissions, but none of the conversations panned out. + +http://lists.gnu.org/archive/html/qemu-discuss/2011-10/msg00011.html +http://copilotco.com/mail-archives/qemu.2008/msg00072.html +http://web.archiveorange.com/archive/v/1XS1vcusGInZKG2e0ImX +http://marc.info/?l=qemu-devel&m=117191084713590 + +What would it take for this feature to be added, and can we use the patches submitted by Eddie Kohler to enable this feature? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1216 b/results/classifier/deepseek-2-tmp/output/files/1216 new file mode 100644 index 000000000..6b3f488eb --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1216 @@ -0,0 +1,10 @@ + +System crashes/hangs when running qemu-img convert +Description of problem: +**Upon running the above command, the Virtual Machine simply crashes and is irrecoverable** +Steps to reproduce: +1. **Start Ubuntu 20.04 or SIFT Workstation** +2. **sudo apt-get install qemu** +3. **qemu-img convert -O raw JEA.vmdk JEA.vmdk.raw** +Additional information: +I have also run this on macOS and it just hangs and never completes diff --git a/results/classifier/deepseek-2-tmp/output/files/1224414 b/results/classifier/deepseek-2-tmp/output/files/1224414 new file mode 100644 index 000000000..5101d414f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1224414 @@ -0,0 +1,19 @@ + +dtc/.git file included in release tarball + +The release tarballs include the dtc/.git submodule file, causing when working git in some circumstances (e.g. doing git clean -fxd in a parent git repository): + +$ mkdir foo && cd foo +$ git init +$ echo yo >bar +$ curl http://wiki.qemu-project.org/download/qemu-1.6.0.tar.bz2 +$ tar xjf qemu-1.6.0.tar.bz2 +$ git clean -fxd +Removing bar +Removing qemu-1.6.0.tar.bz2 +Removing qemu-1.6.0/ +fatal: Not a git repository: qemu-1.6.0/pixman/../.git/modules/pixman + +Leaving the qemu-1.6.0 directory intact. + +So, my suggestion is, would it be possible to filter out the .git file from the release tarball when building a release? Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1245724 b/results/classifier/deepseek-2-tmp/output/files/1245724 new file mode 100644 index 000000000..670e8e5c4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1245724 @@ -0,0 +1,14 @@ + +libfdt.a git compilation fail + +I don't know the commit tags but I checked out dtc on the 28 of october at 20:27 in the tree of qemu (also git checkout out tonight). The compilation fail at line 234 in qemu/dtc/Makefile so I inserted that line: + +@$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + +into the makefile at position 234 to see what is the exact problem but the strace log is inconclusive. + +for the error: /usr/bin/ar: deux operations différentes spécifiées + +liberal translation is: two different operation specified. + +the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and kernel kvm-3.12.0-rc5 from git. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1261320 b/results/classifier/deepseek-2-tmp/output/files/1261320 new file mode 100644 index 000000000..2e7993535 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1261320 @@ -0,0 +1,16 @@ + +Virtual Disk with over 16TB + +Hi, + +is there a option to create a disk for a vm with a size over 16TB. + +the problem that after the diskfile reach 16TB, the disk get a state of read-only at this limit. +I know, that 16TB file size is max, is there a option to create the disk in mutliple files? +we want to use 22 TB. in the VM + +To attach a partition directly to the vm, is not what we want to do. + +best regards + +Chris \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1285505 b/results/classifier/deepseek-2-tmp/output/files/1285505 new file mode 100644 index 000000000..5ac4263ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1285505 @@ -0,0 +1,22 @@ + +[ppa 2.0~git-20140225] SIGABRT with -virtfs + +As requested on u-devel@, I tested QEMU 2.0~git-20140225.aa0d1f4-0ubuntu2 from ppa:ubuntu-virt/candidate. This has a regression with virtfs. + +I created a simple cloud-image based VM with autopkgtest: + + $ sudo apt-get install autopkgtest + $ adt-buildvm-ubuntu-cloud + $ mkdir -p /tmp/shared + $ qemu-system-x86_64 -enable-kvm -m 1024 -nographic -virtfs local,id=autopkgtest,path=/tmp/shared,security_model=none,mount_tag=myshare -snapshot adt-trusty-amd64-cloud.img +** +ERROR:/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c:331:object_initialize_with_type: assertion failed: (type != NULL) +Abgebrochen (Speicherabzug geschrieben) + +It should be easy enough to reproduce and the assertion message already should be clear, but this is the intersting part of the (unretraced) stack trace: + + #2 0x00007fe3329a9195 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x7fe334c5a8e8 "/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c", line=line@entry=331, func=func@entry=0x7fe334c5ac40 "object_initialize_with_type", message=message@entry=0x7fe336e06e40 "assertion failed: (type != NULL)") at /build/buildd/glib2.0-2.39.90/./glib/gtestutils.c:2291 + lstr = "331\000\377\177\000\000\320ޠF\377\177\000\000\220\026\321\066\343\177\000\000R\252\305\064\343\177\000" + s = 0x7fe336e06e70 "pp\340\066\343\177" + #3 0x00007fe3329a922a in g_assertion_message_expr (domain=0x0, file=0x7fe334c5a8e8 "/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c", line=331, func=0x7fe334c5ac40 "object_initialize_with_type", expr=<optimized out>) at /build/buildd/glib2.0-2.39.90/./glib/gtestutils.c:2306 + s = 0x7fe336e06e40 "assertion failed: (type != NULL)" \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1287 b/results/classifier/deepseek-2-tmp/output/files/1287 new file mode 100644 index 000000000..2c7a2cddd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1287 @@ -0,0 +1,11 @@ + +qemu-img info foo.qcow2 tries to get write lock +Description of problem: +When trying to run qemu-img info on an image which is used by QEMU qemu-img tries to acquire a write lock. Ideally this would not attempt to acquire a write lock and let qemu-img info succeed. +``` +[jelle@t14s][/tmp]%qemu-img info /var/tmp/cockpit-qr_j3e_m.qcow2 +qemu-img: Could not open '/var/tmp/cockpit-qr_j3e_m.qcow2': Failed to get shared "write" lock +Is another process using the image [/var/tmp/cockpit-qr_j3e_m.qcow2]? +``` +Steps to reproduce: +1. Run qemu-img on an image used by a QEMU process. diff --git a/results/classifier/deepseek-2-tmp/output/files/1289898 b/results/classifier/deepseek-2-tmp/output/files/1289898 new file mode 100644 index 000000000..b005995cc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1289898 @@ -0,0 +1,8 @@ + +qemu-system-ppc64 easily cause file corruption + +the qemu-system-ppc64 is used to run Fedora-19 on RHEL 5.3. +Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: + +* using scp to transfer a tar.bz file from the RHEL 5.3 host to the Fedora-19 PPC VM, found the size is correct, but the content is corrupted from the middle of the 80+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1299190 b/results/classifier/deepseek-2-tmp/output/files/1299190 new file mode 100644 index 000000000..676b53472 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1299190 @@ -0,0 +1,8 @@ + +Access to /proc/self/exe in linux-user mode + +This is based on a recent bug in GCC Bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 + +It looks like libbacktrace (GCC runtime library used for obtaining stack traces) uses /proc/self/exe for error reporting. Currently this is mapped to qemu-arm which effectively disables libbacktrace on linux-user. + +It seems that QEMU already supports /proc/self/{maps,stat,auxv} so addition of /proc/self/exe may be trivial. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1300863 b/results/classifier/deepseek-2-tmp/output/files/1300863 new file mode 100644 index 000000000..f37c4379c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1300863 @@ -0,0 +1,8 @@ + +Qemu does not show all files on floppy or hard drive (MS DOS 6.22 guest) + +My host system is a raspberry pi model B 512MB. To start qemu I typed into lxterminal: + +qemu-system-i386 -hda qemu.img -Fda Dos622-1.img -boot a + +Qemu version 1.7.0+dfsg-3 installed as package. The DOS disks were downloaded from winworldpc.com and if I mount them under Linux I see all the files, but on qemu I see the first 3 files only. The hard drive image I am using is a 30MB flat image created using bximage. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1321028 b/results/classifier/deepseek-2-tmp/output/files/1321028 new file mode 100644 index 000000000..aea72c122 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1321028 @@ -0,0 +1,48 @@ + +qemu-system-ppc : file systems are not shutting down clean + + + + +Launching a VM that has been shutdown gracefully ( via init 0) typically requires fsck to run when it is started ; +This indications data integrity issues; + + + The symptom can be seen by observing the fsck running when the VM restarted. + +Install 14-04-LTS to a VM and the issue can be seen ; + + + +(trusty)vnc@jade-rev4:/home2/qemu$ cat vm1/go.sh +mymac="52:54:00:12:34:10" +T=` echo $mymac | cut -d: -f5,6 | sed s/\://` +mytap="tap$T" + + +tunctl -d $mytap +tunctl -t $mytap + + /usr/bin/qemu-system-ppc -M ppce500 -nographic -kernel jade-kernel.bin \ + -initrd jade-initrd-2.0.bin -m 1G -enable-kvm \ + -drive file=jade-ubuntu-14.04.raw,if=virtio \ + -net nic,vlan=0,macaddr=$mymac \ + -net tap,vlan=0,ifname=$mytap,script=/usr/local/bin/qemu-ifup \ + -append "console=ttyS0 ssgyboot=break" \ + -no-shutdown -no-reboot -name `basename $fp` + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1 +ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9 +Uname: Linux 3.13.0-24-powerpc-e500mc ppc +ApportVersion: 2.14.1-0ubuntu3 +Architecture: powerpc +Date: Mon May 19 17:01:14 2014 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu +UpgradeStatus: Upgraded to trusty on 2014-04-29 (20 days ago) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1324724 b/results/classifier/deepseek-2-tmp/output/files/1324724 new file mode 100644 index 000000000..d4fa1fa23 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1324724 @@ -0,0 +1,21 @@ + +make install fails if running strip + +I do: + ./configure --target-list=arm-softmmu + make + sudo make install + +and see: +install -d -m 0755 "/usr/local/bin" +libtool --quiet --mode=install install -c -m 0755 qemu-ga qemu-nbd qemu-img qemu-io fsdev/virtfs-proxy-helper "/usr/local/bin" +strip "/usr/local/bin/qemu-ga" "/usr/local/bin/qemu-nbd" "/usr/local/bin/qemu-img" "/usr/local/bin/qemu-io" "/usr/local/bin/fsdev/virtfs-proxy-helper" +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file +Makefile:379: recipe for target 'install' failed +make: *** [install] Error 1 + + +Host is Odroid-XU running Debian Jessie. +Source is at d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-peter' + +libtool version 2.4.2-1.7 armhf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1332297 b/results/classifier/deepseek-2-tmp/output/files/1332297 new file mode 100644 index 000000000..ea1658820 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1332297 @@ -0,0 +1,13 @@ + +qemu-img: crash on check of an image with large value in the 'size' header field + +The qemu-img crashes on the next command: + +qemu-img check test_image + +'test_image' can be found in the attachment. It's a fuzzed test image with the qcow2 image header only. Suppositional cause of the failure is the value of 'size' header field set to maximum uint_64 value. + +System information: + +qemu.git: 6baa963f4dcc2118 +Host: Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1336794 b/results/classifier/deepseek-2-tmp/output/files/1336794 new file mode 100644 index 000000000..b94fe436f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1336794 @@ -0,0 +1,57 @@ + +9pfs does not honor open file handles on unlinked files + +This was originally filed over here: https://bugzilla.redhat.com/show_bug.cgi?id=1114221 + +The open-unlink-fstat idiom used in some places to create an anonymous private temporary file does not work in a QEMU guest over a virtio-9p filesystem. + +Version-Release number of selected component (if applicable): + +qemu-kvm-1.6.2-6.fc20.x86_64 +qemu-system-x86-1.6.2-6.fc20.x86_64 +(those are fedora RPMs) + +How reproducible: + +Always. See this example C program: + +https://bugzilla.redhat.com/attachment.cgi?id=913069 + +Steps to Reproduce: +1. Export a filesystem with virt-manager for the guest. + (type: mount, driver: default, mode: passthrough) +2. Start guest and mount that filesystem + (mount -t 9p -o trans=virtio,version=9p2000.L ...) +3. Run a program that uses open-unlink-fstat + (in my case it was trying to compile Perl 5.20) + +Actual results: + +fstat fails: + +open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) +close(3) + +Expected results: + +open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 +fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +close(3) + +Additional info: + +There was a patch put into the kernel back in '07 to handle this very problem for other filesystems; maybe its helpful: + + http://lwn.net/Articles/251228/ + +There is also a thread on LKML from last December specifically about this very problem: + + https://lkml.org/lkml/2013/12/31/163 + +There was a discussion on the QEMU list back in '11 that doesn't seem to have come to a conclusion, but did provide the test program that i've attached to this report: + + http://marc.info/?l=qemu-devel&m=130443605720648&w=2 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1342704 b/results/classifier/deepseek-2-tmp/output/files/1342704 new file mode 100644 index 000000000..b7be9f984 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1342704 @@ -0,0 +1,16 @@ + +error: Crash of qemu-img/qemu-io on the qcow2 image with large values in 'incompatible features' field + +qemu-io and qemu-img fails with an assertion (see below) at attempt to interact with the qcow2 image having large values in the 'incompatible features' header field. + + util/error.c:34: error_set: Assertion `*errp == ((void *)0)' failed. + + +The backtrace file and the test image can be found in the attachment. The backtraces are for the next command: + + qemu-img check -f qcow2 test_image + + +The image was generated by the qcow2 image fuzzer. + +qemu.git head: 5a7348045091a2bc15 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1349972 b/results/classifier/deepseek-2-tmp/output/files/1349972 new file mode 100644 index 000000000..750da9586 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1349972 @@ -0,0 +1,20 @@ + + qcow2-refcount: qemu-io crashes on 'discard' command + +qemu-io is killed by SIGIOT at the 'discard' command on the image having no refcount information. + +Sequence: +1. Unpack test.img and backing_img.qed in the same directory (see the attached archives for images) +2. Make a copy of test.img to copy.img (qemu-io modifies the image before being kill, therefore the image backup is necessary) +3. Run the command + +qemu-io copy.img -c 'discard 2210816 2856448' + +Result: qemu-io is killed by SIGIOT with the reason: + +qemu-io: block/qcow2-refcount.c:468: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. + + +The image was generated by the image fuzzer. + +qemu.git HEAD: 1d80eb7a680d \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1354167 b/results/classifier/deepseek-2-tmp/output/files/1354167 new file mode 100644 index 000000000..254e6cb19 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1354167 @@ -0,0 +1,30 @@ + +On VM restart: Could not open 'poppy.qcow2': Could not read snapshots: File too large + +I'm unable to restart a VM. virt-manager is giving me: + +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -drive file=/var/lib/libvirt/images/poppy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /var/lib/libvirt/images/poppy.qcow2: Could not read snapshots: File too large + + +From the command line trying to check the image also gives me: +qemu-img check poppy.qcow2 +qemu-img: Could not open 'poppy.qcow2': Could not read snapshots: File too large + + +This bug appears with both the default install of qemu for ubuntu 14.04: +qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard + +And the latest version. +qemu-img version 2.1.50, Copyright (c) 2004-2008 Fabrice Bellard + + +Host: +Dual E5-2650 v2 @ 2.60GHz +32GB Memory +4TB Disk space (2.1TB Free) + +Host OS: Ubuntu 14.04.1 LTS 64bit + +Guest: +Ubuntu 14.04 64bit +Storage Size: 500gb \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1354529 b/results/classifier/deepseek-2-tmp/output/files/1354529 new file mode 100644 index 000000000..ffdbb95ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1354529 @@ -0,0 +1,18 @@ + +qemu-io: Assert failure on the fuzzed qcow2 image + +'qemu-io -c write' failed on the fuzzed image with missed refcount tables: + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.cow in the same directory + 3. Execute + qemu-io copy.img -c 'write 2856960 208896' + +Result: qemu-io was killed by SIGIOT with the reason: + +qemu-io: block/qcow2-cluster.c:910: handle_copied: Assertion `*host_offset == 0 +|| offset_into_cluster(s, guest_offset) == offset_into_cluster(s, *host_offset)' + failed. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1355697 b/results/classifier/deepseek-2-tmp/output/files/1355697 new file mode 100644 index 000000000..75f17cfad --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1355697 @@ -0,0 +1,18 @@ + +qemu-img: Segfault on a fuzzed image with large values of L1/L2 entries + +'qemu-img check -r all/leaks' failed with a segmentation fault on the fuzzed image with L1/L2 entry values having UINT64 border values. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.raw in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGSEGV. + +The qemu-img execution log can be found in the attached archive. + + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1355738 b/results/classifier/deepseek-2-tmp/output/files/1355738 new file mode 100644 index 000000000..80f84150a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1355738 @@ -0,0 +1,19 @@ + +qemu-img: Killed by SIGTRAP on check of the fuzzed image + +'qemu-img check -r all' was killed by SIGTRAP. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.qed in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGTRAP with the reason: + +(process:2210): GLib-ERROR **: gmem.c:140: failed to allocate 18446744069633940288 bytes + +The qemu-img execution log can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1357 b/results/classifier/deepseek-2-tmp/output/files/1357 new file mode 100644 index 000000000..c90b5cc88 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1357 @@ -0,0 +1,10 @@ + +qemu-img should generate VMDK with an EOS marker when `has_marker` flag enabled +Additional information: +I generate a empty volume with capacity 1G and try to deploy it as a part of OVF. This would fail. + +But when I append an EOS marker to that VMDK, which is actually a zeroed sector, the deployed procedure succeeded. + +This case merely happened if VMDK has data, since `qemu-img` always write at least one grain(64 KB). So the padding part will be recognized as EOS marker. + +I have written a temporary patch for this and it works fine for me. I'm glad to send it for review. diff --git a/results/classifier/deepseek-2-tmp/output/files/1357440 b/results/classifier/deepseek-2-tmp/output/files/1357440 new file mode 100644 index 000000000..9b59c9ea2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1357440 @@ -0,0 +1,16 @@ + +qemu-img: Assert for 'amend' command and the fuzzed image + +'qemu-img amend' failed with the assert on the fuzzed image. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.vdi in the same directory + 3. Execute + qemu-img amend -o compat=0.10 -f qcow2 copy.img + +Result: qemu-img was killed by SIGIOT with the reason: + +qemu-img: block/qcow2-cluster.c:1598: expand_zero_clusters_in_l1: Assertion `(cluster_index >= 0) && (cluster_index < *nb_clusters)' failed. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1358287 b/results/classifier/deepseek-2-tmp/output/files/1358287 new file mode 100644 index 000000000..f71d6fab5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1358287 @@ -0,0 +1,13 @@ + +-readconfig file doesn't interpret memory size correctly + +I'm running Qemu 2.1 and have issues with the config file format. + +Specifically Qemu wrote the following snippet with '-writeconfig': + +[memory] + size = "1024" + +However, upon starting a VM with this setting it only receives 128MiB (the default size). + +I'm reverting back to using the command line option now - that works. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1359 b/results/classifier/deepseek-2-tmp/output/files/1359 new file mode 100644 index 000000000..d9e9c80f0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1359 @@ -0,0 +1,2 @@ + +open virtual format diff --git a/results/classifier/deepseek-2-tmp/output/files/136 b/results/classifier/deepseek-2-tmp/output/files/136 new file mode 100644 index 000000000..3eb5f0cba --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/136 @@ -0,0 +1,2 @@ + +windows qemu-img create vpc/vhdx error diff --git a/results/classifier/deepseek-2-tmp/output/files/1368815 b/results/classifier/deepseek-2-tmp/output/files/1368815 new file mode 100644 index 000000000..af572da96 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1368815 @@ -0,0 +1,38 @@ + +qemu-img convert intermittently corrupts output images + +-- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on Ubuntu 14.04 using Ext4 filesystems. + +The command + + qemu-img convert -O raw inputimage.qcow2 outputimage.raw + +intermittently creates corrupted output images, when the input image is not yet fully synchronized to disk. While the issue has actually been discovered in operation of of OpenStack nova, it can be reproduced "easily" on command line using + + cat $SRC_PATH > $TMP_PATH && $QEMU_IMG_PATH convert -O raw $TMP_PATH $DST_PATH && cksum $DST_PATH + +on filesystems exposing this behavior. (The difficult part of this exercise is to prepare a filesystem to reliably trigger this race. On my test machine some filesystems are affected while other aren't, and unfortunately I haven't found the relevant difference between them, yet. Possible it's timing issues completely out of userspace control ...) + +The root cause, however, is the same as in + + http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html + +and it can be solved the same way as suggested in + + http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html + +In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change + + f.fm.fm_flags = 0; + +to + + f.fm.fm_flags = FIEMAP_FLAG_SYNC; + +As discussed in the thread mentioned above, retrieving a page cache coherent map of file extents is possible only after fsync on that file. + +See also + + https://bugs.launchpad.net/nova/+bug/1350766 + +In that bug report filed against nova, fsync had been suggested to be performed by the framework invoking qemu-img. However, as the choice of fiemap -- implying this otherwise unneeded fsync of a temporary file -- is not made by the caller but by qemu-img, I agree with the nova bug reviewer's objection to put it into nova. The fsync should instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC, specifically intended for that purpose. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1388 b/results/classifier/deepseek-2-tmp/output/files/1388 new file mode 100644 index 000000000..aa67d82fa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1388 @@ -0,0 +1,15 @@ + +QEMU 7.2.0 - Update file repository with x86/x64 Windows installer +Description of problem: +In file repository + +https://qemu.weilnetz.de/w32/ +https://qemu.weilnetz.de/w64/ + +are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0. + +The latest version is 7.2.0.RC4 (08.12.2022). + +Thanks. +Steps to reproduce: + diff --git a/results/classifier/deepseek-2-tmp/output/files/1396497 b/results/classifier/deepseek-2-tmp/output/files/1396497 new file mode 100644 index 000000000..a61e3bb57 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1396497 @@ -0,0 +1,76 @@ + +'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot + +qemu-img _may_ be working as designed, but it feels like this could be a bug. I'd certainly prefer to only allow unique snapshot names (unless maybe something like a "--force-non-unique-snapshot-names" was also specified). + +If this really is correct behaviour, it should be documented as qemu-img(1) currently specifies no details whatsoever regarding expected behaviour or valid snapshot names. + +$ qemu-img snapshot -l image.cow +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +$ + +Note also how snapshot deletion works in reverse order - the oldest snapshot with a given name is deleted first. + +ProblemType: Bug +DistroRelease: Ubuntu 15.04 +Package: qemu-utils 2.1+dfsg-4ubuntu9 +ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7 +Uname: Linux 3.16.0-25-generic x86_64 +ApportVersion: 2.14.7-0ubuntu10 +Architecture: amd64 +CurrentDesktop: Unity +Date: Wed Nov 26 08:28:16 2014 +InstallationDate: Installed on 2014-04-11 (228 days ago) +InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 719 2 0.0 [kvm-irqfd-clean] +MachineType: LENOVO 20AQCTO1WW +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago) +dmi.bios.date: 02/10/2014 +dmi.bios.vendor: LENOVO +dmi.bios.version: GJET71WW (2.21 ) +dmi.board.asset.tag: Not Available +dmi.board.name: 20AQCTO1WW +dmi.board.vendor: LENOVO +dmi.board.version: 0B98405 STD +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.name: 20AQCTO1WW +dmi.product.version: ThinkPad T440s +dmi.sys.vendor: LENOVO \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1410288 b/results/classifier/deepseek-2-tmp/output/files/1410288 new file mode 100644 index 000000000..3f72fd7a2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1410288 @@ -0,0 +1,39 @@ + +qemu-img conversion to qcow2 hangs with blank image less than 100kiB + +If you try to convert a blank image to qcow2 that is less than 100kiB in size then qemu-img hangs trying to seek to the end of the file. + +$ truncate --size 102399 /tmp/temp +$ qemu-img convert -p -O qcow2 /tmp/temp /tmp/temp2.qcow2 + +I'm finding this on all versions of qemu-img v2. + +strace shows a seek loop. + +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 +ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 +_llseek(6, 0, [100000], SEEK_END) = 0 + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-utils 2.0.0+dfsg-2ubuntu1.10 +ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11 +Uname: Linux 3.13.0-43-generic i686 +ApportVersion: 2.14.1-0ubuntu3.6 +Architecture: i386 +Date: Tue Jan 13 14:30:39 2015 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1422307 b/results/classifier/deepseek-2-tmp/output/files/1422307 new file mode 100644 index 000000000..bce0328d2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1422307 @@ -0,0 +1,40 @@ + +qemu-nbd corrupts files + +Dear all, + +On Trusty, in certain situations, try to copy files over a qemu-nbd mounted file system leads to write errors (and thus, file corruption). + +Here is the last example I tried: +-> virtual disk is a VDI disk +-> It has only one partition, in FAT + +Here is my mount process: +# modprobe nbd max_part=63 +# qemu-nbd -c /dev/nbd0 "virtual_disk.vdi" +# partprobe /dev/nbd0 +# mount /dev/nbd0p1 /tmp/mnt/ + +Partition is properly mounted at that point: +/dev/nbd0p1 on /tmp/mnt type vfat (rw) + +Now, when I copy a file (rather big, ~28MB): +# cp file_to_copy /tmp/mnt/ ; sync +# md5sum /tmp/mnt/file_to_copy +2efc9f32e4267782b11d63d2f128a363 /tmp/mnt/file_to_copy +# umount /tmp/mnt +# mount /dev/nbd0p1 /tmp/mnt/ +# md5sum /tmp/mnt/file_to_copy +42b0a3bf73f704d03ce301716d7654de /tmp/mnt/file_to_copy + +The first hash was obviously the right one. + +On a previous attempt I did, I spotted thanks to vbindiff that parts of the file were just filed with 0s instead of actual data. +It will randomly work after several attempts to write. + +Version information: +# qemu-nbd --version +qemu-nbd version 0.0.1 +Written by Anthony Liguori. + +Cheers, \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1429034 b/results/classifier/deepseek-2-tmp/output/files/1429034 new file mode 100644 index 000000000..f628702a0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1429034 @@ -0,0 +1,21 @@ + +qemu abort in qemu_coroutine_enter when multi-thread writing + +qemu release version: 2.2.0 +platform: x86_64 + +qemu would be aborted when there are two threads to write two seperate qcow2 files. + +call stack: + +#0 0x7ffff5e18989 __GI_raise(sig=sig@entry=6) (../nptl/sysdeps/unix/sysv/linux/raise.c:56) +#1 0x7ffff5e1a098 __GI_abort() (abort.c:90) +#2 0x7ffff728c034 qemu_coroutine_enter(co=0x7fffe0004800, opaque=0x0) (qemu-coroutine.c:117) +#3 0x7ffff727df39 bdrv_co_io_em_complete(opaque=0x7ffff7fd6ae0, ret=0) (block.c:4847) +#4 0x7ffff7270314 thread_pool_completion_bh(opaque=0x7fffe0006ad0) (thread-pool.c:187) +#5 0x7ffff726f873 aio_bh_poll(ctx=0x7fffe0001d00) (async.c:82) +#6 0x7ffff728340b aio_dispatch(ctx=0x7fffe0001d00) (aio-posix.c:137) +#7 0x7ffff72837b0 aio_poll(ctx=0x7fffe0001d00, blocking=true) (aio-posix.c:248) +#8 ?? 0x00007ffff72795a8 in bdrv_prwv_co (bs=0x7fffdc0021c0, offset=12071639552, qiov=0x7fffe67fa590, is_write=true, flags=(unknown: 0)) (block.c:2703) +#9 ?? 0x00007ffff727966a in bdrv_rw_co (bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128, is_write=true, flags=(unknown: 0)) (block.c:2726) +#10 0x7ffff7279758 bdrv_write(bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128) (block.c:2760) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1437367 b/results/classifier/deepseek-2-tmp/output/files/1437367 new file mode 100644 index 000000000..fe9d8dc5e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1437367 @@ -0,0 +1,25 @@ + +Qemu guest fails to write files with raw disk (like \\.\PhysicalDrive1) on Windows host. + +Qemu guest fails to write files with specifing raw disk like \\.\PhysicalDrive1 +full command line is below. +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi + +I found the reason is below aio_worker returns -EIO when flush operation. + +https://github.com/qemu/qemu/blob/master/block/raw-win32.c#L95 + +static int aio_worker(void *arg) +... + case QEMU_AIO_FLUSH: + if (!FlushFileBuffers(aiocb->hfile)) { + return -EIO; + } + +FlushFileBuffers always fails with GetLastError() == ERROR_INVALID_FUNCTION +I think this function doesn't support raw device. +For flushing, you might have to issue scsi/ata command or use another way. +Trying to just ignoring this error, writing function seems to be fine for me. + +Thanks +hiroaki \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1450891 b/results/classifier/deepseek-2-tmp/output/files/1450891 new file mode 100644 index 000000000..3224763bc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1450891 @@ -0,0 +1,17 @@ + +VM will not resume on GlusterFS + +oVirt uses libvirt to run QEMU. +Images are passed to QEMU as files, not file descriptors. +When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted. +In this case, the VM goes into paused state. +When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a: +"block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)". + +Please check file-descriptors and reopen image file on 'cont' event in QEMU. +Thanks. + +References: + +[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html +[2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1459622 b/results/classifier/deepseek-2-tmp/output/files/1459622 new file mode 100644 index 000000000..925fe3fdd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1459622 @@ -0,0 +1,10 @@ + +firefox hang with virtfs + +Firefox hangs once it starts to load pages. I tried to delete .cache/mozilla/ and .mozilla/ but it doesn't help. But if I mount tmpfs on to .mozilla (not necessary for .cache/mozilla/), pages loads fine. + +I started the vm as root (sudo) with the following command: qemu-system-x86_64 -enable-kvm -m 4G -virtfs local,mount_tag=qemu,security_model=passthrough,path=/mnt/qemu/ -kernel /mnt/qemu/boot/vmlinuz-linux -initrd /mnt/qemu/boot/initramfs-linux-fallback.img -append 'rw root=qemu fstype=9p' -usbdevice tablet -vga qxl -spice port=12345,disable-ticketing + +/mnt/qemu is a btrfs snapshot of the subvolume used as the host root + +Arch Linux, qemu 2.3.0, firefox 38.0.1 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1462944 b/results/classifier/deepseek-2-tmp/output/files/1462944 new file mode 100644 index 000000000..2cecad778 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1462944 @@ -0,0 +1,12 @@ + +vpc file causes qemu-img to consume lots of time and memory + +The attached vpc file causes 'qemu-img info' to consume 3 or 4 seconds of CPU time and 1.3 GB of heap, causing a minor denial of service. + +$ /usr/bin/time ~/d/qemu/qemu-img info afl12.img +block-vpc: The header checksum of 'afl12.img' is incorrect. +qemu-img: Could not open 'afl12.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated. +1.19user 3.15system 0:04.35elapsed 99%CPU (0avgtext+0avgdata 1324504maxresident)k +0inputs+0outputs (0major+327314minor)pagefaults 0swaps + +The file was found using american-fuzzy-lop. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1467 b/results/classifier/deepseek-2-tmp/output/files/1467 new file mode 100644 index 000000000..c0f2c3a69 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1467 @@ -0,0 +1,2 @@ + +guest agent file filtering diff --git a/results/classifier/deepseek-2-tmp/output/files/1474263 b/results/classifier/deepseek-2-tmp/output/files/1474263 new file mode 100644 index 000000000..865ed3dcd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1474263 @@ -0,0 +1,18 @@ + +"Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver + +Running + +qemu -drive file.driver=vvfat,file.dir=. + +displays + +WARNING: Image format was not specified for 'json:{"dir": ".", "driver": "vvfat"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +However, since "images" provided by the vvfat driver are always raw (and the first sector isn't writeable in any case), this warning is superfluous and should not be displayed. + +A similar warning is displayed for NBD devices; I suspect it should be also disabled for similar reasons, but I'm not sure if serving non-raw images is actually a violation of the protocol. qemu-nbd translates them to raw images, for what it's worth, even if it may be suppressed with -f raw. + +Noticed on 2.3.0; the code that causes this behaviour is still apparently present in today's git master (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you may want to update the copyright notice that qemu -version displays. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1484990 b/results/classifier/deepseek-2-tmp/output/files/1484990 new file mode 100644 index 000000000..316295b13 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1484990 @@ -0,0 +1,20 @@ + +fsfreeze-hook script should also ignored dpkg generated files + +Hello, + +In the fsfreeze-hook script, the following code check if some of the files should be ignored: + + +# Check whether file $1 is a backup or rpm-generated file and should be ignored +is_ignored_file() { + case "$1" in + *~ | *.bak | *.orig | *.rpmnew | *.rpmorig | *.rpmsave | *.sample) + return 0 ;; + esac + return 1 +} + +The functions should probably also skip dpkg generated files. + +I've found a list of the different extensions in the systemd source tree: https://github.com/systemd/systemd/blob/master/src/basic/util.c#L1871 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1490611 b/results/classifier/deepseek-2-tmp/output/files/1490611 new file mode 100644 index 000000000..8c4af689d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1490611 @@ -0,0 +1,49 @@ + +Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid + +Starting with a raw disk image, using "qemu-img convert" to convert from raw to VHD results in the output VHD file's virtual size being aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x 512 bytes per sector), instead of preserving the input file's size as the output VHD's virtual disk size. + +Microsoft Azure requires that disk images (VHDs) submitted for upload have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB, 4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This is reflected in Microsoft's documentation: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-create-upload-vhd-generic/ + +This is reproducible with the following set of commands (including the Azure command line tools from https://github.com/Azure/azure-xplat-cli). For the following example, I used qemu version 2.2.1: + +$ dd if=/dev/zero of=source-disk.img bs=1M count=4096 + +$ stat source-disk.img + File: ‘source-disk.img’ + Size: 4294967296 Blocks: 798656 IO Block: 4096 regular file +Device: fc01h/64513d Inode: 13247963 Links: 1 +Access: (0644/-rw-r--r--) Uid: ( 1000/ smkent) Gid: ( 1000/ smkent) +Access: 2015-08-18 09:48:02.613988480 -0700 +Modify: 2015-08-18 09:48:02.825985646 -0700 +Change: 2015-08-18 09:48:02.825985646 -0700 + Birth: - + +$ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img dest-disk.vhd + +$ stat dest-disk.vhd + File: ‘dest-disk.vhd’ + Size: 4296499712 Blocks: 535216 IO Block: 4096 regular file +Device: fc01h/64513d Inode: 13247964 Links: 1 +Access: (0644/-rw-r--r--) Uid: ( 1000/ smkent) Gid: ( 1000/ smkent) +Access: 2015-08-18 09:50:22.252077624 -0700 +Modify: 2015-08-18 09:49:24.424868868 -0700 +Change: 2015-08-18 09:49:24.424868868 -0700 + Birth: - + +$ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US" +info: Executing command vm image create ++ Retrieving storage accounts +info: VHD size : 4097 MB +info: Uploading 4195800.5 KB +Requested:100.0% Completed:100.0% Running: 0 Time: 1m 0s Speed: 6744 KB/s +info: https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was uploaded successfully +error: The VHD https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an unsupported virtual size of 4296499200 bytes. The size must be a whole number (in MBs). +info: Error information has been recorded to /home/smkent/.azure/azure.err +error: vm image create command failed + +I also ran the above commands using qemu 2.4.0, which resulted in the same error as the conversion behavior is the same. + +However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by Ubuntu 14.04) does not pad the virtual disk size during conversion. Using qemu-img convert from qemu versions <=2.1.1 results in a VHD that is exactly the size of the raw input file plus 512 bytes (for the VHD footer). Those qemu versions do not attempt to realign the disk. As a result, Azure accepts VHD files created using those versions of qemu-img convert for upload. + +Is there a reason why newer qemu realigns the converted VHD file? It would be useful if an option were added to disable this feature, as current versions of qemu cannot be used to create VHD files for Azure using Microsoft's official instructions. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1495 b/results/classifier/deepseek-2-tmp/output/files/1495 new file mode 100644 index 000000000..2454b0d82 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1495 @@ -0,0 +1,7 @@ + +MacOS fails check-unit for test-io-channel-command for some reason +Description of problem: +While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709 +Steps to reproduce: +1. install socat +2. make check-unit diff --git a/results/classifier/deepseek-2-tmp/output/files/152 b/results/classifier/deepseek-2-tmp/output/files/152 new file mode 100644 index 000000000..d52a3b27d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/152 @@ -0,0 +1,2 @@ + +qemu-img compare -m option is missing diff --git a/results/classifier/deepseek-2-tmp/output/files/1524546 b/results/classifier/deepseek-2-tmp/output/files/1524546 new file mode 100644 index 000000000..a83785670 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1524546 @@ -0,0 +1,30 @@ + +qemu-img rebase error message mentions wrong file name + +While doing 'qemu-img rebase' for linking to a different backing file, if the old backing file does not exist, the command fails. During this failure, the error message shown is misleading. +e.g. qemu-img rebase -b <backing_file> <filename> throws error saying "Could not open <filename>" +Ideally it should "Could not open <old_backing_file>" + +snippet - +[root@oxy-dev ~]# qemu-img info /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +image: /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 174M +cluster_size: 65536 +backing file: /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +Format specific information: + compat: 1.1 + lazy refcounts: false +[root@oxy-dev ~]# mv /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +[root@oxy-dev ~]# file !$ +file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383a: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 409600 sectors; partition 2: ID=0x8e, starthead 159, startsector 411648, 16365568 sectors, code offset 0xc0 +[root@oxy-dev ~]# file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383b: cannot open (No such file or directory) +[root@oxy-dev ~]# qemu-img rebase -b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +qemu-img: Could not open '/opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk': Could not open file: No such file or directory +[root@oxy-dev ~]# +qemu-img version 1.5.3 +OS: RHEL7 - 3.10.0-229 +libvirtd (libvirt) 1.2.8 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/154 b/results/classifier/deepseek-2-tmp/output/files/154 new file mode 100644 index 000000000..35976dd58 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/154 @@ -0,0 +1,2 @@ + +readlink(2) returns incorrect size for /proc/self/exe diff --git a/results/classifier/deepseek-2-tmp/output/files/1592590 b/results/classifier/deepseek-2-tmp/output/files/1592590 new file mode 100644 index 000000000..fbb99c1a1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1592590 @@ -0,0 +1,20 @@ + +Prevent qemu-img resize from causing "Active L1 table too large" + +This commit prevents qemu from overallocating if qcow2 image is too big (whatever that means): https://lists.gnu.org/archive/html/qemu-devel/2014-07/msg01481.html + +However, `qemu-img resize` isn't protected by the same code and allows to go beyond that. + +root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 +100000T +Image resized. + +Which then causes "Active L1 table too large" error that cannot be reversed. + +root@nwkr-laptop ~virtkick/hdd # qemu-img info 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 +qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large + +root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 -100000T +qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large + + +I originally faces this bug when I passed wrong parameters to qemu-img in a programatic way which caused an image to go corrupt. It's good to protect user's images from being resized too much. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1596870 b/results/classifier/deepseek-2-tmp/output/files/1596870 new file mode 100644 index 000000000..298f4a8b2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1596870 @@ -0,0 +1,8 @@ + +qemu-img backed over https fails on zero-length file + +When creating new disk with qemu-img backed by file accessed over HTTPS and the backing file has zero length, qemu-img fails with uninformative error: + + qemu-img: disk.qcow2: CURL: Error opening file: + +The error message should either be improved, or the operation on zero-length file should be allowed. Some other backends, as e.g. raw backend for regular files, seem to allow empty files. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1599539 b/results/classifier/deepseek-2-tmp/output/files/1599539 new file mode 100644 index 000000000..de0ef055e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1599539 @@ -0,0 +1,8 @@ + +2.6.0: vvfat driver generates bad FAT entries + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/162 b/results/classifier/deepseek-2-tmp/output/files/162 new file mode 100644 index 000000000..2ad8ab13b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/162 @@ -0,0 +1,2 @@ + +util/path.c/follow_path() does not handle "/" well diff --git a/results/classifier/deepseek-2-tmp/output/files/1626 b/results/classifier/deepseek-2-tmp/output/files/1626 new file mode 100644 index 000000000..865e025b6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1626 @@ -0,0 +1,6 @@ + +QEMU insists on using /var/tmp instead of /tmp +Description of problem: +On a host, our sysadmins have decided for whatever reason that `/var/tmp` is not a thing that normal users can write to (and perhaps that's dumb, but it is what it is and would be a challenging non-technical problem to solve). Whenever QEMU detects the temporary directory is /tmp, it changes it to `/var/tmp` without a mechanism to change it (see https://gitlab.com/qemu-project/qemu/-/commit/69fbfff95e849156985cf95e2010ffc8762e34e6). + +I'm sure in the general case this is fine, but can you add an environment variable or a ./configure option to make this location configurable? I really would like to write to `/tmp`. diff --git a/results/classifier/deepseek-2-tmp/output/files/1644754 b/results/classifier/deepseek-2-tmp/output/files/1644754 new file mode 100644 index 000000000..b519d8515 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1644754 @@ -0,0 +1,99 @@ + +gluster partial reads refusal conflicts with qcow2 + +there is an inconsistency in how qemu creates qcow2 files, which causes an error in the gluster (and possibly other block drivers) + +the problem is that the gluster backend expects the filesize to be 512 byte aligned, which is not the case anymore since 2.7.0 when using the file backend for qcow2 files with a backing file + +the error is then +Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error + +steps to reproduce: + + * create a.qcow2 + * create b.qcow2 with a.qcow2 as base via filesystem (without gluster) + b.qcow2 filesize is not a multiple of 512 bytes + * move both files to a gluster share + * access to b.qcow2 via gluster block driver fails + +example: + +have a gluster server at 'gluster01' with a volume 'gv0' (gluster versions tested: 3.7.15,3.8.5,3.8.5) + +root@pc:~# mount -t glusterfs gluster01:/gv0 /mnt/gluster +root@pc:~# qemu-img create -f qcow2 gluster://gluster01/gv0/foo.qcow2 100M +Formatting 'gluster://gluster01/gv0/foo.qcow2', fmt=qcow2 size=104857600 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/foo.qcow2 +image: /mnt/gluster/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/foo.qcow2 +image: gluster://gluster01/gv0/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 gluster://gluster01/gv0/bar.qcow2 +Formatting 'gluster://gluster01/gv0/bar.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar.qcow2 +image: /mnt/gluster/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar.qcow2 +image: gluster://gluster01/gv0/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: gluster://gluster01/gv0/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 /mnt/gluster/bar2.qcow2 +Formatting '/mnt/gluster/bar2.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar2.qcow2 +image: /mnt/gluster/bar2.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar2.qcow2 +qemu-img: Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error +root@pc:~# ls -l /mnt/gluster/ +total 578 +-rw-r--r-- 1 root root 196616 Nov 25 09:07 bar2.qcow2 +-rw------- 1 root root 197120 Nov 25 09:07 bar.qcow2 +-rw------- 1 root root 197120 Nov 25 09:06 foo.qcow2 +drwxr-xr-x 6 root root 46 Nov 24 16:51 images + +here you can see that the file created with directory path is not 512 byte aligned, while the one created through the gluster api is + +also, when creating a qcow2 with the nfs block driver, the filesize is also a multiple of 512, but reading a non aligned file with nfs works however \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1655764 b/results/classifier/deepseek-2-tmp/output/files/1655764 new file mode 100644 index 000000000..1d308e951 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1655764 @@ -0,0 +1,6 @@ + +qemu-img convert -c compression can't decompress + +Used -c compression option of qemu-img convert to compress qcow2, +then libvirt mount for compressed image don't work as well as decompression also +not working, tried glib-deflate to decompress \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1662050 b/results/classifier/deepseek-2-tmp/output/files/1662050 new file mode 100644 index 000000000..c0405bcbf --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1662050 @@ -0,0 +1,8 @@ + +qemu-img convert a overlay qcow2 image into a entire image + +I have a base image file "base.qcow2" and a delta qcow2 image file "delta.qcow2" whose backing file is "base.qcow2". + +Now I use qemu-img to convert "delta.qcow2" and will get a new image file "new.qcow2" which is complete and equivalent to combination of "base.qcow2" and "delta.qcow2". + +In fact, i just want to convert the delta qcow2 image file and get a new delta overlay qcow2 image file. So the "new.qcow2" is not what i want. I have to admit that this is not bug. Could you please take this as a new feature and enable qemu-img to convert images in-place? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1684239 b/results/classifier/deepseek-2-tmp/output/files/1684239 new file mode 100644 index 000000000..5c521b5cb --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1684239 @@ -0,0 +1,21 @@ + +vvfat core dump when enabling RW + +Hi guys, + +I'm getting this qemu crash message: +>>> qemu-system-x86_64: /build/qemu-TziMIO/qemu-2.5+dfsg/block/vvfat.c:2290: commit_direntries: Assertion `!strncmp(s->directory.pointer, "QEMU", 4)' failed. +>>> Aborted (core dumped) +when launching qemu with this options for a VVFAT drive: +>>> -drive file=fat:rw:./ROOT,if=virtio +(same happens when using cache=none and/or if=ide) + +"uname -a" system info is: +>>> Linux RJZ-WRK-LNX 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +and "qemu --version" is: +>>> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.10), Copyright (c) 2003-2008 Fabrice Bellard + +Not sure what logs to attach but I'll be glad to upload whatever needed. + +Thanks in advance for you help, +Rolando \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1687270 b/results/classifier/deepseek-2-tmp/output/files/1687270 new file mode 100644 index 000000000..1dfc13822 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1687270 @@ -0,0 +1,12 @@ + +Can't write to 9p shared folder with qemu 2.9.0 + +When running a virtual machine with qemu 2.9.0 with this parameter for sharing a folder: + +-virtfs local,id=fsdev1,path=$HOME/git,security_model=none,mount_tag=git + +then the folder is shared to the VM but in some subfolders I can't delete files. The guest system then reports that the file, I want to delete, is "no file or folder". + +I've downgraded to 2.8.0 now, which re-enables deleting my files. + +Is this a known bug which will be fixed with a future version? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1689 b/results/classifier/deepseek-2-tmp/output/files/1689 new file mode 100644 index 000000000..dface34cc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1689 @@ -0,0 +1,12 @@ + +memory backend file unnecessarily requires write permission while it is only mapped privately +Description of problem: +One day I wanted to boot the machine with physical memory initialized with a file, in a copy-on-write style. That is why I tried out `-mem-path` and `-object memory-backend-file`. Actually `-mem-path` already works if not considering that qemu dislikes the backing file being readonly and requires it to be writeable even when only private mappings are used here. + +I sadly found out that when using memory-backend-file, and when `share=off`, if `readonly=on`, then file is `open`ed with `O_RDONLY` and mmap prot is `PROT_READ`; if `readonly=off`, then the file is `open`ed with `O_RDWR` and mmap prot is `PROT_READ|PROT_WRITE`. I want `O_RDONLY` and `PROT_READ|PROT_WRITE` but I cannot find it anywhere. + +In my opinion, expected behavior should be that if `share=off`, the file can already be opened with `O_RDONLY` no matter what prot the mmap is. That is how linux `MAP_PRIVATE` works - basically copy on write. When I only need copy on write for the content of file, why do I require write permission for it? + +Now I cannot find a setup that opens the file with `fd=open(*, O_RDONLY)` and mmap it with `mmap(*, *, PROT_READ|PROT_WRITE, MAP_PRIVATE|*, fd, *)`. + +Tell me if I misunderstood linux (for example certain file behave differently if one open with O_RDONLY and this behavior is necessary) or qemu or other posix systems where copy-on-write does not work like this. diff --git a/results/classifier/deepseek-2-tmp/output/files/1689245 b/results/classifier/deepseek-2-tmp/output/files/1689245 new file mode 100644 index 000000000..d3f1e4771 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1689245 @@ -0,0 +1,9 @@ + +qcow2 image converted from Photon OS can't be started + +Steps to reproduce the issue: +1. Download the ovf from this place: +https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova +2. Extract vmdk from ova file. +3. Convert from vmdk fromat to qcow2 via qeum-img +4. Launch the qcow2 image. The VM is started. But there is no any output. CPU usage is 100% \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1690 b/results/classifier/deepseek-2-tmp/output/files/1690 new file mode 100644 index 000000000..79ac3add9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1690 @@ -0,0 +1,4 @@ + +arguments to specify mapping offsets or map like a elf loader for memory backend file +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/1695169 b/results/classifier/deepseek-2-tmp/output/files/1695169 new file mode 100644 index 000000000..675d974c7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1695169 @@ -0,0 +1,6 @@ + +qga fail to start when pidfile path is missing + +The qga main program has two parameters: "--logfile" and "--pidfile" which specifies the paths to the logfile and pidfile. It assumes that the paths exit in the running OS but if not, the qga will fail to start.I think qga should create the missing paths. + +I found this bug exits in several Linux distributions including Ubuntu 14, Cent-OS 6 and 7 when the original and the latest master qga applies. I have a patch which can fix it. Should I patch it to the QEMU master branch? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1701973 b/results/classifier/deepseek-2-tmp/output/files/1701973 new file mode 100644 index 000000000..f9878b948 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1701973 @@ -0,0 +1,18 @@ + +pread does not work right under qemu-sh4 + +The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread + +Expected output: +ret=1 errno=0 + +Actual output: +ret=0 errno=2 +test-pread.c:44: assertion 'ret == 1' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1709 b/results/classifier/deepseek-2-tmp/output/files/1709 new file mode 100644 index 000000000..cad0f853a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1709 @@ -0,0 +1,37 @@ + +Qemu commit 7efd65423a cannot be built: Couldn't find file "symbols/ar" in include paths +Description of problem: +Hello. + +I try to build qemu based on commit 7efd65423a but it breaks in step 9035/10108, complaining about a missing "symbols/ar". + +The last time I get a full build was with commit fdd0df5340. + +Configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` + +Here is the error log I got: + +``` +Running postconf script '/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/symlink-install-tree.py' +[9035/10108] Generating pc-bios/keymaps/ar with a custom command +FAILED: pc-bios/keymaps/ar +/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar +xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths +xkbcommon: ERROR: 1 include paths searched: +xkbcommon: ERROR: /usr/share/X11/xkb +xkbcommon: ERROR: 3 include paths could not be added: +xkbcommon: ERROR: /home/fred/.config/xkb +xkbcommon: ERROR: /home/fred/.xkb +xkbcommon: ERROR: /etc/xkb +xkbcommon: ERROR: Abandoning symbols file "(unnamed)" +xkbcommon: ERROR: Failed to compile xkb_symbols +xkbcommon: ERROR: Failed to compile keymap +[9040/10108] Generating pc-bios/edk2-x...d (wrapped by meson to capture output) +ninja: build stopped: subcommand failed. +``` + +I'll try to do a bisect as soon as possible to see which commit break all. +Steps to reproduce: +1. Just grab commit 7efd65423a +2. Apply these configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` +3. launch make and wait diff --git a/results/classifier/deepseek-2-tmp/output/files/1714750 b/results/classifier/deepseek-2-tmp/output/files/1714750 new file mode 100644 index 000000000..036f9894e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1714750 @@ -0,0 +1,4 @@ + +2.10.0 cannot be installed on case-insensitive file system + +The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1716028 b/results/classifier/deepseek-2-tmp/output/files/1716028 new file mode 100644 index 000000000..56edabde3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1716028 @@ -0,0 +1,66 @@ + +qemu 2.10 locks images with no feature flag + +1) % lsb_release -rd +Description: Ubuntu Artful Aardvark (development branch) +Release: 17.10 + +2) % apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.10~rc3+dfsg-0ubuntu1 + Candidate: 1:2.10+dfsg-0ubuntu1 + Version table: + 1:2.10+dfsg-0ubuntu1 500 + 500 http://archive.ubuntu.com//ubuntu devel/main amd64 Packages + *** 1:2.10~rc3+dfsg-0ubuntu1 100 + 100 /var/lib/dpkg/status + +3) qemu locks image files with no way to discover this feature nor how to disable it + +4) qemu provides a way to query if it supports image locking, and what the default value is, and how to disable the locking via cli + +qemu 2.10 now will lock image files and warn if an image is currently locked. This prevent qemu from running (and possibly corrupting said image). + +However, qemu does not provide any way to determine if a qemu binary actually has this capability. Normally behavior changing features are exposed via some change to the qemu help menu or QMP/QAPI output of capabilities. + +I believe this slipped through since libvirt already does image locking, but direct cli users will be caught by this change. + +In particular, we have a use-case where we simulate multipath disks by creating to disks which point to the same file which now breaks without adding the 'file.locking=off' to the -drive parameters; which is also completely undocumented and unexposed. + +Some parts of the cli like -device allow querying of settable options (qemu-system-x86 -device scsi_hd,?) but nothing equivalent exists for -drive parameters. + +ProblemType: Bug +DistroRelease: Ubuntu 17.10 +Package: qemu-system-x86 1:2.10~rc3+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5 +Uname: Linux 4.12.0-11-generic x86_64 +NonfreeKernelModules: zfs zunicode zavl zcommon znvpair +ApportVersion: 2.20.6-0ubuntu7 +Architecture: amd64 +Date: Fri Sep 8 12:56:53 2017 +JournalErrors: + Hint: You are currently not seeing messages from other users and the system. + Users in groups 'adm', 'systemd-journal' can see all messages. + Pass -q to turn off this notice. + -- Logs begin at Mon 2017-01-30 11:56:02 CST, end at Fri 2017-09-08 12:56:46 CDT. -- + -- No entries -- +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +MachineType: HP ProLiant DL360 Gen9 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.12.0-11-generic root=UUID=45354276-e0c0-4bf6-9083-f130b89411cc ro --- console=ttyS1,115200 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 03/05/2015 +dmi.bios.vendor: HP +dmi.bios.version: P89 +dmi.chassis.type: 23 +dmi.chassis.vendor: HP +dmi.modalias: dmi:bvnHP:bvrP89:bd03/05/2015:svnHP:pnProLiantDL360Gen9:pvr:cvnHP:ct23:cvr: +dmi.product.family: ProLiant +dmi.product.name: ProLiant DL360 Gen9 +dmi.sys.vendor: HP \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1719870 b/results/classifier/deepseek-2-tmp/output/files/1719870 new file mode 100644 index 000000000..a4e4bf3fa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1719870 @@ -0,0 +1,10 @@ + +Converting 100G VHDX fixed image to QCOW2 fails + +Virtual Size recognized incorrectly for VHDX fixed disk and conversion fails with error Expression: !qiov || bytes == qiov->size + + + +PS > & 'C:\Program Files\qemu\qemu-img.exe' --version +qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/173 b/results/classifier/deepseek-2-tmp/output/files/173 new file mode 100644 index 000000000..33ad0b850 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/173 @@ -0,0 +1,2 @@ + +unable to read symlinks when mounting 9p filesystem with security_model=mapped diff --git a/results/classifier/deepseek-2-tmp/output/files/1738840 b/results/classifier/deepseek-2-tmp/output/files/1738840 new file mode 100644 index 000000000..2140c91ab --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1738840 @@ -0,0 +1,86 @@ + +qemu-img convert qcow2 to raw fails on OS X + +I try to convert a image from qcow2 to raw and the result is a not bootable image. +I dont know if it is a bug in qemu-img convert or with the image it self. + +See this error report for better readability: +https://github.com/coreos/bugs/issues/1121#issuecomment-351968518 + +As a reply here they use 2.9.0 version of + + +$ qemu-img -V +qemu-img version 2.11.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ uname -v +Darwin Kernel Version 17.2.0 + +$ mount ./ +/dev/disk1s1 on / (apfs, local, journaled) + +$ wget https://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2 + +$ date +Fri Dec 14 17:15:57 CET 2017 + +$ bunzip2 coreos_production_openstack_image.img.bz2 + + +$ cp -a coreos_production_openstack_image.img.org coreos_production_openstack_image.img + +$ shasum coreos_production_openstack_image.img.org +ae2119c6f0390dc36f247f7016923ea85de5d8e6 coreos_production_openstack_image.img.org + +$ qemu-img convert -f qcow2 -O raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.img -boot c +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +GRUB loading.... +Welcome to GRUB! +.... + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.bin -boot c + +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +Boot failed: not a bootable disk +.... + + +$ head -c 8192 coreos_production_openstack_image.bin | hexdump -C +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00002000 + +$ qemu-img info coreos_production_openstack_image.bin +image: coreos_production_openstack_image.bin +file format: raw +virtual size: 8.5G (9116319744 bytes) +disk size: 217M + +$ qemu-img info coreos_production_openstack_image.img +image: coreos_production_openstack_image.img +file format: qcow2 +virtual size: 8.5G (9116319744 bytes) +disk size: 785M +cluster_size: 65536 +Format specific information: + compat: 0.10 + refcount bits: 16 + +The same version works on Ubuntu so it looks like its only the Mac version or the new APFS filesystem. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1739304 b/results/classifier/deepseek-2-tmp/output/files/1739304 new file mode 100644 index 000000000..aa9c27b2a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1739304 @@ -0,0 +1,10 @@ + +Passing a directory to (eg.) -cdrom results in misleading error message + +For example: + + qemu-system-x86_64 -cdrom /path/to/directory + +Results in: + + Could not read image for determining its format: File too large \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1748 b/results/classifier/deepseek-2-tmp/output/files/1748 new file mode 100644 index 000000000..030867d26 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1748 @@ -0,0 +1,57 @@ + +qcow2: disk size exceeds virtual size +Description of problem: +Disk size of qcow2 image file exceeds its virtual size after repeatedly writing, and deleting data in qemu vm. +Steps to reproduce: +1. qemu-img create -f qcow2 tmp.qcow2 32M +2. attach tmp.qcow2 as a device to qemu vm +3. mount the device in qemu vm, and repeatedly writing, and deleting data +Additional information: +xml for attaching tmp.qcow2 +```xml + <disk device="disk" type="file"> + <target bus="virtio" dev="vdb"/> + <source file="/path/to/tmp.qcow2"/> + <driver type="qcow2" name="qemu" cache="none" discard="unmap"/> + </disk> +``` +in fact, set discard="unmap" or not seems has `little impact` on the final result. +reproducible shell script. +```sh +#! /bin/sh + +for i in {1..1000}; do + for j in {1..27}; do + dd if=/dev/zero of=/mnt/test-$j bs=1M count=1 & + done + sync + sleep 10 + rm -f /mnt/test-* + fstrim /mnt +done +``` +MOUNT the device and run this script, problem happens about 30 minutes. + +final result looks like: +```sh +# qemu-img info tmp.qcow2 --force +image: tmp.qcow2 +file format: qcow2 +virtual size: 32 MiB (33554432 bytes) +disk size: 33 MiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false +Child node '/file': + filename: tmp.qcow2 + protocol type: file + file length: 32.3 MiB (33882112 bytes) + disk size: 33 MiB + Format specific information: + extent size hint: 1048576 +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/1759337 b/results/classifier/deepseek-2-tmp/output/files/1759337 new file mode 100644 index 000000000..2ab3d3eb4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1759337 @@ -0,0 +1,17 @@ + +'Failed to get "write" lock' error when trying to run a VM with disk image file on an SMB share + +This has been reported and discussed downstream: + +https://bugzilla.redhat.com/show_bug.cgi?id=1484130 + +but doesn't seem to be getting a lot of traction there. + +Basically, with qemu since at least 2.10, you cannot use a disk image on an SMB share that's mounted with protocol version 3 (I think possibly 2 or higher). This is made much more serious because kernel 4.13 upstream made version 3 the *default* for SMB mounts, because version 1 is insecure and should not be used. + +So basically, anyone with a recent qemu and kernel cannot use disk images stored on an SMB share. This is a major inconvenience for me because, well, an SMB share is exactly where I store my VM disk images, usually: I have a big NAS drive where I keep them all, only now I can't because of this bug, and I'm manually swapping them in and out of the very limited space I have on my system drive (SSD). + +The error you get is: + +qemu-system-x86_64: -drive file=/share/data/isos/vms/desktop_test_1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Failed to get "write" lock +Is another process using the image? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1774853 b/results/classifier/deepseek-2-tmp/output/files/1774853 new file mode 100644 index 000000000..5781153a4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1774853 @@ -0,0 +1,8 @@ + +claims temp file is used by another process + +QEMU emulator version 2.12.50 (v2.12.0-12378-g99a34dc4d2-dirty) + +"c:\Program Files\qemu\qemu-system-x86_64.exe" -net none -parallel none -bios OVMF.fd -L . -hda fat:rw:image +vvfat image chs 1024,16,63 +c:\Program Files\qemu\qemu-system-x86_64.exe: -hda fat:rw:image: Could not open 'C:\Users\tsiros\AppData\Local\Temp\qem5B92.tmp': The process cannot access the file because it is being used by another process. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1776920 b/results/classifier/deepseek-2-tmp/output/files/1776920 new file mode 100644 index 000000000..d9c01ff18 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1776920 @@ -0,0 +1,4 @@ + +qemu-img convert on Mac OSX creates corrupt images + +An image created by qemu-img create, then modified by another program is converted to bad/corrupt image when using convert sub command on Mac OSX. The same convert works on Linux. The version of qemu-img is 2.12. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1784919 b/results/classifier/deepseek-2-tmp/output/files/1784919 new file mode 100644 index 000000000..c5f91a165 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1784919 @@ -0,0 +1,15 @@ + +native libgfapi glusterfs support for virtio 9p filesystem passthrough + +I can add block devices on glusterfs natively to my virtual machines since qemu 1.3 +I would like to see the same feature for virtio 9p filesystems added on my VM. + +Accessing a filesystem mounted on the Metal is my favorite solution for storage that is to be shared between more than one VM. But because my VMs are not running as root, they are not able to passthrough userids and gids to gluster-fuse. uid mapping is also not possible because no xattr support. + +So all I can do is either setting up seperate NFS Servers to bring the Filesystem in via Network, or to start qemu as root or to add fuse_xattr on top of glusterfs_fuse. I do expect however that the fastest and most relieable solution is to make something like this possible: + +-fsdev local,id=test_dev,path=gluster://this.node/test_mount,security_model=passthrough -device virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount + +regards + + Hans \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1785902 b/results/classifier/deepseek-2-tmp/output/files/1785902 new file mode 100644 index 000000000..b38756fff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1785902 @@ -0,0 +1,8 @@ + +local/9pfs: Too many levels of symbolic links + +Version: 2.9.1 + +The primary symptom is resolving symlink fails w/ error "too many levels of symbolic links". + +My analysis showed that local_readlink() uses local_open_nofollow() to open the file and then tries to read it. local_open_nofollow() then tries to open the file w/ O_NOFOLLOW, which obviously fails if the requested file is a symlink. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1790617 b/results/classifier/deepseek-2-tmp/output/files/1790617 new file mode 100644 index 000000000..06d60ca76 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1790617 @@ -0,0 +1,44 @@ + +Version of disk image format not exhibited using the 'qemu-img info' command + +OS: Fedora (64 bits) – Linux –. Last available component: qemu-img.x86_64 2:2.11.2-2.fc28 + +Description: version of disk image format not exhibited using the 'qemu-img info' command. + +Command 'qemu-img info qcow2 [image-file-name.img]' produces this stderr message: +qemu-img: Expecting one image file name +Try 'qemu-img --help' for more information + +How to reproduce in terminal: +1. Create a VM using Raw disk image format +2. Run either commands 'qemu-img info -f raw [image-file-name.img]', 'qemu-img info [image-file-name.img]'. +3. Run either commands 'qemu-img info -f qcow2 [image-file-name.qcow2]', 'qemu-img info [image-file-name.qcow2]'. + +Actual result: output model resulting from step .2 exhibits following informations: +image: image-file-name.img +file format: raw +virtual size: _G (_ bytes) +disk size: _G + +Output model resulting from step .3 exhibits following informations: +image: image-file-name.qcow2 +file format: qcow2 +virtual size: _G (_ bytes) +disk size: _G +cluster_size: _ +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 snapshot1 _G 2018-07-31 18:27:49 00:03:45.890 + +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: false + +Actual result: raw and qcow2 formats respective versions –which are likely to be mentioned as "version"– to be exhibited. + +Additional information: in documentation lastly updated 2018-08-23 at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/index it is stated in chapters: + +14.10 – 'images in raw format can be resized in both directions, whereas qcow2 version 2 or qcow2 version 3 images can be grown'; +14.12 – 'the qcow2 version supplied with Red Hat Enterprise Linux 7 is 1.1', 'To know which version you are using, run qemu-img info qcow2 [imagefilename.img] command.'. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1791 b/results/classifier/deepseek-2-tmp/output/files/1791 new file mode 100644 index 000000000..b6a4a8ea6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1791 @@ -0,0 +1,41 @@ + +qemu 8.1.0 rc tarballs are broken, missing subproject content +Description of problem: +The released tarballs for 8.1.0 rc releases (both rc0 adn rc1) are missing the +subproject content. Only the submodule content appears present +Steps to reproduce: +1. `wget http://download.qemu.org/qemu-8.1.0-rc1.tar.xz` +2. `tar Jxvf qemu-8.1.0-rc1.tar.xz` +3. `cd qemu-8.1.0-rc1` +4. `./configure --target-list=x86_64-softmmu --disable-download` + +``` +Using './build' as the directory for build output + +ERROR: missing subprojects + +This is not a GIT checkout but subproject content appears to +be missing. Do not use 'git archive' or GitHub download links +to acquire QEMU source archives. Non-GIT builds are only +supported with source archives linked from: + + https://www.qemu.org/download/#source + +Developers working with GIT can use scripts/archive-source.sh +if they need to create valid source archives. + +``` + +The missing subprojects are + +``` + berkeley-softfloat-3 + berkeley-testfloat-3 + dtc + keycodemapdb + libvfio-user +``` + +If I use 'make-release . 8.1.0-rc1' to create a tarball from git, it has all the expected content. + +IOW, either the release tarballs are not being created using 'make-release', or there's something broken with 'make-release' in some scenarios diff --git a/results/classifier/deepseek-2-tmp/output/files/1793904 b/results/classifier/deepseek-2-tmp/output/files/1793904 new file mode 100644 index 000000000..eb70ef4c5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1793904 @@ -0,0 +1,59 @@ + +files are randomly overwritten by Zero Bytes + +Hello together, + +I am currently tracking down a "Hard to reproduce" bug on my systems that I first discovered during gitlab installation: + + +Here is the Text from the Gitlab Bug https://gitlab.com/gitlab-org/gitlab-ce/issues/51023 +---------------------------------------------------------------------------------------------- + +Steps to reproduce + +I still do not have all the steps together to reproduce, so far it is: +apt install gitlab-ce and +gitlab-rake backup:recovery +Then it works for some time before it fails. + +What is the current bug behavior? + +I have a 12 hour old Installation of gitlab ce 11.2.3-ce.0 for debian stretch on a fresh debian stretch system together with our imported data. However it turns out that some gitlab related files contain Zero bytes instead of actual data. + +root@gitlab:~# xxd -l 16 /opt/gitlab/bin/gitlab-ctl +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +This behaviour is somewhat strange because it was working for a few minutes/hours. I did write a shell script to find out which files are affected of this memory loss. It turns out that only files located under /opt/gitlab are affected, if I rule out files like /var/log/faillog and some postgresql table files. + +What I find even stranger is that it does not seem to affect Logfiles/databases/git_repositorys but application files, like .rb scripts. and not all of them. No non gitlab package is affected. + +What is the expected correct behavior? +Binarys and .rb files should stay as they are. + +Possible fixes + +I am still investigating, I hope that it is not an infrastructure problem (libvirt/qemu/glusterfs) it can still be one but the point that files of /opt/gitlab are affected and not any logfile and that we to not have similar problems with any other system leads me to the application for now. +If I would have used docker the same problem might have caused a reboot of the container. +But for the Debian package it is a bit of work to recover. That is all a workaround, however. +--------------------------------------------------------------------------------------------- + +I do have found 2 more systems having the same problem with different software: + +root@erp:~# xxd -l 16 /usr/share/perl/5.26.2/constant.pm +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +The Filesize itself is, compared with another machine 00001660 Bytes for both the corrupted and the intact file. It looks to me from the outside that if some data in the qcow2 file is written too many bytes get written so it sometimes overwites data of existing files located right after the position in memory where the write goes to. + +I would like to rule out Linux+Ext4 filesystems because I find it highly unlikely that such an error keeps undiscovered in that part of the environment for long. I think the same might go for qemu. + +Which leaves qemu, gemu+gluster:// mount, qcow2 volumes, glusterfs, network. So I am now going to check if I can find any system which gets its volumes via fusermount instead of gluster:// path if the error is gone there. This may take a while. + + +----- some software versions--------------- + +QEMU emulator version 2.12.0 (Debian 1:2.12+dfsg-3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +libvirt-daemon-driver-storage-gluster/testing,unstable,now 4.6.0-2 amd64 [installed] + +ii glusterfs-client 4.1.3-1 amd64 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1794086 b/results/classifier/deepseek-2-tmp/output/files/1794086 new file mode 100644 index 000000000..783325406 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1794086 @@ -0,0 +1,48 @@ + +readlink(2) returns incorrect size for /proc/self/exe + +readlink(2) seems to ignore the size of supplied buffer for the resolved name and always returns the actual size of the resolved name instead. + +Steps to reproduce: + +```bash +echo '#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, const char** argv) +{ + if(argc < 2) exit(1); + char buf[1]; + printf("%d\n", readlink(argv[1], buf, sizeof(buf))); +}' >test.c + +# I used GCC mipsel cross-compiler to reproduce this bug +mipsel-linux-gnu-gcc-5.5 test.c -o a.out + +echo "PWD: `pwd`" +qemu-mipsel ./a.out /proc/self/exe +``` + +Expected output (observed when running a.out natively on Linux 4.17 amd64): +``` +PWD: /tmp/test +1 +``` + +Output observed when running with qemu-mipsel 2.1.2: +``` +PWD: /tmp/test +15 +``` + +According to POSIX description of readlink [1], the function shall return the number of bytes written to the supplied buffer, which obviously cannot exceed size of the buffer. + +Note that the bug is only reproduced with links within /proc filesystem; links to the regular files within /home are resolved normally. + +The bug is present in qemu-mipsel 2.1.2: + +# qemu-mipsel -version +qemu-mipsel version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) 2003-2008 Fabrice Bellard + +[1]: http://pubs.opengroup.org/onlinepubs/009695399/functions/readlink.html \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1796 b/results/classifier/deepseek-2-tmp/output/files/1796 new file mode 100644 index 000000000..9e4e6e1c6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1796 @@ -0,0 +1,17 @@ + +qemu-img does not accept backing image file path, only file name +Description of problem: +In `qemu-img create ... -b <backing_image> ... <snapshot_image>`, <backing_image> cannot be a file path, but must be a file name. <backing_image> and <snapshot_image> are forced to be in the same directory for the command to work. +Steps to reproduce: +``` +$ mkdir test +$ qemu-img create -f qcow2 test/a.img 1G +... +$ qemu-img create -f qcow2 -b test/a.img -F qcow2 test/a.img.snap +qemu-img: test/a.img.snap: Could not open 'test/test/a.img': No such file or directory +Could not open backing image. +$ qemu-img create -f qcow2 -b a.img -F qcow2 test/a.img.snap +... +$ ls test +a.img a.img.snap +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/1805913 b/results/classifier/deepseek-2-tmp/output/files/1805913 new file mode 100644 index 000000000..01773a74c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1805913 @@ -0,0 +1,22 @@ + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host + +This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: + +# Setup docker for user-static binfmt +docker run --rm --privileged multiarch/qemu-user-static:register --reset +# Compile the code and run (readdir for / is fine, so create a new directory /test). +docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' +dir=0xff5b4150 +readdir(dir)=(nil) +errno=75: Value too large for defined data type + +Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. + +The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 + +By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. + +The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. + +The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1806196 b/results/classifier/deepseek-2-tmp/output/files/1806196 new file mode 100644 index 000000000..100f17955 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1806196 @@ -0,0 +1,10 @@ + +qed leaked clusters + +There are example of two QED files which AFAIK does not have errors both. But qemu-img check say that one of them has 1 leaked cluster. + +I wrote my own tool and it does not find any error. Both files attached, as well as debug output from my program. + +Both files are about 4G in size after unpacking. Unpack with tar -S to handle sparse files. + +And also, I know, that QED is deprecated, but anyway, seems qemu-img has bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1807073 b/results/classifier/deepseek-2-tmp/output/files/1807073 new file mode 100644 index 000000000..8206a0986 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1807073 @@ -0,0 +1,24 @@ + +qemu-guest-agent stop work when fsfreeze + +Create a live snapshot, we should first to fsfreeze the file system. We do have only one disk mounted to /: +Filesystem Size Used Avail Use% Mounted on +udev 48G 0 48G 0% /dev +tmpfs 9.5G 8.7M 9.5G 1% /run +/dev/vda1 485G 1.5G 484G 1% / +tmpfs 48G 0 48G 0% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 48G 0 48G 0% /sys/fs/cgroup +tmpfs 9.5G 0 9.5G 0% /run/user/0 + +snapshot action is OK, when we restore the snapshot, the file system became read-only, and syslog seems stop writing until we fsck /dev/vda1 and mount -o rw,remount /: +Dec 5 00:39:16 systemd[1]: Started Session 180 of user root. +Dec 5 00:45:05 qemu-ga: info: guest-fsfreeze called +Dec 5 07:00:45 kernel: [ 114.623823] EXT4-fs (vda1): re-mounted. Opts: (null) + +So after snapshoting, wo do fsthaw the file system, maybe the qga dose not respond or stop work, this action dose not execute successfully and there is no log to show the status of qemu-guest-agent. + +Version: +libvirt 1.2.17 +qemu 2.3.0 +qemu-guest-agent 2.5 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1808928 b/results/classifier/deepseek-2-tmp/output/files/1808928 new file mode 100644 index 000000000..0b690c56f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1808928 @@ -0,0 +1,17 @@ + +Bitmap Extra data is not supported + +i am using dirty bitmaps and drive-backup. It works as aspected. + +Lately, i encounter a disastrous error. There is not any information about that situation. I cannot reach/open/attach/info or anything with a qcow2 file. + +virsh version +Compiled against library: libvirt 4.10.0 +Using library: libvirt 4.10.0 +Using API: QEMU 4.10.0 +Running hypervisor: QEMU 2.12.0 + +"qemu-img: Could not open '/var/lib/libvirt/images/test.qcow2': Bitmap extra data is not supported" + +what is that mean? what should i do? +i cannot remove bitmap. i cannot open image or query. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1809304 b/results/classifier/deepseek-2-tmp/output/files/1809304 new file mode 100644 index 000000000..dbcc6de98 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1809304 @@ -0,0 +1,18 @@ + +qemu-img convert is freezing for some DMG files. + +Recently, I created a file using hdiutil from MacOS (using Zlib compression): + +$ hdiutil create -volname MyVolName -srcfolder /path/to/my/vol/ -ov -format UDZO myvolname.dmg + +But, when I try to convert this volume using qemu-img convert, this command is freezing. + +I'm using the upstream version to test it. + +It is freezing inside the binary search method to retrieve the chunk. + +But, I still don't know why. + +I'm attaching the file as an example. + +It can be mounted using MacOS or other Linux apps like hfsleuth and darling-dmg. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1810603 b/results/classifier/deepseek-2-tmp/output/files/1810603 new file mode 100644 index 000000000..216840bd7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1810603 @@ -0,0 +1,54 @@ + +QEMU QCow Images grow dramatically + +I've recently migrated our VM infrastructure (~200 guest on 15 hosts) from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU QCow v3) from which we spawn multiple instances (linked clones). All guests are being revert once per hour for security reasons. + +About 2 weeks after we successfully migrated to Qemu, we noticed that almost all disks went full across all 15 hosts. Our investigation showed that the initial qcow disk images blow up from a few gigabytes to 100GB and more. This should not happen, as we revert all VMs back to the initial snapshot once per hour and hence all changes that have been made to disks must be reverted too. + +We did an addition test with 24 hour time frame with which we could reproduce this bug as documented below. + +Initial disk image size (created on Jan 04): +-rw-r--r-- 1 root root 7.1G Jan 4 15:59 W10-TS01-0.img +-rw-r--r-- 1 root root 7.3G Jan 4 15:59 W10-TS02-0.img +-rw-r--r-- 1 root root 7.4G Jan 4 15:59 W10-TS03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:02 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 8.6G Jan 4 16:05 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:05 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:12 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:12 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:16 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:16 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:19 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 7.5G Jan 4 16:21 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +Disk image size after 24 hours (printed on Jan 05): +-rw-r--r-- 1 root root 13G Jan 5 15:07 W10-TS01-0.img +-rw-r--r-- 1 root root 8.9G Jan 5 14:20 W10-TS02-0.img +-rw-r--r-- 1 root root 9.0G Jan 5 15:07 W10-TS03-0.img +-rw-r--r-- 1 root root 10G Jan 5 15:08 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 19G Jan 5 15:07 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 14G Jan 5 15:08 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 9.7G Jan 5 15:07 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 35G Jan 5 15:08 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 9.2G Jan 5 15:07 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 41G Jan 5 15:08 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +You can reproduce this bug as follow: +1) create an initial disk image +2) create a linked clone +3) create a snapshot of the linked clone +4) revert the snapshot every X minutes / hours + +Due the described behavior / bug, our VM farm is completely down at the moment (as we run out of disk space on all host systems). A quick fix for this bug would be much appreciated. + +Host OS: Ubuntu 18.04.01 LTS +Kernel: 4.15.0-43-generic +Qemu: 3.1.0 +libvirt: 4.10.0 +Guest OS: Windows 10 64bit \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1811711 b/results/classifier/deepseek-2-tmp/output/files/1811711 new file mode 100644 index 000000000..0434249b5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1811711 @@ -0,0 +1,72 @@ + +qemu-img can not convert virtualbox virtual disk formats qcow + +Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command. + +Info +---- +$ sw_vers +ProductName: Mac OS X +ProductVersion: 10.13.6 +BuildVersion: 17G4015 + +VirtualBox +---------- +$ VBoxManage --version +6.0.0r127566 + +$ qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +$ qemu-img --version +qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Steps to reproduce +------------------ + +> Prereq VirtualBox needs to be installed to run the `VBoxManage` command + +$ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5 +0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% +Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb + +$ file vbox-vdisk-exp.qcow +vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes + +$ qemu-img info vbox-vdisk-exp.qcow +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +# Convert vbox virtualdisk to qcow2 format using `qemu-img` +$ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2 + +$ file vbox-vdisk-exp-convert.qcow2 +vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes + +# Print info about qemu-img converted image from vbox created qcow image +$ qemu-img info vbox-vdisk-exp-convert.qcow2 mutts-6 | 0 < 10:53:00 +image: vbox-vdisk-exp-convert.qcow2 +file format: qcow2 +virtual size: 5.0M (5242880 bytes) +disk size: 196K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# Print info about vbox created qcow image +qemu-img info vbox-vdisk-exp.qcow mutts-6 | 0 < 10:53:19 +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1812451 b/results/classifier/deepseek-2-tmp/output/files/1812451 new file mode 100644 index 000000000..275cf7031 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1812451 @@ -0,0 +1,15 @@ + +In windows host, tftp arbitrary file read vulnerability + +https://github.com/qemu/qemu/blob/master/slirp/tftp.c#L343 + + if (!strncmp(req_fname, "../", 3) || + req_fname[strlen(req_fname) - 1] == '/' || + strstr(req_fname, "/../")) { + tftp_send_error(spt, 2, "Access violation", tp); + return; + } + +There are file path check for not allowing escape tftp directory. +But, in windows, file path is separated by "\" backslash. +So, guest can read arbitrary file in Windows host. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1813406 b/results/classifier/deepseek-2-tmp/output/files/1813406 new file mode 100644 index 000000000..9d96d7309 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1813406 @@ -0,0 +1,8 @@ + +qemu-img convert malfunction on macOS + +On macOS 10.13.6, `qemu-img convert` failed to convert a qcow2 into a new qcow2 (for the purpose of shrinking the image). + +A 50GB (3.7GB allocated) qcow2 image was used as source. The qemu-img convert output was a 3.4MB file. + +qemu-img from HomeBrew were tested. Both 2.11.1 and 3.1.0_1 failed to convert a qcow2 image. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1817345 b/results/classifier/deepseek-2-tmp/output/files/1817345 new file mode 100644 index 000000000..ee5a11200 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1817345 @@ -0,0 +1,42 @@ + +configure script breaks when $source_path contains white spaces + +Hi, + +I noticed that the configure script breaks when the qemu source directory is in a path containing white spaces, in particular the list of targets is not correctly generated when calling "./configure --help". + +Steps to reproduce the problem: + +$ mkdir "dir with spaces" +$ cd dir\ with\ spaces/ +$ git clone https://git.qemu.org/git/qemu.git +$ cd qemu/ +$ ./configure --help | grep -A3 target-list + + +Actual result: + + --target-list=LIST set target list (default: build everything) + Available targets: dir with *-softmmu dir with + *-linux-user + + +Expected result: + + --target-list=LIST set target list (default: build everything) + Available targets: aarch64-softmmu alpha-softmmu + arm-softmmu cris-softmmu hppa-softmmu i386-softmmu + lm32-softmmu m68k-softmmu microblaze-softmmu + + +This happens because the $mak_wilds variable uses spaces to separate different paths, maybe newlines may be used, which are less likely to be in directory names. + +BTW "shellcheck" may help finding some other problems. + +Qemu version: + +$ git describe +v3.1.0-1960-ga05838cb2a + +Thanks, + Antonio \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1819182 b/results/classifier/deepseek-2-tmp/output/files/1819182 new file mode 100644 index 000000000..d09bb4d32 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1819182 @@ -0,0 +1,24 @@ + +info does not recognize file format of vpc with subformat=fixed + +After creating or converting an image to vpc with 'subformat=fixed' +'qemu-img info' incorrectly identifies the image as 'raw' format. + +$ qemu-img --version +qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ qemu-img create -f vpc -o subformat=fixed my.vpc 2G +Formatting 'my.vpc', fmt=vpc size=2147483648 subformat=fixed + +$ qemu-img info my.vpc +image: my.vpc +file format: raw +virtual size: 2.0G (2147992064 bytes) +disk size: 4.0K + +$ qemu-img info -f vpc my.vpc +image: my.vpc +file format: vpc +virtual size: 2.0G (2147991552 bytes) +disk size: 4.0K \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1819343 b/results/classifier/deepseek-2-tmp/output/files/1819343 new file mode 100644 index 000000000..8fb9efb9e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1819343 @@ -0,0 +1,8 @@ + +Qcow2 image stuck as locked after host crash + +After a host crash, the qcow2 image of the VM, stored on a remote NFS share, has become inaccessible. Libvirt/QEMU reports that 'failed to get "write" lock\nIs another process using the image [/path/nfs/image.qcow2]?'. No process is accessing the image from either host or the network share side. There is no obvious way in qemu-img to force unlocking the file or repair the image (attempting a qemu-img check with -r all results in qemu-img complaining about the lock and being unable to do force-share=on on anything but readonly images). + +I'm currently attempting to fix this by converting the image via 'qemu-img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2', though this will likely take some time. + +Using QEMU 3.1.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1826200 b/results/classifier/deepseek-2-tmp/output/files/1826200 new file mode 100644 index 000000000..3473b664c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1826200 @@ -0,0 +1,20 @@ + +RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files + +The feature added in + + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd + +and exposed by libvirt as + + https://libvirt.org/formatdomain.html#elementsSysinfo + +allows the user to specify up to 255 strings in the unofmatted area of the Type 11 SMBIOS table, where each string may be of arbitrary length. This feature is useful for exposing arbitrary text to arbitrary guest components (in particular when strings are prefixed with "application identifiers"). + +Right now, strings can only be specified on the QEMU command line, which limits the amount of data that can be passed. Please enable users to pass data from regular files too. + +For example: + + $QEMU -smbios type=11,value=Hello,txtfile=file1.txt,txtfile=file2.txt + +where "file1.txt" and "file2.txt" could be text files containing ASCII application prefixes, followed by base64-encoded binary data. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1829242 b/results/classifier/deepseek-2-tmp/output/files/1829242 new file mode 100644 index 000000000..5bdbabb0e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1829242 @@ -0,0 +1,12 @@ + +qemu on windows host exits after savevm command + +I'm running qemu-system-i386.exe 3.1.0 with this command line: +"C:\Program Files\qemu\qemu-system-i386.exe" -L C:\user\qemu\pc-bios\ -name win7 -m 4G -uuid 564db62e-e031-b5cf-5f34-a75f8cefa98e -rtc base=localtime -accel hax -hdd C:\VirtualMachines\Dev\Win10x64_VS17\swap.qcow "C:\VirtualMachines\qemu\qemu_win7.qcow" +Host OS Windows 10 x64, guest OS Wondows 7 x86. + +Wait till the OS loads, go to compat_monitor0 tab and enter command: +savevm loaded_win +After a few seconds qemu exits, running it another time and entering command: +info snapshots +says "There is no snapshot available". I've tried rinning it with -accel tcg, with same results. I've tried less memory (1G), same results. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1831354 b/results/classifier/deepseek-2-tmp/output/files/1831354 new file mode 100644 index 000000000..7a2133a62 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1831354 @@ -0,0 +1,9 @@ + +unable to read symlinks when mounting 9p filesystem with security_model=mapped + +I am trying to use clang that is mounted from a 9p filesystem that has the options + -fsdev local,id=virtfs3,path=/clang,security_model=mapped-file -device virtio-9p-pci,fsdev=virtfs3,mount_tag=clang + +clang has symlinks to clang-9. eg /clang/clang/bin/clang is a symlink that points to clang-9 in the current directory. + +the clang filesystem is on a bind mount point on /clang/clang on the host and this is mapped to the same place on the guest. If I have the same virtfs mount point with the security_model=none I don't have this problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1835477 b/results/classifier/deepseek-2-tmp/output/files/1835477 new file mode 100644 index 000000000..6ceb8274d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1835477 @@ -0,0 +1,6 @@ + +Converting qcow2 to vmdk on MacOSX results in a non-bootable image + +When using qemu-img convert -O vmdk with version 3.1.0 or 4.0.0 on OSX (10.14.3) with a qcow2 image (https://cloud-images.ubuntu.com/bionic/20190703/bionic-server-cloudimg-amd64.img), the resulting image is not bootable. + +Running the same command on Ubuntu 18.04 results in a bootable image as expected \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1838703 b/results/classifier/deepseek-2-tmp/output/files/1838703 new file mode 100644 index 000000000..765eedacf --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1838703 @@ -0,0 +1,14 @@ + +Makefile BUG in edk2 firmware install 4.1.0-rc3 + +DESTDIR installs end up with wrong paths in JSON files installed to $prefix/share/qemu/firmware. For example, the file: + + 50-edk2-x86_64-secure.json + +ends up incorrectly with: + + "filename": "/build/qemu/pkg/qemu/usr/share/qemu/edk2-x86_64-secure-code.fd", + +instead of the correct: + + "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd", \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1839294 b/results/classifier/deepseek-2-tmp/output/files/1839294 new file mode 100644 index 000000000..30f46de94 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1839294 @@ -0,0 +1,16 @@ + +Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation + +This happens on Windows 10 with the latest installer for 64 bit Windows: qemu-w64-setup-20190807.exe + +On install it will create the files and go through all the typical functions of installing the software, at the very end step it will then delete all files the installer created. + +I looked for logs to see when was going on so I ran the installation in Sandboxie and was able to retain all the installed files but I couldn't find a log for the installer. + +Here is a screenshot of it deleting all the files at the end of the process. + +https://imgur.com/BWiTA38 + +If goes too fast for me to see what is written in the text console otherwise I would post more information but this is all I have. It does not give any error or any other information at completion. + +This error does not occur in the earlier release: qemu-w64-setup-20190731.exe \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1840648 b/results/classifier/deepseek-2-tmp/output/files/1840648 new file mode 100644 index 000000000..2ca6f0d2c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1840648 @@ -0,0 +1,14 @@ + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161: logical fault ? + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161:71: warning: Logical disjunction always evaluates to true: EXPR != '\\' || EXPR != '\0'. [incorrectLogicOperator] + +Source code is + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') || + (*(FileName + 2) != L'\0'))) { + +Maybe better code: + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') && + (*(FileName + 2) != L'\0'))) { \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1840865 b/results/classifier/deepseek-2-tmp/output/files/1840865 new file mode 100644 index 000000000..a52098620 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1840865 @@ -0,0 +1,36 @@ + +qemu crashes when doing iotest on virtio-9p filesystem + +Qemu crashes when doing avocado-vt test on virtio-9p filesystem. +This bug can be reproduced running https://github.com/autotest/tp-qemu/blob/master/qemu/tests/9p.py. +The crash stack goes like: + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 v9fs_mark_fids_unreclaim (pdu=pdu@entry=0xaaab00046868, path=path@entry=0xffff851e2fa8) + at hw/9pfs/9p.c:505 +#1 0x0000aaaae3585acc in v9fs_unlinkat (opaque=0xaaab00046868) at hw/9pfs/9p.c:2590 +#2 0x0000aaaae3811c10 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) + at util/coroutine-ucontext.c:116 +#3 0x0000ffffa13ddb20 in ?? () from /lib64/libc.so.6 +Backtrace stopped: not enough registers or memory available to unwind further + +A segment fault is triggered at hw/9pfs/9p.c line 505 + + for (fidp = s->fid_list; fidp; fidp = fidp->next) { + if (fidp->path.size != path->size) { # fidp is invalid + continue; + } + +(gdb) p path +$10 = (V9fsPath *) 0xffff851e2fa8 +(gdb) p *path +$11 = {size = 21, data = 0xaaaafed6f420 "./9p_test/p2a1/d0/f1"} +(gdb) p *fidp +Cannot access memory at address 0x101010101010101 +(gdb) p *pdu +$12 = {size = 19, tag = 54, id = 76 'L', cancelled = 0 '\000', complete = {entries = { + sqh_first = 0x0, sqh_last = 0xaaab00046870}}, s = 0xaaab000454b8, next = { + le_next = 0xaaab000467c0, le_prev = 0xaaab00046f88}, idx = 88} +(gdb) + +Address Sanitizer shows error and saying that there is a heap-use-after-free on *fidp*. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1850000 b/results/classifier/deepseek-2-tmp/output/files/1850000 new file mode 100644 index 000000000..f04995c93 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1850000 @@ -0,0 +1,81 @@ + +4.1.0 bogus QCOW2 corruption reported after compress + +Creating a compressed image then running `qemu-img check <..>.qcow2' on said image seems to report bogus corruption in some (but not all) cases: + +Step 1. + +# qemu-img info win7-base.qcow2 +image: win7-base.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 12.2 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: false + +# qemu-img check win7-base.qcow2 +No errors were found on the image. +327680/327680 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters +Image end offset: 21478375424 + +Step 2. + +# qemu-img convert -f qcow2 -O qcow2 -c win7-base.qcow2 test1-z.qcow2 + +Step 3. + +# qemu-img info test1-z.qcow2 +image: test1-z.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 5.78 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# qemu-img check test1-z.qcow2 +ERROR cluster 1191 refcount=1 reference=2 +ERROR cluster 1194 refcount=1 reference=4 +ERROR cluster 1195 refcount=1 reference=7 +ERROR cluster 1196 refcount=1 reference=7 +ERROR cluster 1197 refcount=1 reference=6 +ERROR cluster 1198 refcount=1 reference=4 +ERROR cluster 1199 refcount=1 reference=4 +ERROR cluster 1200 refcount=1 reference=5 +ERROR cluster 1201 refcount=1 reference=3 +<...> snip many errors +Leaked cluster 94847 refcount=3 reference=0 +Leaked cluster 94848 refcount=3 reference=0 +Leaked cluster 94849 refcount=11 reference=0 +Leaked cluster 94850 refcount=14 reference=0 + +20503 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +20503 leaked clusters were found on the image. +This means waste of disk space, but no harm to data. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + + +The resultant image seems to work fine in a VM when used as a backing file. + +Interestingly, if I substitute a qemu-img binary from qemu-4.0 then no errors are reported. + +# /tmp/qemu-img check test1-z.qcow2 +No errors were found on the image. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + +Is the image corrupted or not? I'm guessing not. + +Just in case it matters, this is ext4 fs on rotational disk. Latest Arch Linux but self compiled 4.1.0 with recent QCOW2 corruption fixes added. + +I haven't tried latest trunk but might do so if time permits. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1854910 b/results/classifier/deepseek-2-tmp/output/files/1854910 new file mode 100644 index 000000000..ee50e39c2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1854910 @@ -0,0 +1,4 @@ + +Support VHDX differencing images (ie images with backing) + +The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1868221 b/results/classifier/deepseek-2-tmp/output/files/1868221 new file mode 100644 index 000000000..f09eee72f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1868221 @@ -0,0 +1,8 @@ + +/usr/share/applications/qemu.desktop should have an "Exec=" key. + +According to the www.freedesktop.org .desktop-file specification, all "Application" desktop files should have an "Exec=" key. The one in qemu doesn't. + +This can be easily verified by running kbuildsycoca4 if KDE4 is present, but the issue is not DE-dependent. + +Which binary exactly should be assigned as the default one, I don't know. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1869241 b/results/classifier/deepseek-2-tmp/output/files/1869241 new file mode 100644 index 000000000..effdd8704 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1869241 @@ -0,0 +1,20 @@ + +svn checkout fails with E000075 "Value too large for defined data type" + +I try to autobuild for ARM7 with qemu-arm-static. Part of this is downloading source via SVN. + +Whenever I try to download a SVN repository I get the following output: + + svn: E000075: Can't read directory '...': Value too large for defined data type + +qemu-arm-static version is 4.2.0 + +I've also tried older versions without change. + +Platform I try to emulate is armv7h (Arch Linux ARM for Raspberry Pi 2) + +Host system is AMD64 + +This can be reproduced 100% of the time. Here I have the issue happening on Travis CI: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/304839747#L7228 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1870039 b/results/classifier/deepseek-2-tmp/output/files/1870039 new file mode 100644 index 000000000..596702ce4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1870039 @@ -0,0 +1,34 @@ + +windows qemu-img fails to convert vhdx, assertion failure + +When attempting to convert Microsoft's 10X emulator image (19563) vhdx [1], qemu-img terminates abruptly with an assertion failure. (Newer versions of the vhdx exhibit the same issue.) + +Tested with qemu-img.exe --version +qemu-img version 4.2.50 (v4.2.0-676-g3a63b24a1b-dirty) + +Possibly related: 1719870 + +Partial Powershell cmdlet output: + +PS> Get-Vhd flash.vhdx + +VhdFormat : VHDX +VhdType : Dynamic +FileSize : 8365539328 +Size : 137438953472 +MinimumSize : 137438953472 +LogicalSectorSize : 4096 +PhysicalSectorSize : 4096 +BlockSize : 1048576 +ParentPath : +DiskIdentifier : 7BE7C459-AE5D-451A-9368-05875120F702 +FragmentationPercentage : 11 +Alignment : 1 +Attached : False +DiskNumber : +IsPMEMCompatible : False +AddressAbstractionType : None +Number : + + +[1] https://1drv.ms/u/s!AnjdAnZZcu-GpNFK_-tcNAq_4Aug8w?e=5JB6s0 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1871 b/results/classifier/deepseek-2-tmp/output/files/1871 new file mode 100644 index 000000000..35cad6154 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1871 @@ -0,0 +1,2 @@ + +Browse qcow2 image contents and add/remove files diff --git a/results/classifier/deepseek-2-tmp/output/files/1877384 b/results/classifier/deepseek-2-tmp/output/files/1877384 new file mode 100644 index 000000000..89f187ff5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1877384 @@ -0,0 +1,26 @@ + +9pfs file create with mapped-xattr can fail on overlayfs + +QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" + + +I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +The 9p fsdev is configured with security_model=mapped-xattr +When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. + +The relevant strace excerpt is: + +28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +28791 close(20) = 0 +28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) + +My hypothesis for what's going wrong is since the Docker container's overlayfs copies-up on writes, when it opens the file it's created a new version of the `src` directory containing a `client.log`, but this new src directory isn't accessible by file descriptor 20 and the lsetxattr call is instead attempting to set attributes on the path in the old `src` directory. + +Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and change `local_open2` to instead of calling `local_set_xattrat` to set the xattrs by directory file descriptor and file name, to have a version of local_set_xattrat` which uses `fsetxattr` to set the virtfs attributes instead of the `fsetxattrat_nofollow` helper. + +This reliably happened for me in CI, but I don't have access to the CI host or the time to strip the test down to make a minimal test case, and had difficulty reproducing the error on other machines. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1877688 b/results/classifier/deepseek-2-tmp/output/files/1877688 new file mode 100644 index 000000000..2a5cd4398 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1877688 @@ -0,0 +1,12 @@ + +9p virtfs device reports error when opening certain files + +Reading certain files on a 9p mounted FS produces this error message: + +qemu-system-x86_64: VirtFS reply type 117 needs 12 bytes, buffer has 12, less than minimum + +After this error message is generated, further accesses to the 9p FS hangs whatever tries to access it. The Arch Linux guest system is otherwise usable. This happens with QEMU 5.0.0 and guest kernel version 5.6.11, hosted on an Arch Linux distro. I use the following command to launch QEMU: + +exec qemu-system-x86_64 -enable-kvm -display gtk -vga virtio -cpu host -m 4G -netdev tap,ifname=vmtap0,id=vn0,script=no,downscript=no -device virtio-net-pci,netdev=vn0 -kernel kernel.img -drive file=file.img,format=raw,if=virtio -virtfs local,path=mnt,mount_tag=host0,security_model=passthrough,id=host0 -append "console=ttyS0 root=/dev/vda rw" + +There's nothing relevant in the guest kernel logs as far as I'm aware of with loglevel set to 7. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1880518 b/results/classifier/deepseek-2-tmp/output/files/1880518 new file mode 100644 index 000000000..7aa97ed9c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1880518 @@ -0,0 +1,17 @@ + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1): \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1881648 b/results/classifier/deepseek-2-tmp/output/files/1881648 new file mode 100644 index 000000000..ff7422621 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1881648 @@ -0,0 +1,18 @@ + +`qemu-img info` reports an incorrect actual-size when the underlying posix filesystem has transparent compression + +qemu-img info reports the same thing as `du`*1024: + +$ qemu-img info --output json ./my.qcow2 | jq '."actual-size"' +558619648 + +$ du ./my.qcow2 +545527 ./my.qcow2 + +$ echo $((558619648 / 545527)) +1024 + +and this is correct in terms of bytes on disk, but due to transparent compression implemented by the filesystem, it is not the actual byte count: + +$ du -h --apparent-size ./my.qcow2 +1346568192 my.qcow2 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1883414 b/results/classifier/deepseek-2-tmp/output/files/1883414 new file mode 100644 index 000000000..9a801858d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1883414 @@ -0,0 +1,28 @@ + +Cannot build qemu-5.0.0 from tarball + +Cannot build qemu 5.0.0 from the release tarball. Building from git-clone succeeds. + +After downloading and unpacking the 5.0.0 tarball, I typed the following: + +mkdir build +cd build +../configure + +Then got the following error message: + +ERROR: missing file /home/uri/qemu-5.0.0/ui/keycodemapdb/README + +This is not a GIT checkout but module content appears to +be missing. Do not use 'git archive' or GitHub download links +to acquire QEMU source archives. Non-GIT builds are only +supported with source archives linked from: + + https://www.qemu.org/download/#source + +Developers working with GIT can use scripts/archive-source.sh +if they need to create valid source archives. + +It appears the ui/keycodemapdb is missing some files that are obtained from a git submodule in a git tree. + +Building from a git clone succeeds. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1886225 b/results/classifier/deepseek-2-tmp/output/files/1886225 new file mode 100644 index 000000000..0fc5285c7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1886225 @@ -0,0 +1,17 @@ + +[Feature request] Oracle Solaris 11.4 VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1888728 b/results/classifier/deepseek-2-tmp/output/files/1888728 new file mode 100644 index 000000000..7e8acee5c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1888728 @@ -0,0 +1,20 @@ + +Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. + +Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: + +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. +Aborted +root@nofan:~/qemu> + +The problem can be worked around by bind-mounting /proc from the host system into the target chroot: + +root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +(sid-m68k-sbuild)root@nofan:/# + +Host system is an up-to-date Debian unstable (2020-07-23). + +I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1889033 b/results/classifier/deepseek-2-tmp/output/files/1889033 new file mode 100644 index 000000000..302eafcfe --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1889033 @@ -0,0 +1,95 @@ + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1889421 b/results/classifier/deepseek-2-tmp/output/files/1889421 new file mode 100644 index 000000000..1395498c0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1889421 @@ -0,0 +1,14 @@ + +VVFAT is not writable from Windows NT 3.5, 3.51 and 4.0 + +I'm running Windows NT 3.5, 3.51 and 4.0 in QEMU 4.2.0 on Linux. I'm using a VVFAT filesystem. Command lines: + +$ qemu-system-i386 -L pc -cpu 486 -m 64 -vga cirrus -drive file=nt351.img,format=raw -net nic,model=pcnet -net user -soundhw sb16,pcspk -drive file=fat:rw:drived,format=raw + +$ qemu-system-i386 --version +QEMU emulator version 4.2.0 (Debian 1:4.2-6) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Creating a new directory or file on drive D: (the VVFAT filesystem) fails on Windows NT 3.5, 3.51 and 4.0 (see screenshot). It succeeds on Windows NT 3.1. + +Is there a workaround, e.g. a QEMU flag or a change in the Windows NT driver settings? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1893010 b/results/classifier/deepseek-2-tmp/output/files/1893010 new file mode 100644 index 000000000..612aa6692 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1893010 @@ -0,0 +1,6 @@ + +qemu linux-user doesn't support OFD fcntl locks + +"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. + +Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1893807 b/results/classifier/deepseek-2-tmp/output/files/1893807 new file mode 100644 index 000000000..edb3816ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1893807 @@ -0,0 +1,14 @@ + +Crash when launching windows qemu version from WSL2 + +Version: 5.1.0 +Command line from WSL2: +qemu-system-x86_64.exe -hdd /home/jesus/proyectos/RWivOS/bin/RELEASE/image.hdd -m 4G -smp 4 -machine q35 -debugcon stdio + +OS: Windows 10(64 bits) from WSL2 Ubuntu 18.04 + +The error: +ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/block.c:1325:bdrv_open_driver: assertion + failed: (is_power_of_2(bs->bl.request_alignment)) + +The problem i'm seeing when i lauch from wsl2 only occurs when launched with argument -hdd from WSL2, if i launch it from Windows pointing to the WSL path where the file is stored works. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1895122 b/results/classifier/deepseek-2-tmp/output/files/1895122 new file mode 100644 index 000000000..4eb3a8202 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1895122 @@ -0,0 +1,50 @@ + +qemu on wsl tests failed, this configured with debug + + +../configure --enable-debug-info --enable-debug + +** +ERROR:../tests/test-util-filemonitor.c:704:test_file_monitor_events: assertion failed: (err == 0) +Aborted (core dumped) + + + TEST iotest-qcow2: 271 [fail] +QEMU -- "/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/home/lygstate/work/qemu/build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/x86_64 DESKTOP-BLLJ03T 4.4.0-19041-Microsoft +TEST_DIR -- /home/lygstate/work/qemu/build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmp.eyVcw8nLNQ +SOCKET_SCM_HELPER -- /home/lygstate/work/qemu/build/tests/qemu-iotests/socket_scm_helper + +--- /home/lygstate/work/qemu/tests/qemu-iotests/271.out 2020-09-10 15:00:58.190763400 +0800 ++++ /home/lygstate/work/qemu/build/tests/qemu-iotests/271.out.bad 2020-09-10 18:38:25.625090800 +0800 +@@ -37,6 +37,7 @@ + write -q -P PATTERN 0 64k + L2 entry #0: 0x8000000000050000 00000000ffffffff + discard -q 0 64k ++Content mismatch at offset 0! + L2 entry #0: 0x0000000000000000 ffffffff00000000 + write -q -c -P PATTERN 0 64k + L2 entry #0: 0x4000000000050000 0000000000000000 +@@ -79,6 +80,7 @@ + write -q -P PATTERN 0 64k + L2 entry #0: 0x8000000000050000 00000000ffffffff + discard -q 0 64k ++Content mismatch at offset 0! + L2 entry #0: 0x0000000000000000 ffffffff00000000 + write -q -c -P PATTERN 0 64k + L2 entry #0: 0x4000000000050000 0000000000000000 + TEST iotest-qcow2: 283 + TEST iotest-qcow2: 287 + TEST iotest-qcow2: 290 + TEST iotest-qcow2: 292 + TEST iotest-qcow2: 299 +Not run: 060 181 220 259 +Failures: 271 +Failed 1 of 118 iotests +make: [/home/lygstate/work/qemu/tests/Makefile.include:144: check-block] Error 1 (ignored) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1901892 b/results/classifier/deepseek-2-tmp/output/files/1901892 new file mode 100644 index 000000000..23802fe88 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1901892 @@ -0,0 +1,39 @@ + +qemu-img create corrupts the qcow2 if the file already exists + +When creating a disk using qemu-img create command, if the destination path of the qcow2 file already exists, it will show the error saying that it cannot get a lock so it exits with exit status 1 but it will corrupt the qcow2 file anyway. + +Steps to reproduce: +1. Have a guest running with a root (vda) and a second device (vdc). +In my case is a clean Ubuntu 16.04 image with kernel 4.4.0-190-generic x86_64 +vdc disk is called testadddisk-3.qcow2 +2. vdc is an xfs over lvm. +pvcreacte /dev/vdc +vgcreate myVg /dev/vdc +lvcreate -l+100%FREE -n myLv myVg +mkfs.xfs /dev/mapper/myVg-myLv +mount /dev/mapper/myVg-myLv /mnt +3. Create disk IO on that device in the guest. +while true ; do dd if=/dev/zero of=/mnt/testfile bs=1024 count=1000 ; sleep 1; done +4. Execute the command to create a new device but use the same name of the device attached: +sudo qemu-img create -f qcow2 testadddisk-3.qcow2 20G +The output of the command is this: +Formatting 'testadddisk-3.qcow2', fmt=qcow2 size=21474836480 cluster_size=65536 lazy_refcounts=off refcount_bits=16 +qemu-img: testadddisk-3.qcow2: Failed to get "write" lock +Is another process using the image? + +The write continues in the guest but when it is shutdown, when it is powered on again you get this: +error: Failed to start domain testadddisk +error: internal error: process exited while connecting to monitor: 2020-10-27T22:00:51.628374Z qemu-system-x86_64: -drive file=/var/lib/vmImages/testadddisk-3.qcow2,format=qcow2,if=none,id=drive-virtio-disk2: Image is not in qcow2 format + +I run the qemu-img create command with an strace and I believe that first it tries to open the file in write mode, then does a truncate on it and after that says it cannot get a lock. The output is in the file attached. As well as the guest xml just in case. + +The host: +Ubuntu 18.04.5 LTS +4.15.0-112-generic x86_64 +qemu packages installed: +ii qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu7.32 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-kvm 1:2.11+dfsg-1ubuntu7.31 amd64 QEMU Full virtualization on x86 hardware +ii qemu-system-common 1:2.11+dfsg-1ubuntu7.32 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 1:2.11+dfsg-1ubuntu7.31 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.11+dfsg-1ubuntu7.32 amd64 QEMU utilities \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1902262 b/results/classifier/deepseek-2-tmp/output/files/1902262 new file mode 100644 index 000000000..c320a14da --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1902262 @@ -0,0 +1,20 @@ + +vmstate_load_state return error into virtio_load function + +Qemu version 4.2.1 + +In the function of virtio_load, the vmstate_load_state will return error in the following case. + +The virtio is legacy mode(disable-modern=on,disable-legacy=off), virtio_device is in reset state. + +In the the function of "vmstate_load_state", it will load all subsection. For the vmstate_virtio_extra_state subsection. +It will execute: +vmstate_load_state --> + ret = field->info->get(f, curr_elem, size, field); line 143 vmstate.c. + -->virtio_pci_load_extra_state + --> vmstate_load_state + -->qemu_peek_byte +But if the f->buf_index is same with buf_size, qemu_peek_byte function will set "-EIO" error. +the field->info->get will return 0, then it will get the error "ret = qemu_file_get_error(f);". then the vmstate_load_state will return error. + +It output is "Failed to load virtio/extra_state:extra_state" \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1904206 b/results/classifier/deepseek-2-tmp/output/files/1904206 new file mode 100644 index 000000000..398977635 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1904206 @@ -0,0 +1,19 @@ + +install QEMU + +I want install QEMU on Kali, I write : + +qemu-system-arm -kernel ~/qemu_vms/kernel-qemu-3.10.25-wheezy -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda ~/qemu_vms/2020-08-20-raspios-buster-armhf-full.img -nic user,hostfwd=tcp::5022-:22 -no-reboot + +The answer : + +WARNING: Image format was not specified for '/home/kali/qemu_vms/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument +Uncompressing Linux... done, booting the kernel. + +I tried a lot of solutions but nothing worked. Please help \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1905979 b/results/classifier/deepseek-2-tmp/output/files/1905979 new file mode 100644 index 000000000..58fe462ed --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1905979 @@ -0,0 +1,16 @@ + +Check if F_OFD_SETLK is supported may give wrong result + +In util/osdep.c there is a function qemu_probe_lock_ops() to check if file locks F_OFD_SETLK and F_OFD_GETLK (of the style "Open file description locks (non-POSIX)") are supported. + +This test is done by trying a lock operation on the file /dev/null. + +This test can get a wrong result. + +The result is (probably) if the operating system *in general* supports these locks. However, it does not guarantee that the file system where the lock is really wanted (for instance, in caller raw_check_lock_bytes() in block/file-posix.c) does support these locks. + +(In theory it could even be that /dev/null, being a device special file, does not support the lock type while a plain file would.) + +This is in particular relevant for disk images which are stored on a shared file system (my particular use case is the Quobyte file system, which appears not to support these locks). + +The code as mentioned above is present in the master branch (I checked commit ea8208249d1082eae0444934efb3b59cd3183f05) but also for example on stable-2.11 commit 0982a56a551556c704dc15752dabf57b4be1c640) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1911666 b/results/classifier/deepseek-2-tmp/output/files/1911666 new file mode 100644 index 000000000..d8d2e8c58 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1911666 @@ -0,0 +1,71 @@ + +ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability + +-- CVSS ----------------------------------------- + +7.5: AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H + +-- ABSTRACT ------------------------------------- + +Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: +QEMU - QEMU + +-- VULNERABILITY DETAILS ------------------------ + +Version tested:5.0.0-rc3 +Installer file:qemu-5.0.0-rc3.tar.xz +Platform tested:ubuntu 18.04 x64 desktop +Analysis Basically v9fs* functions called from guest kernel are executed under specific thread(I call it main thread later). But when it calls some file related system calls, qemu uses its own coroutine thread(worker thread). Then it returns(yield return) without waiting result of system call and start to execute next v9fs* function. + +In v9fsmarkfidsunreclaim() function, it stores fidlist member (head of singly linked list) to its stack. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L506 + +And if it uses coroutine, it restore fid_list from stack and restart whole loop. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L526 + +v9fsclunk() function calls clunkfid() which unlink fid from list, and free it. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L2060-L2091 + +So if v9fsclunk() is called while v9fsmarkfidsunreclaim()'s coroutine is being executed, it restores "FREED" fidp from stack and use it. + +it can be reproduced with the qemu binary, which is given +it can also be reproduced with own ASAN build (5.0.0-rc3 and 4.2.0 are tested) + +../qemu-5.0.0-rc3/x86_64-softmmu/qemu-system-x86_64 -M pc -kernel ./bzImage -initrd ./rootfs.cpio -append "root=/dev/ram console=tty1 console=ttyS0 rdinit=/bin/sh" -nographic -enable-kvm -fsdev local,id=test_dev,path=/home/xxx/sandbox,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=victim_tag + +$ ./do.sh +expected ASAN report is printed +the race is in coroutine, so the threads are the same one + +================================================================= + ==46645==ERROR: AddressSanitizer: heap-use-after-free on address 0x610000047948 at pc 0x5563d8c28f0f bp0 +READ of size 2 at 0x610000047948 thread T0 + + #0 0x5563d8c28f0e in v9fs_mark_fids_unreclaim hw/9pfs/9p.c:508 + #1 0x5563d8c3e9e3 in v9fs_remove hw/9pfs/9p.c:2988 + #2 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #3 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + 0x610000047948 is located 8 bytes inside of 192-byte region [0x610000047940,0x610000047a00) freed by thread T0 here: + + #0 0x7fadafa5f7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) + #1 0x5563d8c27a60 in free_fid hw/9pfs/9p.c:371 + #2 0x5563d8c27fcc in put_fid hw/9pfs/9p.c:396 + #3 0x5563d8c37267 in v9fs_clunk hw/9pfs/9p.c:2085 + #4 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #5 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + +previously allocated by thread T0 here: + #0 0x7fadafa5fd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) + #1 0x7fadaf0c8b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) + #2 0x5563d8c30ecc in v9fs_attach hw/9pfs/9p.c:1412 + #3 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #4 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + +This vulnerability was discovered by: + +Ryota Shiga(@Garyo) of Flatt Security working with Trend Micro Zero Day Initiative \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1913012 b/results/classifier/deepseek-2-tmp/output/files/1913012 new file mode 100644 index 000000000..d2fd77e76 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1913012 @@ -0,0 +1,36 @@ + +Installed firmware descriptor files contain (invalid) relative paths + +Unless the Qemu build is configured using `./configure --datadir=<path> where <path> is some absolute path which is a subdirectory of <prefix>, the resulting installed firmware descriptor files contain relative paths for their `mapping.filename` properties. These relative paths will not be accepted as valid by tools like `virt-install`, resulting in the inability to configure new VMs using these firmware descriptors. + +# QEMU version +$ qemu-system-x86_64 -version +QEMU emulator version 5.2.0 + +(I've also reproduced the issue with QEMU built from Git master @ v5.2.0-1300-g0e32462630, see next comment.) + +# OS version +Void Linux x86_64 (glibc) + +Steps to reproduce (with results on my system): + +# Verify the symptom + +$ virt-install --boot firmware=efi --disk none --memory 2048 +Using default --name vm4 +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR Failed to open file 'share/qemu/edk2-i386-vars.fd': No such file or directory +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///session start vm4 +otherwise, please restart your installation. + +# Verify most likely cause + +$ grep filename /usr/share/qemu/firmware/*i386*.json +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-code.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-vars.fd", \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1917082 b/results/classifier/deepseek-2-tmp/output/files/1917082 new file mode 100644 index 000000000..a9b6234e1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1917082 @@ -0,0 +1,129 @@ + +[OSS-Fuzz] Issue 27574 e1000: Loopback-related stack-overflow + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -M q35 -nodefaults -device e1000,netdev=net0 -netdev user,id=net0 \ +-qtest /dev/null -qtest stdio +outl 0xcf8 0x80000813 +outl 0xcfc 0xfe +outl 0xcf8 0x80000803 +outw 0xcfc 0x0600 +write 0xfe000102 0x1 0x0a +writel 0xfe000020 0x420ff00 +write 0xfe00280a 0x2 0x0828 +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +write 0xfe00281b 0x1 0x08 +write 0xf9b 0x1 0x01 +write 0x2170 0x1 0x14 +write 0x2171 0x1 0x38 +write 0x2173 0x1 0xfe +write 0xfe000402 0x1 0x02 +write 0xfe00380a 0x2 0x0210 +write 0xfe003818 0x1 0xfa +EOF + +=== Stack-trace === +==288216==ERROR: AddressSanitizer: stack-overflow on address 0x7fff51c96f48 (pc 0x56247061af36 bp 0x7fff51c97790 sp 0x7fff51c96f50 T0) +#0 0x56247061af36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36) +#1 0x5624718eb70d in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2846:13 +#2 0x5624718ecd1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 +#3 0x5624718ecd1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 +#4 0x562470bcb75b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#5 0x562470bcb75b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#6 0x562470bcb75b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#7 0x562470bcb75b in pci_dma_read /home/alxndr/Development/qemu/include/hw/pci/pci.h:821:12 +#8 0x562470bcb75b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:954:9 +#9 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#10 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +#11 0x562470bc7dd8 in xmit_seg /home/alxndr/Development/qemu/build/../hw/net/e1000.c +#12 0x562470bc4dfe in process_tx_desc /home/alxndr/Development/qemu/build/../hw/net/e1000.c:701:9 +#13 0x562470bc4dfe in start_xmit /home/alxndr/Development/qemu/build/../hw/net/e1000.c:756:9 +#14 0x562470bc4dfe in set_tctl /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1127:5 +#15 0x5624719ef2f6 in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 +#16 0x5624719eed63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +#17 0x5624719ee5c0 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c +#18 0x5624718f7776 in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2776:23 +#19 0x5624718ed13b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2816:14 +#20 0x5624718ed13b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2908:18 +#21 0x562470bcba6b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#22 0x562470bcba6b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#23 0x562470bcba6b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#24 0x562470bcba6b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:839:12 +#25 0x562470bcba6b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:967:21 +#26 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#27 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +... \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1917940 b/results/classifier/deepseek-2-tmp/output/files/1917940 new file mode 100644 index 000000000..d85dd4ca6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1917940 @@ -0,0 +1,6 @@ + +-bios edk2-$arch-code doesn't work for x86 + +Whilst creating a flash device is recommended, -bios <file> is extremely useful in many cases as it automatically searches $PREFIX/share/qemu rather than requiring the caller (be it a human or a script) to work out where that directory is for the QEMU being called and prepend it to the file name. + +Currently, all the x86 EDK2 FD code files are 3653632 bytes in size, or 0x37c000 bytes. However, for some reason I cannot find the answer to (I traced the code back to 7587cf44019d593bb12703e7046bd7738996c55c), x86's -bios only allows files that are multiples of 64K in size (x86_bios_rom_init), which would require the EDK2 ROMs to be rounded up to 0x380000 bytes. If I delete the check, QEMU is able to load the only-16K-multiple-sized EDK2 and boot an OS just fine. If I pad EDK2 with 16K of zeroes at the *start* (since the ROM gets mapped counting backwards), it also works just fine (but padding at the *end* doesn't). Please therefore either relax the check in x86_bios_rom_init or ensure the EDK2 binary is suitably padded. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1920211 b/results/classifier/deepseek-2-tmp/output/files/1920211 new file mode 100644 index 000000000..247dd585d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1920211 @@ -0,0 +1,14 @@ + +shrink option for discard (for bad host-filesystems and -backup solutions) + +When using discard=unmap for virtio or scsi devices with QCOW2 images, space discarded by the guest will be unmaped on the host, which is basically great! + +This will turn the QCOW2 image into a sparse file which is efficient for most scenarios. But it may be that you need to avoid big sparse files on your host. For example because you need to use a backup solution which doesn't support sparse files well. Or maybe the QCOW2 image is on a filesystem mount which doesn't support sparse files at all. + +For those scenarios an alternative option for the discard setting (discard=shrink) would be great, so that the QCOW2 file itself gets shrunken again. +I'm not sure about how the initial growing* of QCOW2 images is implemented and if there are maybe limitations. But I hope it may be possible do the inverse and actually shrink (not sparse) an QCOW2 image with internally discarded blocks. + + +I'm using Qemu-5.2.0 and Linux >= 5.3 (host and guest). + +*If you use "qemu-img create -f qcow2 ..." withOUT the "preallocation" option. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1923 b/results/classifier/deepseek-2-tmp/output/files/1923 new file mode 100644 index 000000000..caf094edd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1923 @@ -0,0 +1,19 @@ + +qemu breaks vmdk larger than 600GB. +Description of problem: +The vmdk larger than 600G is corrupted after an edit by qemu-nbd. If I open the corrupted vmdk file, I find an extra **^@** byte. +``` +RW 4194304 SPARSE "disk-s289.vmdk" +RW 4^@94304 SPARSE "disk-s290.vmdk" +RW 4194304 SPARSE "disk-s291.vmdk" +``` +Steps to reproduce: +``` + qemu-img create -f vmdk -o subformat=twoGbMaxExtentSparse disk.vmdk 1T + sudo qemu-nbd -c /dev/nbd0 disk.vmdk + sudo mkfs.btrfs /dev/nbd0 + sudo qemu-nbd -d /dev/nbd0 + qemu-img info disk.vmdk | head + ``` +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/1924987 b/results/classifier/deepseek-2-tmp/output/files/1924987 new file mode 100644 index 000000000..4421959d0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1924987 @@ -0,0 +1,13 @@ + +Storage | Two decimal digits precision + +Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64 + +Hello. A two decimal digits precision is most appropriated on systems whose storage capacities have to be saved. That is one of the reason why such precision is supported in the context of creation of virtual machines in several Unix/Linux virtualization platforms; virt-manager is one of them. That last exhibits virtual disks size values with such precision – 128.00 GiB – nevertheless it lacks yet a mention illustrating physical disks size values. + +Storage values exhibited in qemu-img and virt-manager are already according to a clear format; thus, values are not attached to their measure units (#value# #units#). + +$ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n '2,4p' +file format: qcow2 +virtual size: 128 GiB (137438953472 bytes) +disk size: 147 MiB \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/1944 b/results/classifier/deepseek-2-tmp/output/files/1944 new file mode 100644 index 000000000..f420a746a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1944 @@ -0,0 +1,72 @@ + +Deadlock on snapshot removal (bdrv_graph_wrlock) +Description of problem: +VM was hanging during snapshot removal. +There was an attempt to shutdown the VM, but that did hang. + +gdb shows me: +``` +(gdb) bt full +#0 0x00007f20493427fe in __ppoll (fds=0x557e630718b0, nfds=2, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43 + sc_ret = -514 + sc_cancel_oldtype = 0 + sc_ret = <optimized out> + tval = {tv_sec = 139776632323420, tv_nsec = 139776632323432} +#1 0x0000557e619cab52 in fdmon_poll_wait.llvm () +No symbol table info available. +#2 0x0000557e619ca0b6 in aio_poll () +No symbol table info available. +#3 0x0000557e61801651 in bdrv_graph_wrlock () +No symbol table info available. +#4 0x0000557e617c873b in bdrv_replace_child_noperm.llvm () +No symbol table info available. +#5 0x0000557e617c8601 in bdrv_root_unref_child () +No symbol table info available. +#6 0x0000557e617f6333 in blk_unref () +No symbol table info available. +#7 0x0000557e6181b0d1 in mirror_exit_common () +No symbol table info available. +#8 0x0000557e617dbdb4 in job_do_finalize_locked.llvm () +No symbol table info available. +#9 0x0000557e617dd72b in job_exit () +No symbol table info available. +#10 0x0000557e619e5101 in aio_bh_poll () +No symbol table info available. +#11 0x0000557e619c95a4 in aio_dispatch () +No symbol table info available. +#12 0x0000557e619e655f in aio_ctx_dispatch () +No symbol table info available. +#13 0x00007f2049546e2f in g_main_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:3337 + dispatch = 0x557e619e6550 <aio_ctx_dispatch> + prev_source = 0x0 + begin_time_nsec = 232172181173336 + was_in_call = <optimized out> + user_data = 0x0 + callback = 0x0 + cb_funcs = 0x0 + cb_data = 0x0 + need_destroy = <optimized out> + source = 0x557e62ec73e0 + current = 0x557e63e4b600 + i = 0 + __func__ = {<optimized out> <repeats 16 times>} +#14 g_main_context_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:4055 +No locals. +#15 0x0000557e619e74be in main_loop_wait () +No symbol table info available. +#16 0x0000557e615201e7 in qemu_main_loop () +No symbol table info available. +#17 0x0000557e61374c6a in qemu_default_main () +No symbol table info available. +#18 0x00007f204923feb0 in __libc_start_call_main (main=main@entry=0x557e61374c80 <main>, argc=argc@entry=153, argv=argv@entry=0x7ffe07495238) at ../sysdeps/nptl/libc_start_call_main.h:58 + self = <optimized out> + result = <optimized out> + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6145724763479124305, 140729020666424, 94001285254272, 94001294953808, 139776661151744, 6145708635144279727, 6121919821307926191}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7f204954cb41 <g_malloc0+33>, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1230293825}}} + not_first_call = <optimized out> +#19 0x00007f204923ff60 in __libc_start_main_impl (main=0x557e61374c80 <main>, argc=153, argv=0x7ffe07495238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe07495228) at ../csu/libc-start.c:389 +No locals. +#20 0x0000557e613743d5 in _start () +No symbol table info available. +``` +Steps to reproduce: +Still trying to reproduce in lab. diff --git a/results/classifier/deepseek-2-tmp/output/files/1959 b/results/classifier/deepseek-2-tmp/output/files/1959 new file mode 100644 index 000000000..2074fb6df --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1959 @@ -0,0 +1,2 @@ + +qemu-img: support ZSTD compression level customization diff --git a/results/classifier/deepseek-2-tmp/output/files/2029 b/results/classifier/deepseek-2-tmp/output/files/2029 new file mode 100644 index 000000000..5192854e7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2029 @@ -0,0 +1,2 @@ + +[block jobs]Guest hang when dd file on snapshot overlay(iothread enable) diff --git a/results/classifier/deepseek-2-tmp/output/files/2036 b/results/classifier/deepseek-2-tmp/output/files/2036 new file mode 100644 index 000000000..c637aa5ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2036 @@ -0,0 +1,12 @@ + +`edk2-riscv-code.fd.bz2` is included in the repo but not installed to `$PREFIX/share/qemu` +Description of problem: +`edk2-riscv-code.fd.bz2` is included in the repo (https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/edk2-riscv-code.fd.bz2), but this file is not installed to `$PREFIX/share/qemu`. + +The binaries for other architectures (aarch64, arm, i386, x86\_64) are installed as expected. +https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/meson.build?ref_type=tags#L3-L12 +Steps to reproduce: +`ls $PREFIX/share/qemu/edk2-*` +Additional information: +- Not sure if this is intentional or a bug. +- The descriptor JSON file is missing for riscv: https://gitlab.com/qemu-project/qemu/-/tree/v8.2.0-rc4/pc-bios/descriptors diff --git a/results/classifier/deepseek-2-tmp/output/files/2054889 b/results/classifier/deepseek-2-tmp/output/files/2054889 new file mode 100644 index 000000000..549eaac00 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2054889 @@ -0,0 +1,34 @@ + +pcap streams are text files which insert 0xD in Windows version + +Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. + +Starting at line 275 in hw/usb/bus (https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/bus.c?ref_type=heads#L275), the file is opened as text instead of binary. + +I think the following patch would fix the issue: + if (dev->pcap_filename) { +- int fd = qemu_open_old(dev->pcap_filename, O_CREAT | O_WRONLY | O_TRUNC, 0666); ++ int fd = qemu_open_old(dev->pcap_filename, O_CREAT | O_WRONLY | O_TRUNC | O_BINARY, 0666); + if (fd < 0) { + error_setg(errp, "open %s failed", dev->pcap_filename); + usb_qdev_unrealize(qdev); + return; + } +- dev->pcap = fdopen(fd, "w"); ++ dev->pcap = fdopen(fd, "wb"); + usb_pcap_init(dev->pcap); + } + +To show an example, when using a very common protocol to USB disks, the BBB protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10) command (implemented at https://gitlab.com/qemu-project/qemu/-/blob/master/hw/scsi/scsi-disk.c#L2068) will have a command block length of 10 (0xA). When this 10-byte command (part of the 31-byte CBW) is placed into the PCAP file, the Windows file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a 32-byte CBW. + +Actual CBW: + 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC............ + 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. + +PCAP CBW + 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............ + 0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. + +I believe simply opening the PCAP file as BINARY instead of TEXT will fix this issue. + +Thank you. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/207 b/results/classifier/deepseek-2-tmp/output/files/207 new file mode 100644 index 000000000..47fc3d36a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/207 @@ -0,0 +1,2 @@ + +move ./scripts/qmp to ./python/qemu/qmp diff --git a/results/classifier/deepseek-2-tmp/output/files/2118 b/results/classifier/deepseek-2-tmp/output/files/2118 new file mode 100644 index 000000000..581e4f689 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2118 @@ -0,0 +1,2 @@ + +make vm-build-openbsd reinstalls OpenBSD every time diff --git a/results/classifier/deepseek-2-tmp/output/files/2140 b/results/classifier/deepseek-2-tmp/output/files/2140 new file mode 100644 index 000000000..1409826f0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2140 @@ -0,0 +1,2 @@ + +Compiling object tests/fp - Can't create tests/fp Is directory Centos 7 diff --git a/results/classifier/deepseek-2-tmp/output/files/2171 b/results/classifier/deepseek-2-tmp/output/files/2171 new file mode 100644 index 000000000..485f3fc2a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2171 @@ -0,0 +1,26 @@ + +VPS Disk space over use +Description of problem: +\# qemu-img info -U v1001-dluw9EHRDbmMd8fQ-CACjC7FWnMhISeDM.qcow2 + +file format: qcow2 + +virtual size: 800G (858993459200 bytes) + +disk size: **812G** + +cluster_size: 65536 + +Format specific information: + +compat: 1.1 + +lazy refcounts: false + +refcount bits: 16 + +corrupt: false + +Disk size is using beyond the Virtual size. + +How is that even possible ? diff --git a/results/classifier/deepseek-2-tmp/output/files/2179 b/results/classifier/deepseek-2-tmp/output/files/2179 new file mode 100644 index 000000000..78e0deea9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2179 @@ -0,0 +1,52 @@ + +qemu-storage-daemon: fuse export deadlock +Steps to reproduce: +1. Start QSD +2. Issue a `block-stream` and a read from the fuse export at the same time + +``` +Term 1: +(QEMU) block-stream device=root job-id=job1 +{"return": {}} +(QEMU) +{'timestamp': {'seconds': 1708386076, 'microseconds': 965781}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'created', 'id': 'job1'}} +{'timestamp': {'seconds': 1708386076, 'microseconds': 965838}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'running', 'id': 'job1'}} +(QEMU) +(QEMU) +(QEMU) +(QEMU) query-block-jobs + +<HANGS> + + +Term 2: +dd if=/tmp/fuse_exp of=/dev/null bs=1M skip=2000 +<HANGS> +``` + +``` +$ pidof qemu-storage-daemon + 92313 +$ sudo cat /proc/92313/task/92313/stack +[<0>] do_sys_poll+0x4e1/0x5d0 +[<0>] __x64_sys_ppoll+0xe2/0x170 +[<0>] do_syscall_64+0x64/0xe0 +[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 + +$ sudo cat /proc/92313/task/92314/stack +[<0>] futex_wait_queue+0x63/0x90 +[<0>] __futex_wait+0x14f/0x1c0 +[<0>] futex_wait+0x77/0x110 +[<0>] do_futex+0xcb/0x190 +[<0>] __x64_sys_futex+0x129/0x1e0 +[<0>] do_syscall_64+0x64/0xe0 +[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 +``` +Additional information: +This might also be a general between `block-stream` and `copy-on-read` but I could only trigger the problem with FUSE and not NBD. E.g this command does not deadlock: +``` +--export type=nbd,id=nbd-root,node-name=root_crw,name=root_crw,writable=off + +nbdfuse /tmp/tmp.69dRvNXj1O/disk nbd://localhost:10809/root_crw +dd if=/tmp/tmp.69dRvNXj1O/disk of=/dev/null bs=1M skip=2000 +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/2190 b/results/classifier/deepseek-2-tmp/output/files/2190 new file mode 100644 index 000000000..59a185513 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2190 @@ -0,0 +1,8 @@ + +qemu-block-drivers.rst.inc is embedded twice +Description of problem: +`qemu-block-drivers.rst.inc` is included both in `docs/system/qemu-block-drivers.rst` and in `docs/system/images.rst`, so it is repeated both at https://www.qemu.org/docs/master/system/qemu-block-drivers.html and at https://www.qemu.org/docs/master/system/images.html . + +This also makes the generation of the sphinx `objects.inv` search index nondeterministic: it will point to one page or the other depending on random chance at build time. + +Perhaps instead of embedding the drivers, `images.rst` should point to https://www.qemu.org/docs/master/system/qemu-block-drivers.html for the list? diff --git a/results/classifier/deepseek-2-tmp/output/files/2202 b/results/classifier/deepseek-2-tmp/output/files/2202 new file mode 100644 index 000000000..c6ab73c0e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2202 @@ -0,0 +1,34 @@ + +Crash in contrib/elf2dmp +Description of problem: +The elf2dmp program crash. +``` +$ ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +Using Linux mmap +[1] 994585 segmentation fault ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +``` +Steps to reproduce: +1. build the qemu project following standard steps +2. navigate to the `build` directory and run `./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null` + +The [crash_1](/uploads/d0890c0f8873b8264c417b0f98ee83a4/crash_1) file. +Additional information: +Run in GDB. +``` +$ gdb ./contrib/elf2dmp/elf2dmp +... +(gdb) set args ./crash_1 /dev/null +(gdb) r +Starting program: /data/share/qemu_latest/build/contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Using Linux mmap + +Program received signal SIGSEGV, Segmentation fault. +init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +66 Elf64_Nhdr *start = (void *)((uint8_t *)qe->map + phdr[0].p_offset); +(gdb) bt +#0 init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +#1 QEMU_Elf_init (qe=qe@entry=0x7fffffff83f0, filename=<optimized out>) at ../contrib/elf2dmp/qemu_elf.c:235 +#2 0x0000555555555508 in main (argc=<optimized out>, argv=0x7fffffffdb58) at ../contrib/elf2dmp/main.c:538 +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/2405 b/results/classifier/deepseek-2-tmp/output/files/2405 new file mode 100644 index 000000000..30fa9ec0f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2405 @@ -0,0 +1,17 @@ + +Qemu on Windows fails to parse absolute file path in -acpitable switch +Description of problem: +I expect qemu-system-x86_64.exe to navigate to the path provided with -acpitable switch and to try to parse it. Instead, Qemu prints: "can't open file C: No such file or directory" if provided with absolute path. Qemu thinks "C:" itself is a file with acpi table. + +However, Qemu correctly processes files with relative path. If I run this command to try to parse file COPYING bundled in default qemu build: + +`qemu-system-x86_64.exe -acpitable "file=copying"` + +Qemu says: `qemu-system-x86_64.exe: -acpitable file=copying: warning: ACPI table has wrong length, header says 1313284128, actual size 17992 bytes` + +Then it proceeds to boot BIOS, as usual. +Steps to reproduce: +1. Run `qemu-system-x86_64.exe -acpitable "file=C:\temp\temp.txt"` +2. Experience "can't open file C: No such file or directory" error message returning you to the command prompt. No BIOS screen. +3. Run `qemu-system-x86_64.exe -acpitable "file=copying"` +4. Experience insignificant warning and then a normal BIOS screen. diff --git a/results/classifier/deepseek-2-tmp/output/files/2417 b/results/classifier/deepseek-2-tmp/output/files/2417 new file mode 100644 index 000000000..f99fc13f7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2417 @@ -0,0 +1,6 @@ + +qemu-img allocates full size on exFAT when metadata preallocation is requested +Description of problem: +`qemu-img` seems to preallocate the full size of a qcow2 image on exFAT rather than just the metadata when that is requested. This was initially seen via libvirt/libvirt#649. exFAT does not support sparse files. +Steps to reproduce: +1. Run command diff --git a/results/classifier/deepseek-2-tmp/output/files/2448 b/results/classifier/deepseek-2-tmp/output/files/2448 new file mode 100644 index 000000000..6c4e67e74 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2448 @@ -0,0 +1,47 @@ + +linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin +Description of problem: +When a `*-linux-user` is used as binfmt_misc, and... + +- The `O` (i.e. open-binary) flag is set +- File descriptor 0 is closed when running the executable + +FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable. + +Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior. +Steps to reproduce: +1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary) +2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`) +3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output) + +The correct behavior is (You can see by running the native `cat <&-`): + +``` +cat: -: Bad file descriptor +cat: closing standard input: Bad file descriptor +``` + +Instead, the executable `cat` itself is dumped to stdout. + +Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable. +Additional information: +I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far: + +In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765) + +```c + execfd = qemu_getauxval(AT_EXECFD); + if (execfd == 0) { + execfd = open(exec_path, O_RDONLY); + if (execfd < 0) { + printf("Error while loading %s: %s\n", exec_path, strerror(errno)); + _exit(EXIT_FAILURE); + } + } +``` + +However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value. + +`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`. + +Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay? diff --git a/results/classifier/deepseek-2-tmp/output/files/2493 b/results/classifier/deepseek-2-tmp/output/files/2493 new file mode 100644 index 000000000..04a40d50b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2493 @@ -0,0 +1,2 @@ + +qemu-img delete snapshot by id diff --git a/results/classifier/deepseek-2-tmp/output/files/250 b/results/classifier/deepseek-2-tmp/output/files/250 new file mode 100644 index 000000000..567cff3e0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/250 @@ -0,0 +1,2 @@ + +windows qemu-img fails to convert vhdx, assertion failure diff --git a/results/classifier/deepseek-2-tmp/output/files/2611 b/results/classifier/deepseek-2-tmp/output/files/2611 new file mode 100644 index 000000000..9fed70a4c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2611 @@ -0,0 +1,4 @@ + +[Documentation]What is a Block driver? +Additional information: +Using Windows 11 but can use Linux diff --git a/results/classifier/deepseek-2-tmp/output/files/263 b/results/classifier/deepseek-2-tmp/output/files/263 new file mode 100644 index 000000000..ffb2f41e1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/263 @@ -0,0 +1,2 @@ + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/deepseek-2-tmp/output/files/264 b/results/classifier/deepseek-2-tmp/output/files/264 new file mode 100644 index 000000000..2c3a89335 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/264 @@ -0,0 +1,2 @@ + +qed leaked clusters diff --git a/results/classifier/deepseek-2-tmp/output/files/2719 b/results/classifier/deepseek-2-tmp/output/files/2719 new file mode 100644 index 000000000..af19eea14 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2719 @@ -0,0 +1,2 @@ + +9.2.0 tarball contains unrelated files diff --git a/results/classifier/deepseek-2-tmp/output/files/2735 b/results/classifier/deepseek-2-tmp/output/files/2735 new file mode 100644 index 000000000..c2c106c3b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2735 @@ -0,0 +1,11 @@ + +Couldn't find rom image 'canon-a1100-rom1.bin'. +Description of problem: +``` +$ qemu-system-aarch64 -machine canon-a1100 +qemu-system-aarch64: Couldn't find rom image 'canon-a1100-rom1.bin'. +``` +Steps to reproduce: +``` +qemu-system-aarch64 -machine canon-a1100 +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/2781 b/results/classifier/deepseek-2-tmp/output/files/2781 new file mode 100644 index 000000000..c0baf3f2b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2781 @@ -0,0 +1,2 @@ + +Open logfiles for append diff --git a/results/classifier/deepseek-2-tmp/output/files/2789 b/results/classifier/deepseek-2-tmp/output/files/2789 new file mode 100644 index 000000000..9dfbd4d60 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2789 @@ -0,0 +1,2 @@ + +Emulate a folder instead of creating the iso diff --git a/results/classifier/deepseek-2-tmp/output/files/2811 b/results/classifier/deepseek-2-tmp/output/files/2811 new file mode 100644 index 000000000..aeb23012c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2811 @@ -0,0 +1,95 @@ + +The release artifact for 9.2.1 can not be authenticated with the accompanying OpenPGP signature +Description of problem: +Hi! :wave: + +I package this project for Arch Linux. +This ticket is to inform you that the release artifact for 9.2.1 can not be validated using the accompanying OpenPGP signature. +The signature has been created by the OpenPGP key with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584` (held by @mdroth). +However, I am not able to validate the downloaded archive with the provided signature. + +Please make sure that the archive has not been tampered with and ideally do a full re-release and re-sign cycle. +Steps to reproduce: +Download sources and create checksum: + +```bash +curl -O https://download.qemu.org/qemu-9.2.1.tar.xz +curl -O https://download.qemu.org/qemu-9.2.1.tar.xz.sig +b2sum qemu-9.2.1.tar.xz +062b2ef336dbc488bfd9e6c6a21cd95464ab76a98ce8f66bb314101d25a5dc72815ae4eb28028507c85ddade8a28e00cf8897302645ad6ddd2c093bde1cfba9a qemu-9.2.1.tar.xz +``` + +Get latest version of certificate that can be used to verify the signature: + +```bash +gpg --recv-keys CEACC9E15534EBABB82D3FA03353C9CEF108B584 +gpg: key 3353C9CEF108B584: "Michael Roth <michael.roth@amd.com>" not changed +gpg: Total number processed: 1 +gpg: unchanged: 1 +``` + +Export certificate to file: + +```bash +gpg --export CEACC9E15534EBABB82D3FA03353C9CEF108B584 > mdroth.pgp +``` + +Show info about the certificate: + +``` +gpg --list-sigs CEACC9E15534EBABB82D3FA03353C9CEF108B584 +pub rsa2048 2013-10-18 [SC] [expires: 2026-05-11] + CEACC9E15534EBABB82D3FA03353C9CEF108B584 + Keygrip = D85EA26924D8B15B55C659659E2864C375F1547D +uid [ unknown] Michael Roth <michael.roth@amd.com> +sig 3 3353C9CEF108B584 2020-10-27 [self-signature] +sig 3 3353C9CEF108B584 2024-05-11 [self-signature] +uid [ unknown] Michael Roth <flukshun@gmail.com> +sig 3 3353C9CEF108B584 2013-10-18 [self-signature] +uid [ unknown] Michael Roth <mdroth@utexas.edu> +sig 3 3353C9CEF108B584 2013-10-18 [self-signature] +sub rsa2048 2013-10-18 [E] + Keygrip = 9561B09210E2442DEE64237DBA17A9E9D7A58B04 +sig 3353C9CEF108B584 2013-10-18 [self-signature] +``` + +Try verifying the tarball using gpg: + +```bash +gpg --verify qemu-9.2.1.tar.xz.sig +gpg: assuming signed data in 'qemu-9.2.1.tar.xz' +gpg: Signature made 2025-02-12T03:22:55 CET +gpg: using RSA key CEACC9E15534EBABB82D3FA03353C9CEF108B584 +gpg: BAD signature from "Michael Roth <michael.roth@amd.com>" [unknown] +``` + +Try verifying the tarball using the SOP implementation rsop: + +```bash +rsop verify qemu-9.2.1.tar.xz.sig mdroth.pgp < qemu-9.2.1.tar.xz + No acceptable signatures found +``` + +Try verifying the tarball using sq: + +```bash +sq cert import mdroth.pgp + - ┌ CEACC9E15534EBABB82D3FA03353C9CEF108B584 + └ Michael Roth <michael.roth@amd.com> (UNAUTHENTICATED) + - imported + + +Imported 0 new certificates, updated 0 certificates, 1 certificate unchanged, 0 errors. + +sq verify --signature-file qemu-9.2.1.tar.xz.sig qemu-9.2.1.tar.xz +Error verifying signature made by CEACC9E15534EBABB82D3FA03353C9CEF108B584: + + Error: Message has been manipulated +0 authenticated signatures, 1 bad signature. + + Error: Verification failed: could not authenticate any signatures +``` +Additional information: +On Arch Linux we use the provided release tarball and verify it using the detached signature. +For validation we rely on the OpenPGP certificate with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584`. +The fingerprint is locked in our [build script](https://gitlab.archlinux.org/archlinux/packaging/packages/qemu/-/blob/7cddf5aa82542d6ba511a22aeaa8eca6d6e7d949/PKGBUILD#L158). diff --git a/results/classifier/deepseek-2-tmp/output/files/2912 b/results/classifier/deepseek-2-tmp/output/files/2912 new file mode 100644 index 000000000..ce06f9219 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/2912 @@ -0,0 +1,14 @@ + +qcow2 image corrupted after snapshot+bitmap action +Description of problem: +When taking a backup of the VM via snapshot + bitmap, the qcow2 image became corrupt: +`qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with bitmap directory); further corruption events will be suppressed` + +This resulted in a corrupt (unfix-able) image (see #2909). + +While this process is something that happens multiple times a day, we never hit any issue. +The underlying storage didn't report any error, so it seems like something inside qemu broke the image. +Steps to reproduce: +Unfortunately, I was unable to reproduce this issue yet. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/304636 b/results/classifier/deepseek-2-tmp/output/files/304636 new file mode 100644 index 000000000..2c6674874 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/304636 @@ -0,0 +1,38 @@ + +-hda FAT:. limited to 504MBytes + +Binary package hint: qemu + +The size of the virtual FAT file system (for sharing a particular directory with Guest OS) is hard-coded to be limited to 504MBytes, in block-vvfat.c +-- +/* 504MB disk*/ +bs->cyls=1024; bs->heads=16; bs->secs=63; +-- + +If the directory contents exceeds this is stops with an assert +-- +qemu: block-vvfat.c:97: array_get: Assertion `index < array->next' failed. +Aborted +-- + +Also the FAT16 mode (default) only uses 8KByte cluster sizes which prevents the above being increased. 16KByte and 32KByte sectors can be selected with the following patch +-- +--- block-vvfat.c_orig 2008-12-02 12:37:28.000000000 -0700 ++++ block-vvfat.c 2008-12-02 19:50:35.000000000 -0700 +@@ -1042,6 +1042,12 @@ + s->fat_type = 32; + } else if (strstr(dirname, ":16:")) { + s->fat_type = 16; ++ } else if (strstr(dirname, ":16-16K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x20; ++ } else if (strstr(dirname, ":16-32K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x40; + } else if (strstr(dirname, ":12:")) { + s->fat_type = 12; + s->sector_count=2880; +-- + +Cheers, +Mungewell \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/365 b/results/classifier/deepseek-2-tmp/output/files/365 new file mode 100644 index 000000000..8fd3422d6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/365 @@ -0,0 +1,2 @@ + +virtiofsd: Directory for PID file hardcoded diff --git a/results/classifier/deepseek-2-tmp/output/files/398 b/results/classifier/deepseek-2-tmp/output/files/398 new file mode 100644 index 000000000..c6d7e198a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/398 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 could not open 'ubuntu-16.04-server-cloudimg-arm64-uefi1.img' qemu6.0 on windows 10 diff --git a/results/classifier/deepseek-2-tmp/output/files/408 b/results/classifier/deepseek-2-tmp/output/files/408 new file mode 100644 index 000000000..c812dce00 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/408 @@ -0,0 +1,2 @@ + +DLLs not installing on 32bit version diff --git a/results/classifier/deepseek-2-tmp/output/files/409 b/results/classifier/deepseek-2-tmp/output/files/409 new file mode 100644 index 000000000..96eb4e3cc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/409 @@ -0,0 +1,2 @@ + +tar can only read 4096 bytes from some files on 9p diff --git a/results/classifier/deepseek-2-tmp/output/files/418 b/results/classifier/deepseek-2-tmp/output/files/418 new file mode 100644 index 000000000..1267866d8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/418 @@ -0,0 +1,2 @@ + +qemu-img commit on Windows 10 fails diff --git a/results/classifier/deepseek-2-tmp/output/files/441 b/results/classifier/deepseek-2-tmp/output/files/441 new file mode 100644 index 000000000..d8486856a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/441 @@ -0,0 +1,2 @@ + +qemu-img: "Could not open backing image to determine size" when backing image is encrypted diff --git a/results/classifier/deepseek-2-tmp/output/files/473 b/results/classifier/deepseek-2-tmp/output/files/473 new file mode 100644 index 000000000..5a592e61b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/473 @@ -0,0 +1,2 @@ + +QEMU 6.0.0 - NSIS installer script issues diff --git a/results/classifier/deepseek-2-tmp/output/files/498523 b/results/classifier/deepseek-2-tmp/output/files/498523 new file mode 100644 index 000000000..3890f9c80 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/498523 @@ -0,0 +1,8 @@ + +Add on-line write compression support to qcow2 + +This is a wishlist item. Launchpad really need a way for the submitter to indicate this. + +It would be really cool if qemu were to support disk compression on-line for writes. + +I know this wouldn't be really easy. Although most OS's use blocks, you can really only count on being able to compress 512-byte sectors, which doesn't give much room for a good compression ratio. Moreover, the index indicating where in the image file each sector is located would be complex to manage, since the compressed blocks would be variable sized, and you'd be wanting to do some kind of best-fit allocation of space in the image file. (If you were to make the image file compressed block size granularity, say, 64 bytes, you could probably do this best fit O(1).) If you were to buffer enough writes, you could group arbitrary sequences of written sectors into blocks to compress (which with writeback could be sent to a helper thread on another CPU, so the throughput would be good). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/520 b/results/classifier/deepseek-2-tmp/output/files/520 new file mode 100644 index 000000000..df05dffe8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/520 @@ -0,0 +1,34 @@ + +qemu-ga fsfreeze crashes the kernel +Description of problem: +Hello, + +Still required your attention, duplicate from: +https://bugs.launchpad.net/bugs/1807073 +https://bugs.launchpad.net/bugs/1813045 + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +Moreover, a lot of Proxmox users are complaining about the issue as well: +https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/ +https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/ +Steps to reproduce: +1. Manually start backup for the VM with qemu-agent enabled. +2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command" +3. The VM become unavailable, you can only unlock it and force reset. +Additional information: +/var/log/messages logs: +Aug 6 21:54:00 cpanel qemu-ga: info: guest-ping called +Aug 6 21:54:01 cpanel qemu-ga: info: guest-fsfreeze called +Aug 6 21:54:01 cpanel qemu-ga: info: executing fsfreeze hook with arg 'freeze' + + +after this the VM becomes completely unavailable. diff --git a/results/classifier/deepseek-2-tmp/output/files/527 b/results/classifier/deepseek-2-tmp/output/files/527 new file mode 100644 index 000000000..cd0469d28 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/527 @@ -0,0 +1,2 @@ + +Plain text files in docs/ should be converted to rst diff --git a/results/classifier/deepseek-2-tmp/output/files/567376 b/results/classifier/deepseek-2-tmp/output/files/567376 new file mode 100644 index 000000000..c759dbc2e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/567376 @@ -0,0 +1,7 @@ + +qemu-img fails to convert image + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 built locally, when I run the following commands, a dialog is displayed indicating that "qemu-img.exe has encountered a problem and needs to close". + + qemu-img create foo.img 1G + qemu-img convert -O qcow2 foo.img bar.img \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/567380 b/results/classifier/deepseek-2-tmp/output/files/567380 new file mode 100644 index 000000000..941295094 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/567380 @@ -0,0 +1,6 @@ + +qemu-img fails to create images >= 4G + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. + + qemu-img create foo.img 4G \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/588803 b/results/classifier/deepseek-2-tmp/output/files/588803 new file mode 100644 index 000000000..b7c1b4058 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/588803 @@ -0,0 +1,72 @@ + +Image corruption during snapshot creation/deletion + +Hello, + +The creation/deletion of snapshots sometimes crashes and corrupts the VM image and provoke a segmentation fault in "strcmp", called from "bdrv_snapshot_find". + +Here is a patch that temporarily fixes that (it fixes the segfault but not its reason) : + +--- qemu-kvm-0.12.2-old/savevm.c 2010-01-18 19:48:25.000000000 +0100 ++++ qemu-kvm-0.12.2/savevm.c 2010-02-12 13:45:07.225644169 +0100 +@@ -1624,6 +1624,7 @@ + int nb_sns, i, ret; + + ret = -ENOENT; ++ if (!name) return ret; + nb_sns = bdrv_snapshot_list(bs, &sn_tab); + if (nb_sns < 0) + return ret; +@@ -1649,6 +1650,8 @@ + QEMUSnapshotInfo sn1, *snapshot = &sn1; + int ret; + ++ if (!name) return 0; ++ + QTAILQ_FOREACH(dinfo, &drives, next) { + bs = dinfo->bdrv; + if (bdrv_can_snapshot(bs) && +@@ -1777,6 +1780,11 @@ + QTAILQ_FOREACH(dinfo, &drives, next) { + bs1 = dinfo->bdrv; + if (bdrv_has_snapshot(bs1)) { ++ if (!name) { ++ monitor_printf(mon, "Could not find snapshot 'NULL' on " ++ "device '%s'\n", ++ bdrv_get_device_name(bs1)); ++ } + ret = bdrv_snapshot_goto(bs1, name); + if (ret < 0) { + if (bs != bs1) +@@ -1804,6 +1812,11 @@ + } + } + ++ if (!name) { ++ monitor_printf(mon, "VM state name is NULL\n"); ++ return -EINVAL; ++ } ++ + /* Don't even try to load empty VM states */ + ret = bdrv_snapshot_find(bs, &sn, name); + if ((ret >= 0) && (sn.vm_state_size == 0)) +@@ -1840,6 +1853,11 @@ + QTAILQ_FOREACH(dinfo, &drives, next) { + bs1 = dinfo->bdrv; + if (bdrv_has_snapshot(bs1)) { ++ if (!name) { ++ monitor_printf(mon, "Could not find snapshot 'NULL' on " ++ "device '%s'\n", ++ bdrv_get_device_name(bs1)); ++ } + ret = bdrv_snapshot_delete(bs1, name); + if (ret < 0) { + if (ret == -ENOTSUP) + + +The patch is very simple. Some checks on the variable "name" were missing in "savevm.c". + +Regards, + +Nicolas Grandjean +Conix Security \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/660366 b/results/classifier/deepseek-2-tmp/output/files/660366 new file mode 100644 index 000000000..503035074 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/660366 @@ -0,0 +1,20 @@ + +"qemu-img convert -O qcow2 -o backing_file" makes huge images + +$ dd if=/dev/urandom bs=1M of=1.img count=4 +4+0 records in +4+0 records out +4194304 bytes (4,2 MB) copied, 1,0413 s, 4,0 MB/s +$ qemu-img create -f qcow2 -b 1.img 2.img +Formatting '2.img', fmt=qcow2 size=4194304 backing_file='1.img' encryption=off cluster_size=0 +$ qemu-img convert -O qcow2 -o backing_file=1.img 2.img 3.img +$ du -h ?.img +4,1M 1.img +144K 2.img +4,3M 3.img + +The conversion result is bigger then the source! + +It appears that "-o backing_file" is not applied to data (as expected). I.e. all data is put into the resulting image: both from source image and "backing" image. + +Expected behavior is to put only data that is not present in backing_file. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/681613 b/results/classifier/deepseek-2-tmp/output/files/681613 new file mode 100644 index 000000000..6a8cad75c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/681613 @@ -0,0 +1,6 @@ + +Failed to convert vmdk on MacOSX ppc + +qemu-img -O vmdk raw-file.dd vmdk-file.vmdk +will failed with error. +This issue will be occured on all big endian environment. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/682326 b/results/classifier/deepseek-2-tmp/output/files/682326 new file mode 100644 index 000000000..dd9b4dec3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/682326 @@ -0,0 +1,12 @@ + +linux-user/mmap exhaustion + +Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. + +The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. + +Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. + +Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). + +This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/688 b/results/classifier/deepseek-2-tmp/output/files/688 new file mode 100644 index 000000000..6e74f6503 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/688 @@ -0,0 +1,48 @@ + +Shrinking an image with qemu-img does not reduce image file size +Description of problem: +I have a macOS 10.9 VM using a qcow2 image that was 151GB. The image was originally converted from a VMware image with: +``` +qemu-img convert macOS-10.9.vmdk -O qcow2 -o preallocation=falloc macOS-10.9.qcow2 +``` +This resulted in `macOS-10.9.qcow2` being 151GB big: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +After reducing the filesystem size from within macOS to 25GB with DiskUtil, I shut down the VM and resized the image to 30GB with: +``` +qemu-img resize -f qcow2 --shrink macOS-10.9.qcow2 30G +``` +This succeeded. However, the file still consumes 151GB of space: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +Even though `qemu-img info` shows: +``` +$ qemu-img info macOS-10.9.qcow2 +image: macOS-10.9.qcow2 +file format: qcow2 +virtual size: 30 GiB (32212254720 bytes) +disk size: 30 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false +``` +The size inside the VM is also reported as being 30GB. + +The whole point of resizing that image was to free up disk space on the host. But this doesn't seem to be happening. + +My filesystem is ext4. +Steps to reproduce: +1. Create a vmdk image with `qemu-img create -f vmdk test.vmdk 5G` +2. Convert the vmdk image to qcow2 with `qemu-img convert test.vmdk -O qcow2 -o preallocation=falloc test.qcow2` +3. Shrink the new image with `qemu-img resize -f qcow2 --shrink test.qcow2 3G` + +The resulting `test.qcow2` file should be 3GB, but it's not. It's 5GB. diff --git a/results/classifier/deepseek-2-tmp/output/files/726619 b/results/classifier/deepseek-2-tmp/output/files/726619 new file mode 100644 index 000000000..8ff39576b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/726619 @@ -0,0 +1,14 @@ + +loadvm does not load (offline) snapshot anymore + +qemu Version: 0.14.0 +The problem is present in the current code from git master as well. + +Loading a snapshot that was created while qemu was not running (using qemu-img) does not seem to work anymore. + +Using "loadvm <snapshot-id>" in the qemu monitor does not have the desired effect. Not even an error message is displayed. + +I was able to track down the problem (using git bisect) to this commit: +http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a + +After reverting that commit in my local git checkout everything is workin as expected again. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/753 b/results/classifier/deepseek-2-tmp/output/files/753 new file mode 100644 index 000000000..2019720b6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/753 @@ -0,0 +1,2 @@ + +qemu unable to convert file above 2 TB diff --git a/results/classifier/deepseek-2-tmp/output/files/784977 b/results/classifier/deepseek-2-tmp/output/files/784977 new file mode 100644 index 000000000..5829348e0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/784977 @@ -0,0 +1,27 @@ + +qemu-img convert fails to convert, generates a 512byte file output + +I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to convert to VirtualBox .vdi format using qemu, the first stage of extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just generates a 512byte file: + +{quote} +# Disk DescriptorFile +version=1 +CID=36be9761 +parentCID=ffffffff +createType="twoGbMaxExtentSparse" + +# Extent description +RW 4192256 SPARSE "Ubuntu-s001.vmdk" +RW 4192256 SPARSE "Ubuntu-s002.vmdk" +RW 4192256 SPARSE "Ubuntu-s003.vmdk" +RW 4192256 SPARSE "Ubuntu-s004.vmdk" +RW 4192256 SPARSE "Ubuntu-s005.vmdk" +RW 4192256 SPARSE "Ubuntu-s006.vmdk" +RW 4192256 SPARSE "Ubuntu-s007.vmdk" +RW 4192256 SPARSE "Ubuntu-s008.vmdk" +RW 4192256 SPARSE "Ubuntu-s009.vmdk" +RW 4192256 SPARSE "Ubuntu-s010.vmdk" +RW 20480 SPARSE "Ubunt +{quote} + +No stack trace or other output was found. Anything I can add (other than the 20G VM image to reproduce and I'll be happy to provide) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/786440 b/results/classifier/deepseek-2-tmp/output/files/786440 new file mode 100644 index 000000000..6030034e2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/786440 @@ -0,0 +1,4 @@ + +qcow2 double free + +version 0.14.1 when using qcow2 images, after some time, glibc detects a double free or corruption. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/808737 b/results/classifier/deepseek-2-tmp/output/files/808737 new file mode 100644 index 000000000..57388b80b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/808737 @@ -0,0 +1,4 @@ + +No option to load additional binary files from command line in QEMU + +There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/813 b/results/classifier/deepseek-2-tmp/output/files/813 new file mode 100644 index 000000000..cdab1e194 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/813 @@ -0,0 +1,16 @@ + +On windows, preallocation=full qcow2 not creatable, qcow2 not resizable +Description of problem: +Not possible to create a fixed-virtual-disk qcow as one may do on linux. +One sometimes may want to create a fixed size qcow2, as can be done with the fixed variants of VHDX, VMDK, VDI, + +The advantage of a fixed virtual-disk format, such as fixed-VHDX, fixed-VMDK, fixed-VDI is that it keeps the disk-meta-data as a header bundled along with that is essentially a raw image, allowing for seamless tooling and management of virtual-disks + +Workaround use a raw file as diskimage. (see workaround given below) + +To be very general, the implementation of this may need to factor in what underlying operations (fallocate, fallocate_punchhole, truncate, sparse) are supported by what filesystems (NTFS, ExFAT, ext4), choice of filesystem-driver (sometimes the driver may not have yet implemented an underlying operation), and operating systems (Linux/Win), and possible workarounds to achieve the same effect in the absence of underlying-operation. +Steps to reproduce: +1. open command shell +2. run the qemu-img command. In my case, qcow2 file is attempted to be created on a drive with ExFAT filesystem. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/814 b/results/classifier/deepseek-2-tmp/output/files/814 new file mode 100644 index 000000000..063b70638 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/814 @@ -0,0 +1,38 @@ + +On Windows, qcow2 is corrupted on expansion +Description of problem: +On Windows, the qcow2 loses blocks on account of which the filesystem withing is corrupted as data is copied to it, just the same way as in #727 VHDX is corrupted on expansion on both Linux/Windows. + +After filing a bug for WNBD https://github.com/cloudbase/wnbd/issues/63 , I was suggested to try raw and qcow2. In the process I found that qcow2 is also affected. But it is also true that the kernel-5.15.4 ... 5.15.13 series have also been buggy https://bugzilla.kernel.org/show_bug.cgi?id=215460 . +On Linux, qcow2 never showed any signs of corruption. +On Windows, however, qcow2 does corrupt. + +It is possible that, as Linux is so much more efficient at files and disk-IO, the kernel-block-code, qemu-block-code and qemu-qcow2-code do not hit the bug, and so the corruption does not show up as easily in Linux. Windows, being a little slower at this, might be causing the bug to show up in this qcow2 test. Possibly, the issue more likely to show up on slower machines. I am using an 2013-era intel-4rth gen i7-4700mq Haswell machine. + +It is possible that, the resolution for this issue and that for #727 could be the same or very closely related. The bug may not be in qcow2.c or vhdx.c but maybe in the qemu/block subsystem. If the data-block that arrives from the VM-interface/nbd-interface which has to be written to file, but never gets to the virtual-disk code, not allocated and written to, then the data-block is lost. +Steps to reproduce: +1. Prepare virtual-disk1 as empty qcow2. In my-setup, the qcow2 file resides on an 150 GiB ExFAT partition on 512 GiB SSD. I use ExFAT as the ExFAT-filesystem does not have a concept of sparse files, eliminating that factor from troubleshooting. + ```qemu-img.exe create -f qcow2 H:\gkpics01.qcow2 99723771904``` +2. Prepare virtual-disk2 VHDX with synthetic generated data (sgdata). Scriptlets to recreate sgdata are described in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 . In my-setup, the vhdx file resides on an 1 TiB NTFS partition on a 2 TiB HDD. +3. Start qemu with arguments as given above. +4. Inside VM, boot and bringup livecd desktop, close the installer and open a terminal +5. Use gdisk to put an ext4 partition on /dev/sda +6. Put ext4 partition on sda1 ```mkfs.ext4 -L fs_gkpics01 /dev/sda1``` +7. Create mount directories ```mkdir /mnt/a /mnt/b``` +8. Mount the empty partition from virtual-disk-1 ```mount -t ext4 /dev/sda1 /mnt/a``` +9. Mount the sgdata partition from virtual-disk-2 ```mount.ntfs-3g /dev/sdb2 /mnt/b``` or ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +10. Keep a terminal tab open with ```dmesg -w``` running +11. Rsync sgdata ```( sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date )``` +12. Check sha256sum ```( sdate=`date` ; cd /mnt/a/photos001 ; shas256sum -c ./find.CHECKSUM --quiet ; echo $sdate ; date )``` + corruption will show even without needing to unmount-remount or reboot-remount. + +- About 1.4 GiB free-space left on the ext4 partition. +- Compared to #727, The number of files corrupted are less ``` sha256sum: WARNING: 31 computed checksums did not match ``` +- After, VM guest OS warm reboot, a recheck of the sha256sum shows the same 31 files as corrupted +- After, qemu poweroff, restart qemu, VM guest OS cold boot, a recheck of the sha256sum shows the same 31 files as corrupted +- df shows: sda1 has 95271336 1k-blocks, of which 88840860 are used, 1544820 available, 99% used. The numbers don't add up. Either file-blocks are lost in lost-clusters or the ext4-filesystem has a large journal or the file-system-metadata is too large, or the ext4-filesystem has large cluster-size which results in inefficient space usage. +- An ```unmount /dev/sda1 ; fsck -y /dev/sda1 ; mount -t ext4 /dev/sda1 /mnt/a``` did not find any lost clusters. + +The reason I don't think this is a kernel bug, is because the raw-file as virtual-disk-1 doesn't show this issue. Also, it happens regardless of whether sgdata is on ntfs-3g or ntfs3-paragon. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/files/829 b/results/classifier/deepseek-2-tmp/output/files/829 new file mode 100644 index 000000000..d80c5e9c5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/829 @@ -0,0 +1,15 @@ + +user space emulation: openat() seems to defeat sysroot path translation +Description of problem: +It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. + +In particular, the sequence which fails is: +* create a file in `/tmp/`. +* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. +* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. +Steps to reproduce: +1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 +2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) +3. Try to run under `qemu-arm`. + +This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/deepseek-2-tmp/output/files/832 b/results/classifier/deepseek-2-tmp/output/files/832 new file mode 100644 index 000000000..2410f53d7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/832 @@ -0,0 +1,14 @@ + +error "# mkdir('/..../qtest-9p-local-M33XsI') failed: File exists" on every run of 'qos-test' +Description of problem: +``` +$ ./build//tests/qtest/qos-test -h +# mkdir('/home/berrange/src/virt/qemu/qtest-9p-local-qThj5y') failed: File exists +Usage: + ./build//tests/qtest/qos-test [OPTION...] +...snip... +``` + +Notice the error message from 'mkdir()' whic appears every time you run this program. +Steps to reproduce: +1. Run qos-test diff --git a/results/classifier/deepseek-2-tmp/output/files/848 b/results/classifier/deepseek-2-tmp/output/files/848 new file mode 100644 index 000000000..802ac27ad --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/848 @@ -0,0 +1,49 @@ + +`checkinstall` on Devuan Chimaera (equiv to Debian Bullseye) fails with `FileNotFoundError:` +Description of problem: +Configure and compile work without errors, but `checkinstall` fails with following error. + +``` +Installing with make install... + +========================= Installation results =========================== +changing dir to build for make "install"... +make[1]: Entering directory '/root/go/src/github.com/qemu/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/20] Generating qemu-version.h with a meson_exe.py custom command +[1/2] Installing files. +Traceback (most recent call last): + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/mesonmain.py", line 140, in run + return options.run_func(options) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 544, in run + installer.do_install(datafilename) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 362, in do_install + self.install_targets(d) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 472, in install_targets + file_copied = self.do_copyfile(fname, outname, makedirs=(d.dirmaker, outdir)) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 277, in do_copyfile + shutil.copystat(from_file, to_file) + File "/usr/lib/python3.9/shutil.py", line 375, in copystat + lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns), +FileNotFoundError: [Errno 2] No such file or directory +Installing subdir /root/go/src/github.com/qemu/qemu/qga/run to /usr/local/var/run +Installing trace/trace-events-all to /usr/local/share/qemu +FAILED: meson-install +/usr/bin/python3 /root/go/src/github.com/qemu/qemu/meson/meson.py install --no-rebuild +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:156: run-ninja] Error 1 +make[1]: Leaving directory '/root/go/src/github.com/qemu/qemu/build' +make: *** [GNUmakefile:11: install] Error 2 + +**** Installation failed. Aborting package creation. + +Cleaning up...OK + +Bye. + +``` +Additional information: +- All packages from [requirements](https://wiki.qemu.org/Hosts/Linux#Fedora_Linux_.2F_Debian_GNU_Linux_.2F_Ubuntu_Linux_.2F_Linux_Mint_distributions) installed. +- command `utime` is available from `atfs` package + +I believe error may be related to the `from_file`/`to_file`in: `meson/mesonbuild/minstall.py` line 277. diff --git a/results/classifier/deepseek-2-tmp/output/files/888150 b/results/classifier/deepseek-2-tmp/output/files/888150 new file mode 100644 index 000000000..7571c2e38 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/888150 @@ -0,0 +1,12 @@ + +qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions + +Hi guys, here I am, reporting yet another issue with qemu. This time, it's something that was first reported in January, and Juan proposed a patch for it: + +http://comments.gmane.org/gmane.comp.emulators.qemu/89009 + +[PATCH 4/5] Reopen files after migration + +The symptom is, when running disk stress or any intense IO operation in guest while migrating it causes a qcow2 corruption. We've seen this consistently on the daily test jobs, both for qemu and qemu-kvm. The test that triggers it is autotest stress test running on a VM with ping-pong background migration. + +The fix proposed by Juan is on our RHEL branch and such a problem does not happen on the RHEL branch. So, what about re-considering Juan's patch, or maybe work out a solution that is satisfactory for the upstream maintainers? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/897193 b/results/classifier/deepseek-2-tmp/output/files/897193 new file mode 100644 index 000000000..3f0407993 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/897193 @@ -0,0 +1,44 @@ + +virtfs: kernel compile fails + +I am trying to compile a kernel under virtfs, and am getting an error. The error does not occur when compiling outside of the virtfs mount. + +Both guest and host are running the 3.0.4 kernel. +QEMU is latest from git: bc75c9e50d308b2ec6623a40179c5cdc84b63dae + +QEMU command line: +/usr/local/bin/qemu-system-x86_64 -nographic -boot c -m 1024 -machine type=pc,accel=kvm -drive file=/root/hdd1.img,if=virtio -drive file=/root/test1.img,if=virtio -drive file=/root/test2.img,if=virtio -virtfs local,path=/mnt/virtfs,security_model=none,mount_tag=virtfs -net nic,model=virtio,macaddr=DE:AD:BE:EF:AA:BB -net tap,ifname=qtap0,script=no + +virtfs line in /etc/fstab: +virtfs /mnt/virtfs 9p defaults,noauto,trans=virtio 0 0 + +Steps to reproduce and output: + +[root@guest linux-3.0.4]# make mrproper + CLEAN scripts/basic + CLEAN scripts/kconfig + CLEAN include/config include/generated + CLEAN .config .config.old +[root@guest linux-3.0.4]# make defconfig + HOSTCC scripts/basic/fixdep + HOSTCC scripts/kconfig/conf.o + SHIPPED scripts/kconfig/zconf.tab.c + SHIPPED scripts/kconfig/lex.zconf.c + SHIPPED scripts/kconfig/zconf.hash.c + HOSTCC scripts/kconfig/zconf.tab.o + HOSTLD scripts/kconfig/conf +*** Default configuration is based on 'x86_64_defconfig' +# +# configuration written to .config +# +[root@guest linux-3.0.4]# make +scripts/kconfig/conf --silentoldconfig Kconfig + +*** Error during update of the configuration. + +make[2]: *** [silentoldconfig] Error 1 +make[1]: *** [silentoldconfig] Error 2 +make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. + + +Please let me know if you need any other information. Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/905095 b/results/classifier/deepseek-2-tmp/output/files/905095 new file mode 100644 index 000000000..0568aadf5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/905095 @@ -0,0 +1,61 @@ + +qemu-img can't convert vmdk file: Operation not permitted + +There is no reason why the vdmk image can't be converted. Even running it as root does not help. + +$ ls -lh +insgesamt 60G +-rw-rw-rw- 1 root root 479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk + +$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine: +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument + +Runnung raw images works perfectly for me. + +Hint: i have a symlink set: +/var/lib/libvirt$ ls -lh +insgesamt 12K +drwxr-xr-x 2 root root 4,0K 2011-07-26 14:30 boot +lrwxrwxrwx 1 root root 9 2011-08-19 10:47 images -> /home/vms +drwxr-xr-x 2 root root 4,0K 2011-08-19 09:38 network +drwxr-xr-x 5 libvirt-qemu kvm 4,0K 2011-12-16 04:34 qemu + +but this should not be the reason hopefully + +ProblemType: Bug +DistroRelease: Ubuntu 11.04 +Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4 +ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8 +Uname: Linux 2.6.38-13-generic x86_64 +Architecture: amd64 +CheckboxSubmission: 8f12e98536291f59719792d89958b124 +CheckboxSystem: d00f84de8a555815fa1c4660280da308 +Date: Fri Dec 16 04:24:10 2011 +InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Dell Inc. Latitude E5510 +ProcEnviron: + LANGUAGE=de_DE:en + PATH=(custom, user) + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago) +dmi.bios.date: 09/08/2011 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: A11 +dmi.board.name: 023HKR +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 9 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr: +dmi.product.name: Latitude E5510 +dmi.product.version: 0001 +dmi.sys.vendor: Dell Inc. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/917824 b/results/classifier/deepseek-2-tmp/output/files/917824 new file mode 100644 index 000000000..0da0ed635 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/917824 @@ -0,0 +1,17 @@ + +qemu loops/hangs on extending qcow2-diskspace + +system is ubuntu 11-10 with qemu-kvm 0.14.1 (standard dpkg) + +while trying to install a software in a winXP-guest on a nearly empty disk within a qcow2-file, qemu stops answering console and vnc. + +gdb on original binary shows, that it doesn't really hang, but seems to endless loop + +recompiling the binary with debugging-symbols shows following problem: + +in block/qcow2-cluster.c:777 there's a loop over an allocation-list, but instead of stopping somewhere, the "next" points to the current one. + QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { ... } + +because I'm not firm with qemu-development, I don't know, which behaviour would be correct, but simply break this loop doesn't seem to work: a few moments later the process is again at this point (tried so by setting the register for comparison to 0) + +this situation is continuosly reproducible, but it always take at least 10-15min to get there, so please, if you have suggestion which I should try and report, try to give as much suggestions as possible in one action. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/files/944 b/results/classifier/deepseek-2-tmp/output/files/944 new file mode 100644 index 000000000..42ec2ca23 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/944 @@ -0,0 +1,29 @@ + +9p virtfs issue under MacOS in 7.0.0-rc1 +Description of problem: +9p virtfs under MacOS has an issue with sed inline replacements (sed -i). +The issue somewhere in xattr I believe +Steps to reproduce: +1. /Users/sid/ is mounted via 9p virtfs from MacOS host +2. +``` +[core@localhost ~]$ sed -i 's/aaa/zzz/g' /Users/sid/q/123 +sed: preserving permissions for ‘/Users/sid/q/sed3MLMjp’: Protocol not supported +``` +Additional information: +strace part with error +``` +openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", O_RDWR|O_CLOEXEC) = 5 +write(5, NULL, 0) = 0 +close(5) = 0 +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +read(3, "qqq\nzzz\nsss\n", 8192) = 12 +newfstatat(4, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0 +read(3, "", 8192) = 0 +fchown(4, 501, 1000) = 0 +fgetxattr(3, "system.posix_acl_access", 0x7ffd6dbd18b0, 132) = -1 ENODATA (No data available) +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fchmod(4, 0100644) = 0 +``` diff --git a/results/classifier/deepseek-2-tmp/output/files/991 b/results/classifier/deepseek-2-tmp/output/files/991 new file mode 100644 index 000000000..101db2fe3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/991 @@ -0,0 +1,7 @@ + +Failed to get write lock on qcow2 image from a sigkilled vm +Additional information: +That feature will solve an issue i have with qemu that i muself created +by sending a `kill -9` to a qemu VM after it stopped accepting vnc connections. +I can't use the same qcow2 image currently. Maybe a reboot will fix it, but i did +check `lslocks` and there was no lock on it there. |