diff options
Diffstat (limited to 'results/classifier/deepseek-1/output/files')
25 files changed, 0 insertions, 1161 deletions
diff --git a/results/classifier/deepseek-1/output/files/1093360 b/results/classifier/deepseek-1/output/files/1093360 deleted file mode 100644 index 3dbc9376f..000000000 --- a/results/classifier/deepseek-1/output/files/1093360 +++ /dev/null @@ -1,19 +0,0 @@ - -files on microsoft iso images mounted to qemu VM get stripped from Version info. E.G. Microsoft UAG installation fails - -QEMU 0.9.0-0.14.1 -KVM 60-88-0.14.1 -there is a reference for a root cause, why installation of Microsoft UAG fails. -http://blogs.technet.com/b/isablog/archive/2010/07/13/another-tmg-2010-installation-failure-with-error-0x80070643.aspx - -when checking available information on the mounted UAG ISO in my qemu machine, I realized simliar reduced information. -this was found: -using AQEMU 0.8.2 of 2011.07.27 - -using QEMU 0.9.0-0.14.1 and KVM 60-88-0.14.1 -in an KVM managed machine - -Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1253465 b/results/classifier/deepseek-1/output/files/1253465 deleted file mode 100644 index 9c502b2b1..000000000 --- a/results/classifier/deepseek-1/output/files/1253465 +++ /dev/null @@ -1,62 +0,0 @@ - -qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 - -qemu-img convert in.vmdk -O RAW out.img - -Fails with: -qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 - -qemu-img version 1.6.1 - -On Wed, Nov 20, 2013 at 11:00:14PM -0000, adrelanos wrote: -> qemu-img convert in.vmdk -O RAW out.img -> -> Fails with: -> qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 -> -> qemu-img version 1.6.1 - -This is a known issue. VMware has not released the file format -specification for VMDK version 3. At this point the information needed -to implement version 3 support is not publicly available. - -If you are aware of open source software which already supports version -3, please let us know! - -Fam: Do you have instructions for exporting version 2 images from -VMware? - -Stefan - - -> If you are aware of open source software which already supports version 3, please let us know! - -VirtualBox can. - -- VirtualBox uses VMDK version 3 disks. -- When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. -- VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') - -Does that help? - - -On Sat, 01/07 21:36, Patrick Schleizer wrote: -> > If you are aware of open source software which already supports -> version 3, please let us know! -> -> VirtualBox can. -> -> - VirtualBox uses VMDK version 3 disks. -> - When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. -> - VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') -> -> Does that help? - -Can you try again with QEMU 2.8? Recent versions of QEMU should be able to -handle version 3 VMDK disks. - -Fam - - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1349972 b/results/classifier/deepseek-1/output/files/1349972 deleted file mode 100644 index 9f3089b34..000000000 --- a/results/classifier/deepseek-1/output/files/1349972 +++ /dev/null @@ -1,41 +0,0 @@ - - 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 - - - -FWIW: - -While trying to restore (apply) a snapshot on a Windows VM (ie: qemu-img snapshot -a snapshotname windows.qcow2 where the image file is 150gb in size,) I got the above error: - -qemu-img: /build/buildd/qemu-2.0.0+dfsg/block/qcow2-refcount.c:467: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. - -(My VM is now broken.) - -This is the only reference that I found using Google. - -HTH - -I sent a patch that fixes the original problem that Maria reported. It's hard to say whether this is the same problem as you saw, Sam, but it's quite possible. - -Fix has been included here: -http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ecbda7a22576591a84 -... so I think it should be OK now to mark this ticket as fixed. - diff --git a/results/classifier/deepseek-1/output/files/1450891 b/results/classifier/deepseek-1/output/files/1450891 deleted file mode 100644 index cfada6236..000000000 --- a/results/classifier/deepseek-1/output/files/1450891 +++ /dev/null @@ -1,32 +0,0 @@ - -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 - -We can't just reopen files, we don't know what state they are in. Any data that has been written to the image between the last flush and the point where gluster made the fd invalid may be there or may be missing. If any data is missing, we can't continue the guest or you'll get data corruption. - -The correct fix for resuming after I/O errors is on gluster. As long as it invalidates the fd, without a way to resume, there is no way for qemu to correctly continue after an error. - -Hi Kevin, - -I understand. In this case (where the gluster process was killed or crashed) I guess the best option would be to poweroff and restart the VM, which can be done client-side (ovirt + libvirt) - -Please mark as "Won't fix". - -Thanks. - -Marking as "Won't Fix" according to the last comment. - diff --git a/results/classifier/deepseek-1/output/files/1452062 b/results/classifier/deepseek-1/output/files/1452062 deleted file mode 100644 index 7a519f6e8..000000000 --- a/results/classifier/deepseek-1/output/files/1452062 +++ /dev/null @@ -1,46 +0,0 @@ - -qemu-img will fail to convert images in 2.3.0 - -Hello guys, - - There seems to be a bug in qemu-img with 2.3.0 that wasn't there in 2.2.1 .... qemu convert will always fail converting. See the output below: - - -Started by upstream project "Create windows image" build number 73 -originally caused by: - Started by user anonymous -Building remotely on builder (builder lab) in workspace /var/lib/jenkins/remote/workspace/Prepare windows Image -[Prepare WS2008R2 Image] $ /bin/sh -xe /tmp/hudson4138890034689910617.sh -+ sudo bash -x /var/images/prepare_windows.sh WS2008R2 -+ set +x - -Preparing: windows -Virtio CD: virtio-win-0.1.96.iso - -Sparsifying... -qemu-img: error while compressing sector 11131648: Input/output error -virt-sparsify: error: external command failed: qemu-img convert -f -qcow2 -O 'qcow2' -c -o 'compat=0.10' '/tmp/sparsifyb459a0.qcow2' -'/var/images/generated/WS2008R2.qcow2' - -virt-sparsify: If reporting bugs, run virt-sparsify with debugging -enabled (-v) and include the complete output. -Build step 'Execute shell' marked build as failure -Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered -Finished: FAILURE - -Thanks, -Dave - -I can't reproduce this. qemu-img convert works just fine here. - -qemu-img convert -f qcow2 -O qcow2 -c -o compat=0.10 x.img y.img - -(from a random winXP guest image). - -The only possibly relevant change I can see in 2.3 is that the qcow2 driver added an additional error check to a truncate operation. Can you please run qemu-img under strace -f and either provide the output as an attachment or paste the relevant failing call(s) if you can recognise them? - -I rolled back QEMU to 2.2.1 and it succeeded converting the image ... I'll try to see if I can re-upgrade QEMU without breaking again the CI we have here. - -This problem is fixed with commit 3e5feb62 ("qcow2: Handle EAGAIN returned from update_refcount"), which will be included in qemu 2.4.0. - diff --git a/results/classifier/deepseek-1/output/files/1481654 b/results/classifier/deepseek-1/output/files/1481654 deleted file mode 100644 index b2ff63995..000000000 --- a/results/classifier/deepseek-1/output/files/1481654 +++ /dev/null @@ -1,42 +0,0 @@ - -libcacard.pc paths are not modified when configure prefix is - -Ubuntu Server 15.04 Gnome -Qemu sources from master git://git.qemu-project.org/qemu.git 2.4.0-rc3 SHA 2be4f242 - -Built with: -make distclean -./configure --target-list=x86_64-softmmu \ - --cpu=x86_64 \ - --enable-virtfs \ - --enable-kvm \ - --enable-spice \ - --enable-usb-redir \ - --enable-libusb \ - --audio-drv-list=oss,alsa,sdl,pa \ - --enable-uuid \ - --enable-libnfs \ - --enable-libssh2 \ - --prefix=/usr --sysconfdir=/etc --localstatedir=/var - -make -j6 - -Yet, /usr/lib/libcacard.pc: -prefix=/usr/local -exec_prefix=${prefix} -libdir=/usr/local/lib -includedir=/usr/local/include/cacard - -Name: cacard -Description: CA Card library -Version: 2.3.50 - -Requires.private: nss glib-2.0 -Libs: -L${libdir} -lcacard -Libs.private: -Cflags: -I${includedir} - -This issue affects the building of spice-client-gtk (http://cgit.freedesktop.org/spice/spice-gtk/) which expects correct paths in that file. - -Since QEMU 2.5, libcacard is now an external project (see http://www.spice-space.org/page/Libcacard), so this should not be a problem anymore. - diff --git a/results/classifier/deepseek-1/output/files/1563931 b/results/classifier/deepseek-1/output/files/1563931 deleted file mode 100644 index 314e055c6..000000000 --- a/results/classifier/deepseek-1/output/files/1563931 +++ /dev/null @@ -1,23 +0,0 @@ - -qemu-img should allow resizing image with snapshots - -Currently it's not possible to resize a disk image with qemu-img if image in question has snapshots associated. I'm not entirely sure this is technically possible but if it is, it would be really nice to support that. - -$ qemu-img --version -qemu-img version 2.4.1 (qemu-2.4.1-8.fc23), Copyright (c) 2004-2008 Fabrice Bellard - -The QEMU project is currently considering to move its bug tracking to -another system. For this we need to know which bugs are still valid -and which could be closed already. Thus we are setting older bugs to -"Incomplete" now. - -If you still think this bug report here is valid, then please switch -the state back to "New" within the next 60 days, otherwise this report -will be marked as "Expired". Or please mark it as "Fix Released" if -the problem has been solved with a newer version of QEMU already. - -Thank you and sorry for the inconvenience. - - -Implemented in 7fa140abf69675b7b83af32de. Note that every internal snapshot has a disk size associated with it, though, so applying a snapshot from when the image had a different size means the image size will be reverted to what it was as the time of the snapshot. - diff --git a/results/classifier/deepseek-1/output/files/1644754 b/results/classifier/deepseek-1/output/files/1644754 deleted file mode 100644 index b7e55e354..000000000 --- a/results/classifier/deepseek-1/output/files/1644754 +++ /dev/null @@ -1,107 +0,0 @@ - -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 - -The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to -"Incomplete" now. -If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. - - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1672365 b/results/classifier/deepseek-1/output/files/1672365 deleted file mode 100644 index 336f867d5..000000000 --- a/results/classifier/deepseek-1/output/files/1672365 +++ /dev/null @@ -1,54 +0,0 @@ - -nested 9pfs read fail - -tl;dr: A virtfs read fails. The init being on this virtfs (mounted by the initrd), the linux kernel guest is unable to boot, and kernel panics. The fact that qemu still takes 100%cpu after the kernel panic makes me think it's a qemu bug. - -Here is the setup (some hashes replaced with "..."): - * A (NixOS) host system, with /nix/store as a btrfs on lvm on cryptsetup - * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store: -``` -exec /nix/store/...-qemu-x86-only-for-vm-tests-2.8.0/bin/qemu-kvm \ - -name test \ - -m 8192 \ - -cpu kvm64 \ - -net nic,vlan=0,model=virtio -net user,vlan=0 \ - -virtfs local,path=/nix/store,security_model=none,mount_tag=store \ - -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=xchg \ - -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=shared \ - -drive index=0,id=drive1,file=/home/ekleog/nixos/test.qcow2,if=virtio,cache=writeback,werror=report \ --kernel /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel \ --initrd /nix/store/...-nixos-system-test-17.09.git.deee8da/initrd \ --append "$(cat /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-test-17.09.git.deee8da/init regInfo=/nix/store/...-reginfo" \ - -vga std -usbdevice tablet -``` - * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store - * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store/...-vm-nginx-store: -``` -/nix/store/...-qemu-2.8.0/bin/qemu-kvm \ - -name nginx -m 128 -smp 2 -cpu kvm64 \ - -nographic -serial unix:"/var/lib/vm/consoles/nginx/socket.unix",server,nowait \ - -drive file="/var/lib/vm/images/nginx.img",if=virtio,media=disk \ - -virtfs local,path="/nix/store/...-vm-nginx-store",security_model=none,mount_tag=store \ - -netdev type=tap,id=net0,ifname=vm-nginx,script=no,dscript=no -device virtio-net-pci,netdev=net0,mac=56:00:00:00:00:01 \ - -kernel /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel \ - -initrd /nix/store/...-nixos-system-nginx-17.09.git.deee8da/initrd \ - -append "$(cat /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-nginx-17.09.git.deee8da/init console=ttyS0 boot.shell_on_fail" \ - -virtfs local,path="/var/lib/vm/persist/nginx/home",security_model=mapped-xattr,mount_tag="shared1" \ - -virtfs local,path="/var/lib",security_model=mapped-xattr,mount_tag="shared2" \ - -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared3" -``` - * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store - * With init in /nix/store - -What happens is that at boot time the inner VM doesn't manage to read the init script after the initrd has mounted the 9pfs and overlayfs. - -What makes me think it's a qemu bug is that htop in the outer VM shows the inner VM's qemu as using 100% cpu, despite the fact the kernel it's running is under kernel panic, thus doing nothing. - -What do you think about this? - -Oh, I forgot to mention: it first worked for some time, then in the middle of a shell session running over a screen /var/lib/vm/consoles/nginx/screen from the outer VM (socat-linked to /var/lib/vm/consoles/nginx/socket.unix to provide a predictable pty link), the 9pfs stopped returning any data, and it didn't go away after a reboot of the inner VM, as it then no longer managed to boot. - -I was unfortunately unable to identify exactly which operation caused the thing to "stop working", but I'd say it is due to zsh's path-full autocompletion in paths including directories with ~700 entries, without being certain of that. - -Hmm, actually it looks like a kernel in kernel panic always takes 100% CPU (just got another unrelated one), so I guess it's not necessarily a qemu bug but can arise from anywhere in the stack. I'm marking the bug as invalid as a consequence. - diff --git a/results/classifier/deepseek-1/output/files/1673957 b/results/classifier/deepseek-1/output/files/1673957 deleted file mode 100644 index 9abe3ed85..000000000 --- a/results/classifier/deepseek-1/output/files/1673957 +++ /dev/null @@ -1,38 +0,0 @@ - -virtfs: mapped-xattr on mount point - -With - -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2" -in the qemu command line, - shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144) -in the guest mount points, and - tmpfs on /tmp type tmpfs (rw,nosuid,nodev) -in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis. - -When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty. - -After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported". - -Do you have a pointer as to what is happening? - -PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case - -The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to -"Incomplete" now. -If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. - - -Independent of the planned tracker transition: this issue would require more information by original reporter anyway. - -From the information provided so far, I cannot reproduce this problem, and the error messages don't look like common misconfigurations on host side like wrong permissions, AppArmor policies or something like that. Especially the error message "Cannnot allocate memory" looks weird to me. So I think there should at least be more details about the host system this was deployed on. - -Hmm… so this dates back quite long ago unfortunately, I had basically forgotten about this bug report as I had opened it while just experimenting with qemu. - -To the best of my recollection, this was happening with a NixOS, either 16.09, 17.03 or unstable, at an update that was probably within 0-2 months of the time I made the bug report. - -Now, I guess the best may be to just close as can't reproduce, as I no longer have the code originally used to trigger the issue anyway? - -Either way, thank you for your feedback! - -Thanks for your answer! ... since this is not reproducible anymore, I'm closing the ticket now. - diff --git a/results/classifier/deepseek-1/output/files/1685526 b/results/classifier/deepseek-1/output/files/1685526 deleted file mode 100644 index 804fc7691..000000000 --- a/results/classifier/deepseek-1/output/files/1685526 +++ /dev/null @@ -1,19 +0,0 @@ - -UEFI firmware can't write to "fake" FAT hard disk - -Using the Tianocore OVMF UEFI firmware, a UEFI application cannot write to the emulated fat disk (-hda fat:rw:path/here). A file will get created or written, but will be corrupted. - -Looking through old bug tickets ... When reporting issues, please provide proper information on the versions that you were using (QEMU, OVMF, ...) and complete information about which command line parameters you used to start QEMU. - -Out of scope; please see my (independent, more recent) replies here: - -[edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk - -https://edk2.groups.io/g/devel/message/66655 -https://edk2.groups.io/g/devel/message/66656 - -(alternative links: -https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00877.html -https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00878.html -) - diff --git a/results/classifier/deepseek-1/output/files/1761153 b/results/classifier/deepseek-1/output/files/1761153 deleted file mode 100644 index 672e27086..000000000 --- a/results/classifier/deepseek-1/output/files/1761153 +++ /dev/null @@ -1,33 +0,0 @@ - -qemu-user incorrect mmap for large files on 64bits host and 32bits executable. - -qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf. - -See attached test program `test_mmap.c`. - -``` -$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap -$ file test_mmap -test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped -$ uname -a -Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux -$ qemu-i386 --version -qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers -$ ./test_mmap -$ qemu-i386 test_mmap -Incorrect data 1 -``` - -Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c) - -The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family. - - - -The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. -If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. - - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1807073 b/results/classifier/deepseek-1/output/files/1807073 deleted file mode 100644 index 1ddd4c1bf..000000000 --- a/results/classifier/deepseek-1/output/files/1807073 +++ /dev/null @@ -1,90 +0,0 @@ - -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 - -Just got almost the same -Ubuntu 16.04 as guest on Centos 7 host, -all will latest updates. - -Execute of -virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-freeze"}' - -failed with agent not available ( or something like this), but fsfreeze executed in OS -Apr 7 02:28:54 inetgw2 qemu-ga: info: guest-fsfreeze called - -snapshot was created -after this -virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-thaw"}' -failed too with agent not available - -So Ubuntu 16.04 VM stuck in freezed i/o state. - qemu-guest-age 1:2.5+dfsg-5 - -Same version... - -Thank you! - -btw,I run OEL7 VM on the same host and Ubuntu 18.04 VM, -both have newer qemu-guest-agent: - -18.04: qemu-guest-age 1:2.11+dfsg- - -OEL7: rpm -qi qemu-guest-agent -Name : qemu-guest-agent -Epoch : 10 -Version : 2.12.0 -Release : 2.el7 - -Never had this problem on both oh these. - - -But it happens in some times， this problem dose not occur 100 percent。I can not reproduce when I want to find WHY。So it‘s dangerous in my production environment。 - -I have a problem with fsfreeze that looks very similar to this, though I'm of course not 100% sure it's the same. - -When I try to snapshot one server, fsfreeze-freeze hangs, and after having timeout'ed the qemu agent has crashed: - -# qm guest cmd 105 fsfreeze-status -thawed -# qm guest cmd 105 fsfreeze-freeze -^C << hangs, having to break out of the command -# qm guest cmd 105 fsfreeze-status -QEMU guest agent is not running -# qm reset 105 --skiplock -# qm guest cmd 105 fsfreeze-status -thawed - -Host is Proxmox 5, VM is Centos 7 with Cpanel. This happens every time I try to snapshot the server. Other VM's on the host freeze fine without problem. - -I don't find anything interesting under /var/log. Please let me know if there is anything I can do to help debug this problem. - - - -The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. -If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. - -[Expired for QEMU because there has been no activity for 60 days.] - -Re-opened in the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues/520 - diff --git a/results/classifier/deepseek-1/output/files/1811711 b/results/classifier/deepseek-1/output/files/1811711 deleted file mode 100644 index 3227b822c..000000000 --- a/results/classifier/deepseek-1/output/files/1811711 +++ /dev/null @@ -1,89 +0,0 @@ - -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. - - - -Hi, - -What exactly is the issue? All of that looks rather OK to me. - -Max - -This bug was related to an IRC discussion on Jan 14th but this bug description is not showing the problem that was raised on IRC. The IRC discussion showed a source image with a 9GB Windows 10 installation, turning into an image with only 8 MB of data present. The images in this bug description don't have any data written so are not illustrating the data conversion issue. - - -The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. -If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1833871 b/results/classifier/deepseek-1/output/files/1833871 deleted file mode 100644 index 3006bbcd5..000000000 --- a/results/classifier/deepseek-1/output/files/1833871 +++ /dev/null @@ -1,22 +0,0 @@ - -qemu-img convert file.vmdk: Invalid footer - -Steps to reproduce -- Open ESXi 6.5 Web UI -- Export OVF -- qemu-img convert disk.vmdk disk.qcow2 - -Error: - - qemu-img: Could not open './disk-1.vmdk': Invalid footer - -I found another person having this problem here: -https://forum.proxmox.com/threads/error-converting-vmdk-file-to-qcow2-file.38264/ -As I guess from the answer, the guy went over to manually copy the flat file from the datastore instead of using the ovf-exported file. - -Nevertheless, I think this bug should be investigated further and closed. Probably it is just some metadata issue and should not be too hard to fix once the root of the problem is found. - -I just compiled the version in the master branch and the same error occurred. - -Probably my image was corrupt since it works with another image. So this bug can be closed. - diff --git a/results/classifier/deepseek-1/output/files/1840865 b/results/classifier/deepseek-1/output/files/1840865 deleted file mode 100644 index 08af90b02..000000000 --- a/results/classifier/deepseek-1/output/files/1840865 +++ /dev/null @@ -1,45 +0,0 @@ - -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*. - - -This is an automated cleanup. This bug report has been moved to QEMU's -new bug tracker on gitlab.com and thus gets marked as 'expired' now. -Please continue with the discussion here: - - https://gitlab.com/qemu-project/qemu/-/issues/181 - - diff --git a/results/classifier/deepseek-1/output/files/1879998 b/results/classifier/deepseek-1/output/files/1879998 deleted file mode 100644 index 5d60613da..000000000 --- a/results/classifier/deepseek-1/output/files/1879998 +++ /dev/null @@ -1,35 +0,0 @@ - -Bad check for return value of mmap() - -In -./roms/skiboot/extract-gcov.c -there is this code: - - addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); - assert(addr != NULL); - -This check is wrong, mmap never returns NULL, on errors it returns MAP_FAILED (or -1). (Also sidenote: asserts usually shouldn't be used for error checking.) - -In -roms/skiboot/libstb/print-container.c -there's a similar issue: - - payload = mmap(NULL, payload_st.st_size - SECURE_BOOT_HEADERS_SIZE, - PROT_READ, MAP_PRIVATE, fdin, SECURE_BOOT_HEADERS_SIZE); - if (!payload) - -This if should be (payload == MAP_FAILED). - -Another one is in -./roms/skiboot/libstb/create-container.c - -And in -./roms/u-boot/tools/aisimage.c -there's an mmap call that does not check the return value at all. - -skiboot is a separate project, we do not manage its code in the QEMU project, but just include the source code in our release tarballs since we ship the skiboot binary with QEMU. Please report these problems to the skiboot project instead: - - https://github.com/open-power/skiboot - -And concerning the mmap in roms/u-boot/, please report that issue to the U-Boot project instead: https://www.denx.de/wiki/U-Boot/ - diff --git a/results/classifier/deepseek-1/output/files/1883083 b/results/classifier/deepseek-1/output/files/1883083 deleted file mode 100644 index d87e295d8..000000000 --- a/results/classifier/deepseek-1/output/files/1883083 +++ /dev/null @@ -1,53 +0,0 @@ - -QEMU: block/vvfat driver issues - -Nathan Huckleberry <email address hidden> has reported following issues in the block/vvfat driver for the virtual VFAT file system image, used to share a host system directory with a guest VM. - -Please note: - -> https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images - -Virtual VFAT read/write support is available only for (beta) testing purposes. - -Following issues are reproducible with: - - host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \ - -drive file=fat:rw:/tmp/var/run/,index=2 -m 2048 /var/lib/libvirt/images/f27vm.qcow2 - - guest)# mount -t vfat /dev/sdb1 /mnt/ - -The attached reproducers (run inside a guest) include: - -1. dir.sh: - directory traversal on the host - - It creates a file under /mnt/yyyy - - Then edits the VFAT directory entry to make it -> /mnt/../y - - The handle_renames_and_mkdirs() routine does not check this new file name - and creates a file outside of the shared directory on the host - -2. dos.sh: hits an assertion failure in vvfat driver - - Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/ - - While updating vvfat commits, driver hits an assertion in - handle_renames_and_mkdirs - ... - } else if (commit->action == ACTION_MKDIR) { - ... - assert(j < s->mapping.next); <== it fails - -3. read.sh: reads past vvfat directory entries - - Creates a file with: echo "x" > /mnt/a - - Reads past VVFAT directory entry structure with - - # head -c 1000000 $MNTDEV | xxd | grep x -A 512 - - - It may disclose some heap addresses. - -4. write.sh: heap buffer overflow - - Creates large number of files as /mnt/file[1..35] - - while syncing directory tree with the host, driver hits an overflow - while doing memmove(3) in array_roll() routine - - - -This ticket has been transferred to QEMU's new bug tracker here: -https://gitlab.com/qemu-project/qemu/-/issues/272 -... thus closing the issue on Launchpad now. - diff --git a/results/classifier/deepseek-1/output/files/1884169 b/results/classifier/deepseek-1/output/files/1884169 deleted file mode 100644 index f9e059fbb..000000000 --- a/results/classifier/deepseek-1/output/files/1884169 +++ /dev/null @@ -1,19 +0,0 @@ - -There is no option group 'fsdev' for OSX - -When I try to use -fsoption on OSX I receive this error: - --fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example: There is no option group 'fsdev' - -That's the behaviour on macOS that I would expect ATM. So it's not a bug. - -Your macOS version was compiled without virtfs support, that's why qemu does not even offer you these options. - -Even though 9P is a network protocol, you still need support by host OS and guest OS for some kind of communication channel between host and guest. Currently 9pfs in qemu supports either virtio (Linux KVM host <-> Linux guest) or Xen as communication channel. For macOS so far nobody bothered to implement a communication driver for qemu 9pfs yet. - -But actually OS X (macOS) supports 9pfs and it does have its own AppleVirtIO9PVFS which makes things a bit strange, would not that be a good workaround, to use the AppleVirtIO9PVFS? - -All my best, - -Waheed - diff --git a/results/classifier/deepseek-1/output/files/1888467 b/results/classifier/deepseek-1/output/files/1888467 deleted file mode 100644 index f16dfde7e..000000000 --- a/results/classifier/deepseek-1/output/files/1888467 +++ /dev/null @@ -1,77 +0,0 @@ - -qemu-img http convert bug - -Hello, Why the file sizes of http conversion and local conversion are inconsistent? - -Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 -My image size is 40 G, raw format. - -The source is the same file, but the access method is different -http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） -local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） - -thank you - -Hi, - -What exactly do you mean by “file size”? The file length (as reported by ls -l) or the bytes used on disk (reported as “disk size” by qemu-img, or by du -B1)? - -You say that qcow2 and vmdk are normal – do you mean as input or as output formats? - -One thing that comes to my mind is that from http, we have no way of inquiring about holes in the source file, so we have to scan the file for ranges that are zero, which may not be optimal. OTOH, the default minimum-zero length is 4 kB, which should basically be the granularity at which filesystems can record and report holes, too. -(And if that’s the problem, it should present itself regardless of the output format.) - -Can you paste the output for “qemu-img map” on your source file somewhere (the local one), or is that too long? - -first, what I said "file size" is file length as reported by ls -l?field.comment=first, what I said "file size" is file length as reported by ls -l. - -The following attachment shows the size of the same source file after different conversion methods， - -http -> local: qemu-img convert -f raw -O vdi localfile localfile1 -local -> local: qemu-img convert -f raw -O vdi localfile localfile2 -localfile1's size is different from localfile2 - -secondly, the conversion of qcow2 and vmdk is normal. -http -> local: qemu-img convert -f raw -O qcow2 localfile localfile1 -local -> local: qemu-img convert -f raw -O qcow2 localfile localfile2 -localfile1's size is the same size as localfile2 - -OK, that’s interesting. To be honest, I have no idea. I’ll keep this in mind and I’ll try to play around with it, but I can’t promise anything. - -hello, I have an other question。 -Why does qemu-img support http reader mode but not http writer mode? -think you. - -Because nobody has implemented it so far. - -The QEMU project is currently moving its bug tracking to another system. -For this we need to know which bugs are still valid and which could be -closed already. Thus we are setting the bug state to "Incomplete" now. - -If the bug has already been fixed in the latest upstream version of QEMU, -then please close this ticket as "Fix released". - -If it is not fixed yet and you think that this bug report here is still -valid, then you have two options: - -1) If you already have an account on gitlab.com, please open a new ticket -for this problem in our new tracker here: - - https://gitlab.com/qemu-project/qemu/-/issues - -and then close this ticket here on Launchpad (or let it expire auto- -matically after 60 days). Please mention the URL of this bug ticket on -Launchpad in the new ticket on GitLab. - -2) If you don't have an account on gitlab.com and don't intend to get -one, but still would like to keep this ticket opened, then please switch -the state back to "New" within the next 60 days (otherwise it will get -closed as "Expired"). We will then eventually migrate the ticket auto- -matically to the new system (but you won't be the reporter of the bug -in the new system and thus won't get notified on changes anymore). - -Thank you and sorry for the inconvenience. - - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/1905979 b/results/classifier/deepseek-1/output/files/1905979 deleted file mode 100644 index 63c29d863..000000000 --- a/results/classifier/deepseek-1/output/files/1905979 +++ /dev/null @@ -1,56 +0,0 @@ - -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) - -This is rather serious, since it causes VMs to crash: - -Unexpected error in raw_check_lock_bytes() at /build/qemu-PKI6mj/qemu-4.2/block/file-posix.c:796: -Failed to get "write" lock -2020-11-23 11:32:27.810+0000: shutting down, reason=crashed - -when openstack attempts to create a snapshot. - -In this thread, it is pointed out that support for OFD is provided by the generic VFS layer in the kernel, so there should never be a situation where one filesystem supports OFD and another does not support OFD: - - https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05264.html - -Can you say what filesystem you are using that exhibits the lack of OFD support, and what kernel version - -Interesting. Thanks for the link. - -The file system we are using is the Quobyte file system (2.24.1) (https://www.quobyte.com/), which works via FUSE. -We've had problems with OFD locks with this file system in the past, so my first thought, seeing the error in comment #1, was that those would be to blame. - -But if the OFD locks are not really handled by the file system, I'm not sure how that explains the OFD lock issues we had in the past. I don't suppose this changed in the last year or so. Just now I made a little test program (basically copying qemu_lock_fd_test() and qemu_probe_lock_ops() from qemu) to double-check, and indeed right now it seems that the OFD locks *are* working on the Quobyte file system. Or at least qemu_lock_fd_test() doesn't return an error. - -So now I'm back to square one on diagnosing the observed error. It occurred in an installation of Openstack Ussuri installed on Ubuntu 18.04 Bionic using the Ubuntu Cloud Archive for packaging. The Cloud Archive has backports of the latest Qemu to earlier Ubuntu versions. The exact qemu version was http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/q/qemu/qemu_4.2-3ubuntu6.7~cloud0_amd64.deb . - -Annoyingly I have not been able to locate the git repo from which the Ubuntu Cloud Archive creates its packages (containing the patches and build changes for backports); all I can find is version 4.2-3ubuntu6.7 (without ~cloud0) which is for Ubuntu 20.04 Focal. - -For now we're working around it by downgrading Qemu to the normal Bionic version (2.11+dfsg-1ubuntu7.33) - -You wouldn't happen to know where the Ubuntu Cloud Archive stores exact files it creates its packages from? (I have already asked on stackoverflow without success so far: https://stackoverflow.com/questions/65146846/from-which-git-repos-does-the-ubuntu-cloud-archive-compile-its-packages) - - - -Look in the same directory as that .deb link above - the the files ending in orig.tar.gz (upstream source) and files ending in debian.tar.xz (downstream modifications) - -The kernel version is Linux hostname 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux - -That is indeed the source and patches, but I wanted to follow their git repo for easier maintenance. Surely they must have one. - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/304636 b/results/classifier/deepseek-1/output/files/304636 deleted file mode 100644 index 7181b1e00..000000000 --- a/results/classifier/deepseek-1/output/files/304636 +++ /dev/null @@ -1,91 +0,0 @@ - --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 - -please send your patch to upstream at <email address hidden>, the vvfat code in qemu is fragile and should be carefully reviewed. - -the path ever came? i'm still having this problem, i can't run qemu on windows because in the fat: partition there are files bigger then 500 mb - -Please submit the patch upstream - -Linked against upstream, confirmed and wishlist. Ubuntu should get this when upstream takes the patch. - -Thanks! -:-Dustin - -Thank YOU, dustin! -What's next? I don't understand, should i do something else or i can just wait for the fix? somebody has to send the patch ? -Another thing: why wishlist? this is clearly a bug, and a quite serious one: you just can't give a fat bigger than 500 mb to qemu. i can't use qemu since years, because of this... -Thanks - -Hello. - -I am using qemu-5.2.0 in Windows with operating system Minix 3.1.2a and vfat fail to write files of size over 4096 bytes. The read works well. This is not ploblem of Minix 3.1.2a because in Bochs emulator reads an writes of files of any size works well. - -I also consider this to be a major bug as it prevents communication of information between the guest OS and the host. I have over 300 students complaining about this bug present in qemu. - -Thanks. - - - -Hi Pedro, - -Sorry to hear of your difficulty, but given the age of this bug report, I'd strongly urge you to file a new bug report. Since this was last looked at over 10 years ago, it's extremely likely your issue is completely unrelated to the originally reported one. - -Here are a couple pages on how to write effective bug reports, that I'd encourage reading to ensure your report is actionable and can (hopefully) get resolved expediently: - - * https://help.ubuntu.com/community/ReportingBugs - * https://ubuntu.com/server/docs/reporting-bugs - -A few other tips specific to qemu (per the upstream bug tracker): - - * Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug. Reports against the latest release or even the latest development tree are usually acted upon faster. - * Include the full command line used to launch the QEMU guest. - * Reproduce the problem directly with a QEMU command-line. Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend. - * Include information about the host and guest (operating system, version, 32/64-bit). - - -Pedro, -please also note that vvfat driver is general in a bad state and more or less completely unmaintaind. I can only strongly recommend to *not* use it in production. If you have to share files between guest and host, please use something more modern like virtio-fs (or maybe virtio-9p) instead. - -If you need OS portability then the "usb-mtp" device is also an option for adhoc file sharing. - -This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets now closed in Launchpad. Please continue with the discussion here: - - https://gitlab.com/qemu-project/qemu/-/issues/66 - diff --git a/results/classifier/deepseek-1/output/files/584146 b/results/classifier/deepseek-1/output/files/584146 deleted file mode 100644 index cb57801d7..000000000 --- a/results/classifier/deepseek-1/output/files/584146 +++ /dev/null @@ -1,13 +0,0 @@ - -Virtual fat breaks with -snapshot - -When using fat emulation together with snapshot, qemu fails to find the directory for the fat "filesystem". - -See Debian bug#504049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 and discussion on qemu-devel with Kevin Wolf, http://marc.info/?t=126850802800001 for details. - -There's a workaround for this bug: when using full path for fat:/dir/name it works. - -Can you still reproduce this issue with the latest version of QEMU? If so, could you please provide a proper command line that triggers this problem? - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/597575 b/results/classifier/deepseek-1/output/files/597575 deleted file mode 100644 index 3ed17955f..000000000 --- a/results/classifier/deepseek-1/output/files/597575 +++ /dev/null @@ -1,38 +0,0 @@ - -Hangs on HTTP errors when using the curl block driver - -Hi, - -It seems that qemu-kvm does not handle HTTP errors gracefully when using the curl block driver and a synchronous request is made (i.e. one using bdrv_read_em() for example). In these cases, if an HTTP error (such as 404 or 416) is returned, the aio thread exits but the main thread never finishes waiting for I/O completion, thus freezing KVM. - -Versions affected: -At least 0.11.1 and 0.12.4 were tested and found to be affected. - -How to reproduce: -Simply specify a non-existing path for an HTTP URL as a CDROM drive. -kvm -drive file=test.img,format=qcow2,if=ide,index=0,boot=on -drive file=http://127.0.0.1/static/test1.iso,media=cdrom,index=2,if=ide -boot c - -qemu-kvm will hang on boot using 100% cpu as it will try to open the block device. At that point, the backtrace is (qemu-kvm-0.12.4): - -#0 0x000000000047aaaf in qemu_aio_wait () at aio.c:163 -#1 0x000000000047a055 in bdrv_read_em (bs=0x1592320, sector_num=0, buf=0x7fffcf7e9ae0 "¨\237~Ïÿ\177", nb_sectors=4) - at block.c:1939 -#2 0x0000000000479c0e in bdrv_pread (bs=0x1592320, offset=<value optimized out>, buf=0x7fffcf7e9ae0, count1=2048) - at block.c:716 -#3 0x000000000047a862 in bdrv_open2 (bs=0x1591a30, filename=0x1559f00 "http://127.0.0.1/static/test1.iso", - flags=0, drv=0x84eca0) at block.c:316 -#4 0x000000000040dcb4 in drive_init (opts=0x1559e60, opaque=<value optimized out>, fatal_error=0x7fffcf7ea494) - at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2471 -#5 0x000000000040e086 in drive_init_func (opts=0x155db00, opaque=0x0) - at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2488 -#6 0x0000000000475421 in qemu_opts_foreach (list=<value optimized out>, func=0x40e070 <drive_init_func>, - opaque=0x8495e0, abort_on_failure=12) at qemu-option.c:817 -#7 0x000000000040e9af in main (argc=7, argv=0x7fffcf7ea838, envp=<value optimized out>) - at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:6011 - -Thanks - -QEMU 0.11 / 0.12 are pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU? - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/deepseek-1/output/files/888150 b/results/classifier/deepseek-1/output/files/888150 deleted file mode 100644 index a459bfd37..000000000 --- a/results/classifier/deepseek-1/output/files/888150 +++ /dev/null @@ -1,17 +0,0 @@ - -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? - -The URL that you've mentioned in the description is not valid anymore ... can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? - -[Expired for QEMU because there has been no activity for 60 days.] - |