diff options
Diffstat (limited to 'results/classifier/gemma3:12b/files')
459 files changed, 13416 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/files/1005 b/results/classifier/gemma3:12b/files/1005 new file mode 100644 index 00000000..d81f992f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1005 @@ -0,0 +1,178 @@ + +blockdev-del doesn't work after blockdev-backup with incremental, which using dirty-bitmap +Description of problem: +After incremental backup with bitmap, blockdev-del doesn't work at target node. +Because of this, incremental backup cannot rebase to base node. +I refered this. https://qemu-project.gitlab.io/qemu/interop/bitmaps.html#example-incremental-push-backups-without-backing-files +Steps to reproduce: +1. `blockdev-add` incremental backup node +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-add","arguments":{"driver":"qcow2","node-name":"incre0","file":{"driver":"file","filename":"/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2"}}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +``` +2. `blockdev-backup` with `vda` to target `incre0` node +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-backup", "arguments": {"device": "vda", "bitmap":"bitmap0", "target": "incre0", "sync": "incremental", "job-id": "incre0-job", "speed": 536870912}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848370 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "created", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848431 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "running", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848464 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "paused", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848485 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "running", + "id": "incre0-job" + } +} +{ + "return": { + } +} + +``` +3. `query-block-jobs` check `incre0-job` is done +``` +echo '{"execute":"qmp_capabilities"}{"execute":"query-block-jobs"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +{ + "return": [ + ] +} +``` +4. To release write lock (need to rebase in incre0.qcow2), `blockdev-del` +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-del","arguments":{"node-name":"incre0"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +``` +5. `qemu-img rebase` +``` +qemu-img rebase -b base.qcow2 -u incre0.qcow2 + +qemu-img: Could not open 'incre0.qcow2': Failed to get "write" lock +Is another process using the image [incre0.qcow2]? +``` + +6. check `query-named-block-nodes` after `blockdev-del` +``` +{ + "return": [ + { + "iops_rd": 0, + "detect_zeroes": "off", + "image": { + "virtual-size": 53687091200, + "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2", + "cluster-size": 65536, + "format": "qcow2", + "actual-size": 241340416, + "format-specific": { + "type": "qcow2", + "data": { + "compat": "1.1", + "compression-type": "zlib", + "lazy-refcounts": false, + "refcount-bits": 16, + "corrupt": false, + "extended-l2": false + } + }, + "dirty-flag": false + }, + "iops_wr": 0, + "ro": false, + "node-name": "incre0", + "backing_file_depth": 0, + "drv": "qcow2", + "iops": 0, + "bps_wr": 0, + "write_threshold": 0, + "encrypted": false, + "bps": 0, + "bps_rd": 0, + "cache": { + "no-flush": false, + "direct": false, + "writeback": true + }, + "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2" + }, + { + "iops_rd": 0, + "detect_zeroes": "off", + "image": { + "virtual-size": 240451584, + "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2", + "format": "file", + "actual-size": 241340416, + "dirty-flag": false + }, + "iops_wr": 0, + "ro": false, + "node-name": "#block412", + "backing_file_depth": 0, + "drv": "file", + "iops": 0, + "bps_wr": 0, + "write_threshold": 0, + "encrypted": false, + "bps": 0, + "bps_rd": 0, + "cache": { + "no-flush": false, + "direct": false, + "writeback": true + }, + "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2" + }, + ...... + ] +} +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1006655 b/results/classifier/gemma3:12b/files/1006655 new file mode 100644 index 00000000..0d7da1a4 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1007490 b/results/classifier/gemma3:12b/files/1007490 new file mode 100644 index 00000000..e4697f58 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1012 b/results/classifier/gemma3:12b/files/1012 new file mode 100644 index 00000000..c2f60aea --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1013241 b/results/classifier/gemma3:12b/files/1013241 new file mode 100644 index 00000000..6756f0cc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1013241 @@ -0,0 +1,27 @@ + +qemu-system-ppc64 hanging occasionally in disk writes + +I found last week that qemu-system-ppc64 (from git) hangs occasionally +under load, and I have a reproducer for it now. Unfortunately the +reproducer really takes a long time to run -- usually I can get a hang +in under 12 hours. + +Here is the reproducer case: + + https://lists.fedoraproject.org/pipermail/ppc/2012-June/001698.html + +Notes: + +(1) Verified by one other person (other than me). Happens on both + ppc64 and x86-64 host. + +(2) Happens with both Fedora guest kernel 3.3.4-5.fc17.ppc64 and kernel + 3.5.0 that I compiled myself. The test case above contains 3.3.4-5. + +(3) Seems to be a problem in qemu, not the guest. The reason I think + this is because I tried to capture a backtrace of the hang using + remote gdb, but gdb just hung when trying to connect to qemu + (gdb connects fine before the bug happens). + +(4) Judging by guest messages, appears to be happening when writing + to the disk. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1025 b/results/classifier/gemma3:12b/files/1025 new file mode 100644 index 00000000..3c55b0e2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1025244 b/results/classifier/gemma3:12b/files/1025244 new file mode 100644 index 00000000..a0c622b3 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1027525 b/results/classifier/gemma3:12b/files/1027525 new file mode 100644 index 00000000..b7b73027 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1027525 @@ -0,0 +1,30 @@ + +Unable to insert cd media located on ro nfs mount + +When issuing a "change" command via the monitor, qemu is unable to open the iso file if it is mounted on a read-only nfs share. If I mount read-write (and make sure the file is writable by the qemu process), then the change command succeeds. Note that this doesn't affect media specified on the command line when starting qemu, only when changing via the monitor. + +To reproduce, mount cd images directory read only, e.g. + +[root@kvmhost0 ~]# grep iso /etc/fstab +10.48.50.20:/iso /srv/kvm/iso nfs4 defaults,ro 0 0 + +Start qemu with minimal options, just need access to the monitor: + +[root@kvmhost0 ~]# kvm -vnc 127.0.0.1:0 -S + +Connect to the monitor and issue a change command: + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +Could not open '/srv/kvm/iso/ubuntu-12.04-server-amd64.iso + +Re-mount the iso directory read-write and notice that the command succeeds: + +[root@kvmhost0 ~]# mount -o remount,rw /srv/kvm/iso + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +(qemu) + +[root@kvmhost0 ~]# kvm --version +QEMU emulator version 1.1.1 (qemu-kvm-1.1.1), Copyright (c) 2003-2008 Fabrice Bellard +[root@kvmhost0 ~]# uname -a +Linux kvmhost0 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/103 b/results/classifier/gemma3:12b/files/103 new file mode 100644 index 00000000..85b67892 --- /dev/null +++ b/results/classifier/gemma3:12b/files/103 @@ -0,0 +1,2 @@ + +9pfs does not honor open file handles on unlinked files diff --git a/results/classifier/gemma3:12b/files/1054831 b/results/classifier/gemma3:12b/files/1054831 new file mode 100644 index 00000000..96f83a25 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1054831 @@ -0,0 +1,18 @@ + +qemu-user-static for sparc32plus : bash: fork: Invalid argument + +On Debian x86-64 host system I setup a sparc chroot using: + +host $ mkdir sparc +host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian +host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static +host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash + +When I then run the second stage of debootstrap I get: + +target $ /debootstrap/debootstrap --second-stage +bash: fork: Invalid argument + +The above procedures works perfectly for armhf. + +This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1062589 b/results/classifier/gemma3:12b/files/1062589 new file mode 100644 index 00000000..b944eb68 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1062589 @@ -0,0 +1,89 @@ + +Xp guest disk is corrupted when the data size exceeds 4 GB + +Host : +- 2.6.30.10 i686 pentium3 i386 GNU/Linux + +Guest : +- XPsp3 + +QEMU : +- QEMU emulator version 1.2.0 and 1.2.50 +- sudo /sources/qemu/i386-softmmu/qemu-system-i386 \ + -runas user -enable-kvm -rtc base=localtime -no-shutdown \ + -m 384 -usb -usbdevice tablet -vga std \ + -net nic,model=ne2k_pci -net tap,script=no,downscript=no \ + -drive file=/qemu/XP.img,index=0,media=disk,cache=writeback \ + -hdb /qemu/data.img \ + -drive index=2,media=cdrom,file=/jukebox/iso/xpProSP2.iso + +- image: /qemu/XP.img (before problem) +file format: qcow2 +virtual size: 10G (10737418240 bytes) +disk size: 3.9G +cluster_size: 65536 + +- chkdsk on Guest (before problem) +10474348 KB total disk space. +3519880 KB in 16982 files. +4440 KB in 898 indexes. +0 KB in bad sectors. +75980 KB in use by the system. +54432 KB occupied by the log file. +6874048 KB available on disk. + +4096 bytes in each allocation unit. +2618587 total allocation units on disk. +1718512 allocation units available on disk. + +- qemu-img check +Warning: cluster offset=0x42330b55100000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x42330b55120000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=42330b55110000: Table is not cluster aligned; L1 entry corrupted +Warning: cluster offset=0xa4d26d66440000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0xa4d26d66460000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=a4d26d66453300: Table is not cluster aligned; L1 entry corrupted +ERROR: invalid cluster offset=0xad1f0047300000 +ERROR: invalid cluster offset=0xad1f0047320000 +ERROR l2_offset=ad1f0047309700: Table is not cluster aligned; L1 entry corrupted +ERROR OFLAG_COPIED: l2_offset=c452330b15090000 refcount=0 +Warning: cluster offset=0x52330b15080000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x52330b150a0000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=52330b15090000: Table is not cluster aligned; L1 entry corrupted +ERROR OFLAG_COPIED: l2_offset=cc5234077956330b refcount=0 +Warning: cluster offset=0x52340779560000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x52340779580000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=52340779563300: Table is not cluster aligned; L1 entry corrupted +ERROR refcount block 0 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 1 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 2 is outside image +ERROR refcount block 3 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 4 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 5 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 6 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 7 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 8 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 9 is not cluster aligned; refcount table entry corrupted +. +. +. +. +. +ERROR refcount block 16381 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 16382 is outside image +ERROR refcount block 16383 is not cluster aligned; refcount table entry corrupted +ERROR cluster 0 refcount=0 reference=1 +ERROR cluster 1 refcount=0 reference=1 +ERROR cluster 3 refcount=0 reference=1 + +16396 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +8 internal errors have occurred during the check. + + +Hi, + +Everything is running pretty good until data size on disk C exceeds 4 GB. I Tried many options before figuring out that the problem occurs when data size exceeds 4 GB. I tried with QEMU 1.2.50, same problem. + +Best Regards. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1067517 b/results/classifier/gemma3:12b/files/1067517 new file mode 100644 index 00000000..5d5caf10 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1067517 @@ -0,0 +1,75 @@ + +qemu dosn't save snapshots with the 'commit' command + +Usually there is the 'commit' command in qemu which is described as followed: "commit changes to the disk images (if -snapshot is used) or backing files" +From the context i though if i start a guest with the "-snapshot" option, the commit command would save all the changes back to the file. I've tried it out but i didn't get it to work. I tried a few things like first use savevm or stop and than commit all, but actually nothing works. +Interestingly, when using qcow2 files qemu doesn't show's any error at all. The changes in the guest just won't get saved. But if i'm using lvm2 partitions i would get I/O errors after execute 'commit all'. That's probably because lvm2 doesn't support this feature.?!? However i made a attachment which shows the error's in the guest (dmesg). + +Right now i started the guest with following command: +/usr/bin/qemu-system-x86_64 -name g64 -runas kvm -m 4096 -smp 2 \ +-monitor unix:/var/run/kvm/g64.sock,server,nowait -pidfile /var/run/kvm/g64.pid -daemonize -snapshot \ +-device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent \ +-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ +-drive file=/media/btrfs/g64.qcow2,if=virtio,cache=none,aio=threads \ +-netdev type=tap,id=g64_3,vhost=on,ifname=qtap3,script=no,downscript=no \ +-device virtio-net-pci,netdev=g64_3,mac=DE:AD:BE:EF:CB:22 \ +-spice port=5803,addr=192.168.2.60,password=secret -k de -cpu host \ +-usb -usbdevice tablet -vga qxl + +The system is stable gentoo: +Portage 2.1.11.9 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r2, 3.4.9-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-3.4.9-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1 +Timestamp of tree: Tue, 16 Oct 2012 03:45:01 +0000 +app-shells/bash: 4.2_p37 +dev-lang/python: 2.7.3-r2, 3.2.3 +dev-util/cmake: 2.8.8-r3 +dev-util/pkgconfig: 0.27.1 +sys-apps/baselayout: 2.1-r1 +sys-apps/openrc: 0.9.8.4 +sys-apps/sandbox: 2.5 +sys-devel/autoconf: 2.68 +sys-devel/automake: 1.11.6 +sys-devel/binutils: 2.22-r1 +sys-devel/gcc: 4.5.4 +sys-devel/gcc-config: 1.7.3 +sys-devel/libtool: 2.4-r1 +sys-devel/make: 3.82-r3 +sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) +sys-libs/glibc: 2.15-r2 +Repositories: gentoo x-local x11 sunrise virtualization +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe -march=native -fopenmp" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe -march=native -fopenmp" +DISTDIR="/usr/portage/distfiles" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS=" http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ http://gentoo.mirror.web4u.cz/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.ynet.sk/pub" +LANG="de_DE.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp" +LINGUAS="en" +MAKEOPTS="-j12" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +PORTDIR="/usr/portage" +PORTDIR_OVERLAY="/home/clown/public/overlays/local /home/clown/public/overlays/layman/x11 /home/clown/public/overlays/layman/sunrise /home/clown/public/overlays/layman/virtualization" +SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" +USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-1.1.1-r1 was built with the following: +USE="aio caps curl ncurses sasl spice vde vhost-net -alsa -bluetooth -brltty -debug -doc -fdt -opengl -pulseaudio -python -rbd -sdl -smartcard -static -tci -tls -usbredir -virtfs -xattr -xen -xfs" QEMU_SOFTMMU_TARGETS="i386 x86_64 (-alpha) (-arm) -cris (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 x86_64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel (-mips) -mipsel (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/107 b/results/classifier/gemma3:12b/files/107 new file mode 100644 index 00000000..5c8a9712 --- /dev/null +++ b/results/classifier/gemma3:12b/files/107 @@ -0,0 +1,2 @@ + +qemu-img fixed vhd issues diff --git a/results/classifier/gemma3:12b/files/1074 b/results/classifier/gemma3:12b/files/1074 new file mode 100644 index 00000000..b36b01ff --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1085 b/results/classifier/gemma3:12b/files/1085 new file mode 100644 index 00000000..e9ff1112 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1085 @@ -0,0 +1,41 @@ + +QEMU 7.0.0 - NSIS installer issue +Description of problem: +Misisng info in QEMU.nsi file +Steps to reproduce: +The exe installer exe file properties has a lot of porpeties missing + + + +This is casued by mssing instruction like + +VIAddVersionKey "ProductName" "" +VIAddVersionKey "ProductVersion" "" +VIAddVersionKey "Comments" "" +VIAddVersionKey "CompanyName" "" +VIAddVersionKey "LegalTrademarks" "" +VIAddVersionKey "LegalCopyright" "" +VIAddVersionKey "FileVersion" "" +VIAddVersionKey "FileDescription" "" + +VIAddVersionKey "InternalName" "" +VIAddVersionKey "OriginalFilename" "" + +In Windows program òlist about uninstalle + +the QEMU icon is not right (generic icon) +The Is missing teh publisg + + + +This si due error on + +!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico" + +that probably point to an icon file not available + +and an misisng line that set Publisher info for uninstalelr + +WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "" + +Thanks. KR. diff --git a/results/classifier/gemma3:12b/files/1087411 b/results/classifier/gemma3:12b/files/1087411 new file mode 100644 index 00000000..714a69ad --- /dev/null +++ b/results/classifier/gemma3:12b/files/1087411 @@ -0,0 +1,19 @@ + +pseries machine breaks in instalation of SLES11_SP2 + +QEMU version: 1.0, 1.1, and 1.2 + +Host OS: +Intel(R) Core(TM) i5-2520M CPU @ 2.50GH + Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +SLES Media: +SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256 -> 2247dd6bb495eb50860668e46f7d6ba004eece9909f347c8ce487fd6a5f65ee1 + +Command line: +./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom +/exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server + +Error message (after starting instalation ~23%): +Installation of package ./suse/ppc64/vim-base-7.2-8.15.2.ppc64.rpm failed. +Subprocess failed. Error: RPM failed: error: %post(vim-base-7.2-8.15.2.ppc64.rpm) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1090615 b/results/classifier/gemma3:12b/files/1090615 new file mode 100644 index 00000000..50e7af8f --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1093360 b/results/classifier/gemma3:12b/files/1093360 new file mode 100644 index 00000000..9167dc55 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1093360 @@ -0,0 +1,14 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1094564 b/results/classifier/gemma3:12b/files/1094564 new file mode 100644 index 00000000..f4b4ea39 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1094564 @@ -0,0 +1,20 @@ + +images used as scsi disks not readable (qemu-system-arm, macos 10.8) + +Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is + +commit f563a5d7a820424756f358e747238f03e866838a +Merge: a273652 aee0bf7 +Author: Paolo Bonzini <email address hidden> +Date: Wed Oct 31 10:42:51 2012 +0100 + + Merge remote-tracking branch 'origin/master' into threadpool + + Signed-off-by: Paolo Bonzini <email address hidden> + + +I am using: +qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 + +Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: +CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1101 b/results/classifier/gemma3:12b/files/1101 new file mode 100644 index 00000000..0cd9c18c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1102027 b/results/classifier/gemma3:12b/files/1102027 new file mode 100644 index 00000000..f320ddda --- /dev/null +++ b/results/classifier/gemma3:12b/files/1102027 @@ -0,0 +1,10 @@ + +QED Time travel + +This night after a reboot of a VM, it was back to 8 Oct. 2012, i've lost all data between 8 Oct 2012 and now. I've check the QED file and mount on another VM, all seems OK. + +This QED has a raw backfile with the base OS (debian) shared with many others QED. It has NO snapshot. + +QEMU emulator version 1.1.2 + +Does anyone have a hint ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1103868 b/results/classifier/gemma3:12b/files/1103868 new file mode 100644 index 00000000..39396747 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1103903 b/results/classifier/gemma3:12b/files/1103903 new file mode 100644 index 00000000..3b89b177 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1103903 @@ -0,0 +1,23 @@ + +drive_mirror on a resized image creates file with wrong size + +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 vda test +Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off + +the file is 32M instead of 64M: + +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/gemma3:12b/files/1105670 b/results/classifier/gemma3:12b/files/1105670 new file mode 100644 index 00000000..715ba39d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1105670 @@ -0,0 +1,47 @@ + +Converting vpc image to raw results in an image that is smaller than it should be. + +When using qemu-img to convert a 3GB dynamic vhd image to raw, the resultant image was smaller than what I was expecting. I was expecting a new raw image of size 3221225472bytes but the size generated was 3220955136bytes. I had similar results when I used a fixed vhd image and explicitly specified the format as vpc. + +Details about my configuration +OS: Centos 5.4, 64bit +Qemu used 1.1.1-1, but also saw the same behavior on 1.3.3 and the development build. + +Command used for dynamic vhd image file: +qemu-img convert -O raw inputDynamic.vhd outputFromDynamic.raw + +Command used for fixed vhd image file: +qemu-img convert f vpc -O raw inputFixed.vhd outputFromFixed.raw + +Both images were first created on hyperv running on windows 2008 r2 using the hyperv manager interface. I think I tried their diskpart utility and had the same results. + +Output from the following commands (I saw this on Bug#893956) +$ hexdump -C -n 512 image.VHD +00000000 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +00000010 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +00000020 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +00000030 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +00000040 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +00000050 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00000200 + +$ hexdump -C -n 512 -s $(($(ls -l image.VHD | awk '{ print $5 }') - 512)) image.VHD +56057e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +56057e10 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +56057e20 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +56057e30 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +56057e40 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +56057e50 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +56057e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +56058000 +----- +When I investigated this a bit further I found that the disk geometry calculations needed to be one cylinder more than the information stored in the footer size information. The disk size information in the file was 3221225472 bytes, and the disk geometry was cylinders 6241, heads 10, sectors per cylinder 63. Multiplying that together and with a sector size of 512 gives 3220955136bytes...the size qemu made the image as, but the new image is now smaller than the original image. + +When I added one to the cylinder size I got a size larger than I was expecting, but large enough to hold all of the data from the original image. + +My suggested fix for this is to add one to the cylinder size when reading a vhd image file. And subtracting one when writing out to a vhd file. I've attached a patch with the suggested fix. + +Please let me know if you need additional information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1116 b/results/classifier/gemma3:12b/files/1116 new file mode 100644 index 00000000..5acc502f --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1117 b/results/classifier/gemma3:12b/files/1117 new file mode 100644 index 00000000..f7291ce4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1117 @@ -0,0 +1,96 @@ + +migration corrupts qcow2 metadata when "backing file: json:{" is involve +Description of problem: +the bug happens when you have a qcow2 with backing file in json format +image: 2.qcow2 +[...] +backing file: json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}} +backing file format: qcow2 +[...] +if you want to migrate a VM that have that kind of qcow2 attached, the migration is gonna corrupted qcow2 metadata in memory and info block will look like this +json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} +later if you execute blockdev-snapshot-sync, the corrupt json will be write to the new qcow2 resulting with a unusable qcow2 +Steps to reproduce: +/opt/qemu-7.0.0/bin/qemu-img create -f qcow2 0.qcow2 64G +/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "0.qcow2"}}' 1.qcow2 +/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}}' 2.qcow2 + +#VM1 +/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none + +#VM2 +/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none -incoming tcp::8082 + + +#VM1 INFO BLOCK +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: 1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + +#VM1 MIGRATE +{ "execute": "migrate", "arguments": { "uri": "tcp:localhost:8082" } } +{"return": {}} +{"timestamp": {"seconds": 1658491019, "microseconds": 233177}, "event": "STOP"} + + +#VM2 INFO BLOCK +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writeback\r\n Backing file: 1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + +#VM2 MIGRATE +{"timestamp": {"seconds": 1658491019, "microseconds": 249760}, "event": "RESUME"} + +#VM2 MIGRATION DONE, INFO BLOCK +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: json:{\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}} (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + + +#VM2 SNAPSHOT AFTER MIGRATION +{ "execute": "blockdev-snapshot-sync", "arguments": { "format": "qcow2", "snapshot-file": "3.qcow2", "node-name": "drive0", "snapshot-node-name": "drive0-snap" }} +Formatting '3.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=68719476736 backing_file=json:{"backing": {"backing": {"driver": "qcow2",, "file": {"driver": "file",, "filename": "0.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "1.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "2.qcow2"}} backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16 +{"return": {}} + + +#VM2 INFO BLOCK AFTER SNAPSHOT +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0-snap): 3.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (chain depth: 3)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + + + +#INFO +/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver' +Additional information: +Even if the bug is scary it's very simple to fix it + +/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver' + +root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img rebase -f qcow2 -F qcow2 -u -b 2.qcow2 3.qcow2 +root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +image: 3.qcow2 +file format: qcow2 +virtual size: 64 GiB (68719476736 bytes) +disk size: 24 KiB +cluster_size: 65536 +backing file: 2.qcow2 +backing file format: qcow2 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false + +image: 2.qcow2 +file format: qcow2 +virtual size: 64 GiB (68719476736 bytes) +disk size: 24 KiB +cluster_size: 65536 +[..........] diff --git a/results/classifier/gemma3:12b/files/1144 b/results/classifier/gemma3:12b/files/1144 new file mode 100644 index 00000000..da08785d --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1151450 b/results/classifier/gemma3:12b/files/1151450 new file mode 100644 index 00000000..7a8a5e1c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1151450 @@ -0,0 +1,20 @@ + +wrong description in qemu manual + + +Description: +man qemu, there is a line: +qemu-system-x86_84 --drive file=gluster://192.0.2.1/testvol/a.img +seems should be: +qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img + +Additional info: +* operating system +arch linux x86_64 +* package version(s) +1.4.0 +* config and/or log files etc. + + +Steps to reproduce: +man qemu \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1169 b/results/classifier/gemma3:12b/files/1169 new file mode 100644 index 00000000..2114fb2e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1169 @@ -0,0 +1,4 @@ + +rename snapshot by qemu-img +Additional information: +I have no idea to rename a snapshot which created by `qemu-img snapshot -c`, I think it is a useful function diff --git a/results/classifier/gemma3:12b/files/117 b/results/classifier/gemma3:12b/files/117 new file mode 100644 index 00000000..5b94a19c --- /dev/null +++ b/results/classifier/gemma3:12b/files/117 @@ -0,0 +1,2 @@ + +nested 9p filesystem with security_model=mapped-xattr diff --git a/results/classifier/gemma3:12b/files/1175 b/results/classifier/gemma3:12b/files/1175 new file mode 100644 index 00000000..f3c73441 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1175 @@ -0,0 +1,9 @@ + +Crash / Assert in VVFAT.c while installaling WinXP from QEMU 7.0 running in Raspberry OS +Description of problem: +- Windows XP installation crashes QEMU with : +qemu-system-i386: ../block/vvfat.c:103: array_get: Assertion `index < array->next' failed. +Steps to reproduce: +Use command line above and run WindowsXP installation +Additional information: +Execution also leads to many "Invalid file name" being reported by QEMU diff --git a/results/classifier/gemma3:12b/files/1176 b/results/classifier/gemma3:12b/files/1176 new file mode 100644 index 00000000..749fb33e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1176 @@ -0,0 +1,8 @@ + +VVFAT :rw writes from guest (ReactOS, windowsXP) not visible by host +Description of problem: +As described in https://jira.reactos.org/browse/CORE-18327 +While ./LMS is mounted as a :rw VVFAT drive, guest OS (ReactOS) is able to read files BUT when files are "written" from the guest, they are not visible on host side. +QEMU execution is also massively polluted by "invalid file name" messages coming from https://git.qemu.org/?p=qemu.git;a=blob_plain;f=block/vvfat.c;hb=HEAD (but this is not specific to the use with ReactOS, as this is also observed with other guest : WXP, ...) + +See attached screenshot showing WXPSP3 as guest with file created in VVFAT drive while guest misses the newly created file. diff --git a/results/classifier/gemma3:12b/files/1179 b/results/classifier/gemma3:12b/files/1179 new file mode 100644 index 00000000..7702ed67 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1185395 b/results/classifier/gemma3:12b/files/1185395 new file mode 100644 index 00000000..c1898c1f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1185395 @@ -0,0 +1,13 @@ + +qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend + +With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error. +Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6? + +( -95 might be a general "Operation not supported" error? ) + +Up to 1.4.2 everything is OK with savevm, though. + +Any help welcome, + +Oliver. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1188018 b/results/classifier/gemma3:12b/files/1188018 new file mode 100644 index 00000000..e2e0c573 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1188018 @@ -0,0 +1,6 @@ + +qemu monitor does not suppot rbd "savevm" command + +1. I used ceph rbd as my block device, /usr/local/bin/qemu-system-x86_64 -drive format=rbd,file=rbd:rbd/sles.img:rbd_cache=true,cache=writeback -boot c -m 1024 -enable-kvm -vnc 0.0.0.0:0 -monitor stdio + +2. when in monitor command line "savevm", it reports "Error -95 while writing VM" in the monitor \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1190 b/results/classifier/gemma3:12b/files/1190 new file mode 100644 index 00000000..0ebf6d75 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1190 @@ -0,0 +1,2 @@ + +compiling v7.1 with --static fails with "/usr/bin/ld: cannot find -lmount" diff --git a/results/classifier/gemma3:12b/files/1207896 b/results/classifier/gemma3:12b/files/1207896 new file mode 100644 index 00000000..0b4d1619 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1207896 @@ -0,0 +1,4 @@ + +binfmt wrapper for argv[0] handling + +Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1213 b/results/classifier/gemma3:12b/files/1213 new file mode 100644 index 00000000..c78ba121 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1213 @@ -0,0 +1,44 @@ + +7.1.0 - NSIS Installer file issues +Description of problem: + + +Please check the screenshot relative to Window program list + +**Problem n. 1 (standard icon)** + +The icon rlative to QEMU is not graphic icon but starndrd udenfiend icon + +**Problem n. 2 (author missing)** + +Author info is missing + +**Problem n. 3 (installer date is not updated)** + +When you upgrade QEM the installation date not reflect last update but first installation (ex. version 7.1.0 with date of 2021). + +Note: all issues are relative to NSIS installer script. + +**Uninstaller icon** + +It seems that + +**!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico"**__ + +didn't work. + +Please check here + +https://nsis.sourceforge.io/Add_uninstall_information_to_Add/Remove_Programs + +Please try to add in uninsaller section + + WriteRegStr HKLM "${UNINST_KEY}" "DisplayIcon" "${SRCDIR}\pc-bios\qemu-nsis.ico" + +**Missing author info in uninstall view** + + ; Write the uninstall keys for Windows + WriteRegStr HKLM "${UNINST_KEY}" "DisplayName" "QEMU" + WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "QEMU crew" + +Replace "QEMU crew" with text that you like. diff --git a/results/classifier/gemma3:12b/files/1216 b/results/classifier/gemma3:12b/files/1216 new file mode 100644 index 00000000..6b3f488e --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1218 b/results/classifier/gemma3:12b/files/1218 new file mode 100644 index 00000000..46083878 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1218 @@ -0,0 +1,21 @@ + +bitmap lost when create snapshot using blockdev-snapshot-sync function +Description of problem: +bitmap will be lost when using the blockdev-snapshot-sync qmp command to create external snapshot. +if we create snapshot with the bitmap ,we have to start our incremental backup chain from a new full-backup. +Steps to reproduce: +1. start the qemu : +qemu-system-x86_64 -name guest=i-00001C,debug-threads=on -machine pc,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0x9 -device piix4-usb-uhci,id=usb2,bus=pci.0,addr=0xb -device qemu-xhci,id=usb3,bus=pci.0,addr=0xc -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on -drive file=/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait + +2. {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-19-16-10-23"}} + +3. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block173", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "**dirty-bitmaps**": [{"name": "bitmap-2022-09-19-16-10-23", "recording": true, "persistent": false, "busy": false, "granularity": 65536, "count": 0}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +4. {"execute":"blockdev-snapshot-sync","arguments":{"device": "drive-virtio-disk0", "snapshot-file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "format": "qcow2"}} +5. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "backing-filename-format": "qcow2", "virtual-size": 21474836480, "filename": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "full-backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block618", "backing_file_depth": 1, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "backing_file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +we lost the bitmap bitmap-2022-09-19-16-10-23 +Additional information: +the bitmap attach the active bs, when changing the active bs ,the bitmap will be lost... diff --git a/results/classifier/gemma3:12b/files/1222 b/results/classifier/gemma3:12b/files/1222 new file mode 100644 index 00000000..72cd513e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1222 @@ -0,0 +1,22 @@ + +/proc/self/exe not handled in execve +Description of problem: +I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this. + +My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with `execve /proc/self/exe`. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use... + +> Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary +> emulated, as opposed to qemu-system which runs an entire system but is harder to automate in +> toolchains) we need these patches because of a peculiar thing many golang applications do. They +> re-execute themselves using the execve syscall using /proc/self/exe as the executable. In +> non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the +> top-level emulator process and _not_ podman/buildah/skopeo. This causes all container storage +> operations to mysteriously fail, because the wrong binary is being executed. This issue was quite +> difficult to root cause. +Additional information: +Old patchsets that seem to be trying to fix this: +- http://next.patchew.org/QEMU/20210531055019.10149-1-yamamoto@midokura.com/20210531055019.10149-2-yamamoto@midokura.com/ +- https://patchew.org/QEMU/20190916155545.29928-1-olivier.dion@polymtl.ca/ +- https://patchew.org/QEMU/20190807135458.32440-1-dion@linutronix.de/ + +It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue. diff --git a/results/classifier/gemma3:12b/files/1223467 b/results/classifier/gemma3:12b/files/1223467 new file mode 100644 index 00000000..68730f60 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1223467 @@ -0,0 +1,23 @@ + +Unable to use USB as hda in Windows + +I built qemu 1.6.0 from source in MinGW (and all dependents not available with mingw-get) +The command line: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +or +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +(or the *w.exe equivalents) +reports in stderr.txt: +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: Block protocol 'host_device' doesn't support the option 'filename' +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: could not open disk image \\.\PhysicalDrive1: Invalid argument + +I have also found this bug in 1.5 but not in 1.4 + +Some Help: +The code in Qemu is a bit beyond me at 1am, but I was able to determine the root cause seems to be that block.c is becoming confused about referring to a file but not having a file name. I have been able to work around this by changing line 860 of block.c from: "if (qdict_size(options) != 0) {" to "if (qdict_size(options) != 0 && !is_windows_drive(filename)) {" + +But I don't think this is a good solution (it is assuming that nothing else could be wrong), and I can't be sure that I'm not masking some real issue. + +FWIW; Build is on XP, but execution is on Win7. + +Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1224414 b/results/classifier/gemma3:12b/files/1224414 new file mode 100644 index 00000000..5101d414 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1236 b/results/classifier/gemma3:12b/files/1236 new file mode 100644 index 00000000..020c5c1c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1236 @@ -0,0 +1,47 @@ + +blockdev fixed vhdx trying to reserve space, also misleading error, Could not open file: Invalid argument +Description of problem: +The qemu-storage-daemon/other qemu commands will not start and will choke on requiring vhdx driver for the blockdev layer. +Opening a fixed-virtual-disk like fixed-vhdx should not reserve extra space, and should only overwrite as all blocks are already allocated. +Steps to reproduce: +1. Ensure that a partition size is such that after deciding a fixed-vhdx size, the remainder space after creation of fixed-vhdx is less than the fixed-vhdx. +2. Create a fixed-vhdx file +3. Try to start an nbd server with it +the qemu-storage-daemon will not start +Additional information: +I want to mention that I am testing qemu-storage-daemon under windows/hyperv + +So far, I want to report that it has **worked** for rawimg and qcow2-fixed. +See comment of 20220926 https://github.com/cloudbase/wnbd/issues/63#issuecomment-1257148849 + +The driver parameter ```vhdx``` to the blockdev argument seems to struggle with it. + +I wanted to check if the vhdx blockdev driver has the same VHDX-related-bugs as qemu-nbd +- #727 VHDX is corrupted on expansion. +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts + +Even the the blockdev reference entries seem to have VHDX all over the place +- pg 318 https://readthedocs.org/projects/qemu/downloads/pdf/latest/ +- https://www.qemu.org/docs/master/system/qemu-block-drivers.html +- except conspicuously here !! https://www.qemu.org/docs/master/interop/qemu-storage-daemon-qmp-ref.html?highlight=blockdev#qapidoc-265 + + +``` +C:\Windows\System32>qemu-storage-daemon --version +qemu-storage-daemon version 7.1.0 (v7.1.0-11925-g4ec481870e-dirty) + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file: Could not open 'H:\gkpics01.vhdx': Invalid argument + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed: Parameter 'subformat' is unexpected + +C:\Windows\System32>dir H:\gkpics01.vhdx + Volume in drive H is CPERF0 + Volume Serial Number is F196-DB9E + Directory of H:\ +09/29/2022 08:55 PM 99,727,966,208 gkpics01.vhdx + 1 File(s) 99,727,966,208 bytes + 0 Dir(s) 4,312,399,872 bytes free +``` +## diff --git a/results/classifier/gemma3:12b/files/1239 b/results/classifier/gemma3:12b/files/1239 new file mode 100644 index 00000000..5c942817 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1239 @@ -0,0 +1,37 @@ + +The help document of qemu-img misses some options +Description of problem: +The "--help" option of qemu-img misses the option "skip-broken-bitmaps" for convert , "image-opts" for bench, "object" for dd and "force-share" for measure. +Steps to reproduce: +1. For the option "skip-broken-bitmaps", the following code appears during option parsing for convert and modifies the skip_broken in qemu-img.c:2377-2379. + +``` + case OPTION_SKIP_BROKEN: + skip_broken = true; + break; +``` + +2. For the option "image-opts", the following code appears during option parsing for bench and modifies the image_opts in qemu-img.c:4511-4513. + +``` + case OPTION_IMAGE_OPTS: + image_opts = true; + break; +``` +3. For the option "object", the following code appears during option parsing for dd and calls the user_creatable_process_cmdline in qemu-img.c:4980-4982. + +``` + case OPTION_OBJECT: + user_creatable_process_cmdline(optarg); + break; +``` +4. For the option "force-share", the following code appears during option parsing for measure and modifies the force_share in qemu-img.c:5237-5239. +``` + case 'U': + force_share = true; + break; +``` +Additional information: +But they do not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/gemma3:12b/files/1245703 b/results/classifier/gemma3:12b/files/1245703 new file mode 100644 index 00000000..3a6c8873 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1245703 @@ -0,0 +1,10 @@ + +LD_PREFIX option reads directories recursively in an endless loop + +If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel. + +According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop. + +The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. + +Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1261 b/results/classifier/gemma3:12b/files/1261 new file mode 100644 index 00000000..7a91cada --- /dev/null +++ b/results/classifier/gemma3:12b/files/1261 @@ -0,0 +1,26 @@ + +qemu-user syscall 439 (faccessat2) not implemented - loongarch64 +Description of problem: +On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in linux-user/syscall +Steps to reproduce: +1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi +2. The result is "ERROR" even if the file "test.sh" exists and it is readeable +3. The correct result should be "OK" +Additional information: +test.sh: + ``` + if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi + ``` +qemu-loongarch -strace log: + ``` +[...] +12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0 +12579 lseek(255,0,SEEK_CUR) = 0 +12579 read(255,0x2016d490,56) = 56 +12579 Unknown syscall 439 +12579 write(1,0x20172010,6) = 6 +12579 read(255,0x2016d490,56) = 0 +12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0 +12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0 +12579 exit_group(0) + ``` diff --git a/results/classifier/gemma3:12b/files/1269606 b/results/classifier/gemma3:12b/files/1269606 new file mode 100644 index 00000000..28a66d6c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1269606 @@ -0,0 +1,115 @@ + +curl driver (http) always says "No such file or directory" + +I have a remote server, on which an http disk image definitely exists. However the qemu curl block driver cannot open it. It always gives the bogus error: + +CURL: Error opening file: Connection time-out +qemu-system-x86_64: -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none: could not open disk image http://onuma/scratch/cirros-0.3.1-x86_64-disk.img: Could not open backing file: Could not open 'http://onuma/scratch/cirros-0.3.1-x86_64-disk.img': No such file or directory + +On the server, I can see from the logs that qemu/curl is opening it: + +192.168.0.175 - - [15/Jan/2014:21:25:37 +0000] "HEAD /scratch/cirros-0.3.1-x86_64-disk.img HTTP/1.1" 200 - "-" "-" +192.168.0.175 - - [15/Jan/2014:21:25:37 +0000] "GET /scratch/cirros-0.3.1-x86_64-disk.img HTTP/1.1" 206 264192 "-" "-" + +I am using qemu & curl from git today. + +curl: curl-7_34_0-177-gc7a76bb +qemu: for-anthony-839-g1cf892c + +Here is the full command I am using: + +http_proxy= \ +LD_LIBRARY_PATH=/home/rjones/d/curl/lib/.libs \ +LIBGUESTFS_BACKEND=direct \ +LIBGUESTFS_HV=/home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ +guestfish -v --ro -a http://onuma/scratch/cirros-0.3.1-x86_64-disk.img run + +The full output (includes qemu command itself) is: + +libguestfs: launch: program=guestfish +libguestfs: launch: version=1.25.20fedora=21,release=1.fc21,libvirt +libguestfs: launch: backend registered: unix +libguestfs: launch: backend registered: uml +libguestfs: launch: backend registered: libvirt +libguestfs: launch: backend registered: direct +libguestfs: launch: backend=direct +libguestfs: launch: tmpdir=/tmp/libguestfsoQctgE +libguestfs: launch: umask=0002 +libguestfs: launch: euid=1000 +libguestfs: command: run: /usr/bin/supermin-helper +libguestfs: command: run: \ --verbose +libguestfs: command: run: \ -f checksum +libguestfs: command: run: \ --host-cpu x86_64 +libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] whitelist = (not specified) +supermin helper [00000ms] host_cpu = x86_64 +supermin helper [00000ms] dtb_wildcard = (not specified) +supermin helper [00000ms] inputs: +supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] outputs: +supermin helper [00000ms] kernel = (none) +supermin helper [00000ms] dtb = (none) +supermin helper [00000ms] initrd = (none) +supermin helper [00000ms] appliance = (none) +checking modpath /lib/modules/3.12.5-302.fc20.x86_64 is a directory +checking modpath /lib/modules/3.11.9-200.fc19.x86_64 is a directory +checking modpath /lib/modules/3.11.10-200.fc19.x86_64 is a directory +checking modpath /lib/modules/3.11.4-201.fc19.x86_64 is a directory +picked kernel vmlinuz-3.12.5-302.fc20.x86_64 +supermin helper [00000ms] finished creating kernel +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/base.img.gz +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img.gz +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles +supermin helper [00041ms] visiting /usr/lib64/guestfs/supermin.d/init.img +supermin helper [00041ms] visiting /usr/lib64/guestfs/supermin.d/udev-rules.img +supermin helper [00041ms] adding kernel modules +supermin helper [00064ms] finished creating appliance +libguestfs: checksum of existing appliance: 2017df18eaeee7c45b87139c9bd80be2216d655a1513322c47f58a7a3668cd1f +libguestfs: [00066ms] begin testing qemu features +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -help +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -version +libguestfs: qemu version 1.7 +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -machine accel=kvm:tcg +libguestfs: command: run: \ -device ? +libguestfs: [00127ms] finished testing qemu features +[00128ms] /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ + -global virtio-blk-pci.scsi=off \ + -nodefconfig \ + -enable-fips \ + -nodefaults \ + -display none \ + -machine accel=kvm:tcg \ + -cpu host,+kvmclock \ + -m 500 \ + -no-reboot \ + -no-hpet \ + -kernel /var/tmp/.guestfs-1000/kernel.19645 \ + -initrd /var/tmp/.guestfs-1000/initrd.19645 \ + -device virtio-scsi-pci,id=scsi \ + -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/var/tmp/.guestfs-1000/root.19645,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-pci \ + -serial stdio \ + -device sga \ + -chardev socket,path=/tmp/libguestfsoQctgE/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' +CURL: Error opening file: Connection time-out +qemu-system-x86_64: -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none: could not open disk image http://onuma/scratch/cirros-0.3.1-x86_64-disk.img: Could not open image: Invalid argument +libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages +libguestfs: child_cleanup: 0x7f07bf6599b0: child process died +libguestfs: sending SIGTERM to process 19654 +libguestfs: error: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 exited with error status 1, see debug messages above +libguestfs: error: guestfs_launch failed, see earlier error messages +libguestfs: closing guestfs handle 0x7f07bf6599b0 (state 0) +libguestfs: command: run: rm +libguestfs: command: run: \ -rf /tmp/libguestfsoQctgE \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1280961 b/results/classifier/gemma3:12b/files/1280961 new file mode 100644 index 00000000..e8314ffa --- /dev/null +++ b/results/classifier/gemma3:12b/files/1280961 @@ -0,0 +1,6 @@ + +editing the file when mount the file system using 9pfs. it will report fsync failed. + + I have get a fsync error when I use the 9pfs on the kvm guest. it appears when I use vi editor and sysbench. I have not found the reason yet. can you tell something about it? the attache is the picture. and there is no any log which I can provide. + + My qemu version is qemu-kvm-0.13.0, and my host linux distributions is 2.6.32-431.el6.x86_64 and the guest vm is the same version which enable 9pfs and 9pnet support. I use the string of "mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl" to get the file system. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1285505 b/results/classifier/gemma3:12b/files/1285505 new file mode 100644 index 00000000..5ac4263a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1287 b/results/classifier/gemma3:12b/files/1287 new file mode 100644 index 00000000..2c7a2cdd --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1289898 b/results/classifier/gemma3:12b/files/1289898 new file mode 100644 index 00000000..b005995c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1299190 b/results/classifier/gemma3:12b/files/1299190 new file mode 100644 index 00000000..676b5347 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1300863 b/results/classifier/gemma3:12b/files/1300863 new file mode 100644 index 00000000..f37c4379 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1308542 b/results/classifier/gemma3:12b/files/1308542 new file mode 100644 index 00000000..bbddab24 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1308542 @@ -0,0 +1,17 @@ + +hang in qemu_gluster_init + +In qemu_gluster_init, if the call to either glfs_set_volfile_server or glfs_set_logging fails into the "out" case, glfs_fini is called without having first calling glfs_init. This causes glfs_lock to spin forever on this bit: + + while (!fs->init) + pthread_cond_wait (&fs->cond, &fs->mutex); + +And here's the bottom part of the backtrace when hung: + +#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 +#1 0x00007feceebf58c3 in glfs_lock (fs=0x7fecf15660b0) at glfs-internal.h:156 +#2 glfs_active_subvol (fs=0x7fecf15660b0) at glfs-resolve.c:799 +#3 0x00007feceebeb5b4 in glfs_fini (fs=0x7fecf15660b0) at glfs.c:652 +#4 0x00007fecf0043c73 in qemu_gluster_init (gconf=<value optimized out>, filename=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block/gluster.c:229 + +I believe this can be fixed by simply moving the call to glfs_init after the call to glfs_new but before the calls to glfs_set_volfile_server or glfs_set_logging. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1312561 b/results/classifier/gemma3:12b/files/1312561 new file mode 100644 index 00000000..8a3feaa4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1312561 @@ -0,0 +1,16 @@ + +libstdc++-6.dll is missing from your computer + +qemu-w64-setup-20140418.exe + +Windows 7 64 bit PC. + +qemu-system-armw -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda c:\11\rasimg\test.vhd + + +qemu-system-armw.exe - System Error +The program can't start because libstdc++-6.dll is missing from your computer. + +Try reinstalling the program to fix this problem. + +I tried reinstalling, but no change. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1319493 b/results/classifier/gemma3:12b/files/1319493 new file mode 100644 index 00000000..c81392f1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1319493 @@ -0,0 +1,31 @@ + +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file make: *** [install] Error 1 + +Folder "fsdev" will not be created in "/usr/local/bin". +Qemu compiled from actual git. + + + +####################################################################### +... +Installing with make install... +========================= Installation results =========================== +install -d -m 0755 "/usr/local/share/doc/qemu" +install -c -m 0644 qemu-doc.html qemu-tech.html "/usr/local/share/doc/qemu" +install -c -m 0644 qmp-commands.txt "/usr/local/share/doc/qemu" +install -d -m 0755 "/usr/local/share/man/man1" +install -c -m 0644 qemu.1 "/usr/local/share/man/man1" +install -c -m 0644 qemu-img.1 "/usr/local/share/man/man1" +install -d -m 0755 "/usr/local/share/man/man8" +install -c -m 0644 qemu-nbd.8 "/usr/local/share/man/man8" +install -d -m 0755 "/usr/local/share/man/man1" +install -c -m 0644 fsdev/virtfs-proxy-helper.1 "/usr/local/share/man/man1" +install -d -m 0755 "/usr/local/share/qemu" +install -d -m 0755 "/usr/local/etc/qemu" +install -c -m 0644 /tmp/qemu/sysconfigs/target/target-x86_64.conf "/usr/local/etc/qemu" +install -d -m 0755 "/usr/local/var"/run +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 +make: *** [install] Error 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1321028 b/results/classifier/gemma3:12b/files/1321028 new file mode 100644 index 00000000..aea72c12 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1324724 b/results/classifier/gemma3:12b/files/1324724 new file mode 100644 index 00000000..d4fa1fa2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1330 b/results/classifier/gemma3:12b/files/1330 new file mode 100644 index 00000000..9c13b343 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1330 @@ -0,0 +1,183 @@ + +qemu-img finishes successfully while having errors in commit or bitmaps operations +Description of problem: +Problem raises when trying to merge two images with the top image almost +full, and base image having stale bitmaps (bitmaps missing from +the top image). +In our usercase, the size of the LV that contains the base image is not +accounting for the stale bitmaps, and therefore, when we run `commit` or +`bitmap --merge`, it fails with: +``` +qcow2_free_clusters failed: No space left on device +qemu-img: Lost persistent bitmaps during inactivation of node '#block308': Failed to write bitmap 'stale-bitmap-002' to file: No space left on device +qemu-img: Failed to flush the refcount block cache: No space left on device +``` +However, in both cases `qemu-img` returned successfully, +while having logs printed to `stderr`, and failing the merge. + +For commit operation, the data was commited successfully, it failed as it +was adding the bitmaps. +Still, the process exit with success. + +On the other hand, for bitmaps operation, since its main purpose is to +manipulate bitmaps, and it failed, it should not return with code 0. +The process shall return with error code. +Also, bitmaps in the base image are left with the `in-use` flag set. +Steps to reproduce: +1. Create these lvs and chown them to the user +``` +sudo lvcreate --name base.qcow2 --size 128m storage +sudo chown $USER:$USER /dev/mapper/storage-base.qcow2 +sudo lvcreate --name top.qcow2 --size 128m storage +sudo chown $USER:$USER /dev/mapper/storage-top.qcow2 +``` +2. Run this python script. Note the `STALE_BITMAPS` counter. Using 6, 11, or 13 stale + bitmaps, the `commit`, or the `bitmaps` operations shall fail. +``` +# Reproduce ENOSPC error when merging into base image with lot of bitmaps. + +import json +import subprocess + +IMG_SIZE = 1 << 30 +LV_SIZE = 128 << 20 + +# Testing shows that we can merge successfully with 13 bitmaps, and require +# size calculation is more strict, allowing up to 11 bitamps. +STALE_BITMAPS = 11 + +def run(*cmd): + subprocess.run(cmd, check=True) + +def output(cmd): + cp = subprocess.run(cmd, stdout=subprocess.PIPE, check=True) + return json.loads(cp.stdout) + +def info(img): + return output(["qemu-img", "info", "--output", "json", img]) + +def measure(img): + return output(["qemu-img", "measure", "-f", "qcow2", "-O", "qcow2", "--output", "json", img]) + +def check(img): + cmd = ["qemu-img", "check", "-f", "qcow2", "--output", "json", img] + cp = subprocess.run(cmd, stdout=subprocess.PIPE) + if cp.returncode not in (0, 3): + raise RuntimeError(f"Check failed") + + return json.loads(cp.stdout) + +def indent(info): + return json.dumps(info, indent=2) + +base = "/dev/mapper/storage-base.qcow2" +top = "/dev/mapper/storage-top.qcow2" + +# Start with clean lvs by discarding current data. +run("blkdiscard", base) +run("blkdiscard", top) + +print("Creating base") +run("qemu-img", "create", "-f", "qcow2", base, str(IMG_SIZE)) + +# Simulate stale bitmaps - missing in top. +for i in range(STALE_BITMAPS): + bitmap = f"stale-bitmap-{i:03d}" + print(f"Creating stale bitmap {bitmap}") + run("qemu-img", "bitmap", "--add", base, bitmap) + +print("Info base before merge") +base_info = info(base) +print(indent(base_info)) + +print("Check base before merge") +base_check = check(base) +print(indent(base_check)) + +print("Measure base before merge") +base_measure = measure(base) +print(indent(base_measure)) + +print("Creating top") +run("qemu-img", "create", "-f", "qcow2", "-b", base, "-F", "qcow2", top) + +print("Adding good bitmap to top") +run("qemu-img", "bitmap", "--add", top, "good-bitmap") + +print("Writing data to top") +cmd = f"write -P {ord('B')} 0 126m" +run("qemu-io", "-f", "qcow2", "-c", cmd, top) + +print("Info top before merge") +top_info = info(top) +print(indent(top_info)) + +print("Check top before merge") +top_check = check(top) +print(indent(top_check)) + +print("Measure top before merge") +top_measure = measure(top) +print(indent(top_measure)) + +print("Commit top into base") +run("qemu-img", "commit", "-f", "qcow2", "-t", "none", "-b", base, "-d", "-p", top) + +print("Add good bitmap to base") +run("qemu-img", "bitmap", "--add", base, "good-bitmap") + +print("Merge good bitmap from top to base") +run("qemu-img", "bitmap", "--merge", "good-bitmap", "-F", "qcow2", "-b", top, base, "good-bitmap") + +print("Info base after merge") +print(indent(info(base))) + +print("Check base after merge") +print(indent(check(base))) + +print("Measure base after merge") +print(indent(measure(base))) +``` +Additional information: +Example output of the script with 6 stale bitmaps: +``` +Commit top into base + (100.00/100%) +Image committed. +Add good bitmap to base +Merge good bitmap from top to base +qcow2_free_clusters failed: No space left on device +qemu-img: Lost persistent bitmaps during inactivation of node '#block159': Failed to write bitmap 'good-bitmap' to file: No space left on device +qemu-img: Failed to flush the refcount block cache: No space left on device +Info base after merge +{ + "virtual-size": 1073741824, + "filename": "/dev/mapper/storage-base.qcow2", + "cluster-size": 65536, + "format": "qcow2", + "actual-size": 0, + "format-specific": { + "type": "qcow2", + "data": { + "compat": "1.1", + "compression-type": "zlib", + "lazy-refcounts": false, + "bitmaps": [ + ... + { + "flags": [ + "in-use", + "auto" + ], + "name": "good-bitmap", + "granularity": 65536 + } + ], + "refcount-bits": 16, + "corrupt": false, + "extended-l2": false + } + }, + "dirty-flag": false +} +``` diff --git a/results/classifier/gemma3:12b/files/1332297 b/results/classifier/gemma3:12b/files/1332297 new file mode 100644 index 00000000..ea165882 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1334 b/results/classifier/gemma3:12b/files/1334 new file mode 100644 index 00000000..9601ed39 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1334 @@ -0,0 +1,2 @@ + +qemu-img map qcow2 image,but can't get right zero area diff --git a/results/classifier/gemma3:12b/files/1336794 b/results/classifier/gemma3:12b/files/1336794 new file mode 100644 index 00000000..b94fe436 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1338563 b/results/classifier/gemma3:12b/files/1338563 new file mode 100644 index 00000000..e4a7f6d6 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1338563 @@ -0,0 +1,4 @@ + +README refers to a non-extant file + +The current stable QEMU release (1.4.2-89400a8) README consists of a single line telling the new user to "read the documentation in qemu-doc.html or on http://wiki.qemu.org". The distribution includes no qemu-doc.html, just a qemu-doc.texi. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1342704 b/results/classifier/gemma3:12b/files/1342704 new file mode 100644 index 00000000..b7be9f98 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1345 b/results/classifier/gemma3:12b/files/1345 new file mode 100644 index 00000000..79cdb6a8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1345 @@ -0,0 +1,2 @@ + +qemu-img manpage and is missing info on compression_type option diff --git a/results/classifier/gemma3:12b/files/1349722 b/results/classifier/gemma3:12b/files/1349722 new file mode 100644 index 00000000..2aeb5962 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1349722 @@ -0,0 +1,16 @@ + +qemu-io: Exit code is always zero + +The qemu-io always returns zero on exit independently on errors occurred during the command execution. + +Example, + +$ qemu-io -c 'write 128 234' /tmp/run1/test-1/test.img + +offset 128 is not sector aligned + +$ echo $? +0 + + +qemu.git HEAD: 41a1a9c42c4e \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1349972 b/results/classifier/gemma3:12b/files/1349972 new file mode 100644 index 00000000..750da958 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1352179 b/results/classifier/gemma3:12b/files/1352179 new file mode 100644 index 00000000..71163466 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1352179 @@ -0,0 +1,29 @@ + +could not open disk image + +After restart the server it's show this error: + +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +qemu-kvm: -drive file=/var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk: No such file or directory + +the disk info show + qemu-img info disk +image: disk +file format: qcow2 +virtual size: 100G (107374182400 bytes) +disk size: 22G +cluster_size: 65536 +backing file: /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f + +but this file (backing file : /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f) is empty. +And all the instances cant't find the disk image + +We use CentOS release 6.5 (64bit) +kernel version : 2.6.32-431.11.2.el6.x86_64 +qemu-kvm-0.12.1.2-2.415.el6_5.10.x86_64 + +virsh version +Compiled against library: libvirt 0.10.2 +Using library: libvirt 0.10.2 +Using API: QEMU 0.10.2 +Running hypervisor: QEMU 0.12.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1353456 b/results/classifier/gemma3:12b/files/1353456 new file mode 100644 index 00000000..71edaee3 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1353456 @@ -0,0 +1,18 @@ + +qemu-io: Failure on a qcow2 image with the fuzzed refcount table + +'qemu-io -c write' and 'qemu-io -c aio_write' crashes on a qcow2 image with a fuzzed refcount table. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.file in the same directory + 3. Execute + qemu-io copy.img -c write 279552 322560 + or + qemu-io copy.img -c aio_write 836608 166400 + +Result: qemu-io was killed by SIGIOT with the reason: + +qemu-io: block/qcow2-cluster.c:1291: qcow2_alloc_cluster_offset: Assertion `*host_offset != 0' failed. + +qemu.git HEAD 69f87f713069f1f \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1354167 b/results/classifier/gemma3:12b/files/1354167 new file mode 100644 index 00000000..254e6cb1 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1354529 b/results/classifier/gemma3:12b/files/1354529 new file mode 100644 index 00000000..ffdbb95a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1355697 b/results/classifier/gemma3:12b/files/1355697 new file mode 100644 index 00000000..75f17cfa --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1355738 b/results/classifier/gemma3:12b/files/1355738 new file mode 100644 index 00000000..80f84150 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1356916 b/results/classifier/gemma3:12b/files/1356916 new file mode 100644 index 00000000..58e5af07 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1356916 @@ -0,0 +1,7 @@ + +Too small argv limit + +Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: + +$ /bin/true $(yes | head -n 100000) +-bash: /bin/true: Argument list too long \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1356969 b/results/classifier/gemma3:12b/files/1356969 new file mode 100644 index 00000000..e459b90a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1356969 @@ -0,0 +1,14 @@ + +qemu-io: the 'map' command hangs 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-io copy.img -c map + +Result: qemu-io processes part of the image and then hangs loading 100% of CPU time. + + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1357 b/results/classifier/gemma3:12b/files/1357 new file mode 100644 index 00000000..c90b5cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1357440 b/results/classifier/gemma3:12b/files/1357440 new file mode 100644 index 00000000..9b59c9ea --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1357445 b/results/classifier/gemma3:12b/files/1357445 new file mode 100644 index 00000000..59d96a81 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1357445 @@ -0,0 +1,16 @@ + +qemu-img: 'amend -o compat=0.10' command failed with segfault on the fuzzed image + +qemu-img amend -o compat=0.10' failed with a segmentation fault on the fuzzed image. + +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 amend -o compat=0.10 -f qcow2 copy.img + +Result: qemu-img was killed by SIGSEGV. + +Traces can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/136 b/results/classifier/gemma3:12b/files/136 new file mode 100644 index 00000000..3eb5f0cb --- /dev/null +++ b/results/classifier/gemma3:12b/files/136 @@ -0,0 +1,2 @@ + +windows qemu-img create vpc/vhdx error diff --git a/results/classifier/gemma3:12b/files/1360 b/results/classifier/gemma3:12b/files/1360 new file mode 100644 index 00000000..79dd7909 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1360 @@ -0,0 +1,20 @@ + +Starting using WSL fails even if the same image is valid when starting qemu directly from windows +Description of problem: +I'm trying to follow a rust tutorial on writing a custom OS in rust. https://os.phil-opp.com/minimal-rust-kernel/ +The problem occurse when trying to run qemu from wsl. If I run qemu from a windows command line everything works as expected. +If I run the os calling qemu (installed on windows) from wsl it fails with + +``` +ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +Bail out! ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +``` + +I also found an old bug report that seemed to be the same issue in the old issue tracker: https://bugs.launchpad.net/qemu/+bug/1893807 +Steps to reproduce: +1. Sample code can be found at `https://github.com/phil-opp/blog_os` branch: `post-02` +2. create wsl environment +3. run `cargo install bootimage` only required on the once to install bootimage +4. run `cargo build` +5. run `cargo bootimage` to create the image +6. `qemu-system-x86_64 -drive format=raw,file=target/x86_64-blog_os/debug/bootimage-blog-os.bin` diff --git a/results/classifier/gemma3:12b/files/1366 b/results/classifier/gemma3:12b/files/1366 new file mode 100644 index 00000000..322ee709 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1366 @@ -0,0 +1,85 @@ + +Data inconsistency on LVM logical volume mounted as partition on ubuntu guest, when the written file's size is equal or greater than 27G. +Description of problem: +On the guest, writing a 27Gib file or larger result in inconsistent file checksum upon subsequent read. +Steps to reproduce: +**On the host** + +0. Create a LVM logical volume on a Linux RAID 1 (with 1 disk only) + +``` + --- Logical volume --- + LV Path /dev/davidahw2-vg4/lv0 + LV Name lv0 + VG Name davidahw2-vg4 + LV UUID 5FbDcl-eSDe-7cXL-22tj-Lg6O-79AL-4Gq7gx + LV Write Access read/write + LV Creation host, time davida-hw2, 2021-12-06 16:45:00 +0800 + LV Status available + # open 1 + LV Size <7.28 TiB + Current LE 1907688 + Segments 1 + Allocation inherit + Read ahead sectors auto + - currently set to 256 + Block device 253:4 + + --- Segments --- + Logical extents 0 to 1907687: + Type linear + Physical volume /dev/md4 + Physical extents 0 to 1907687 +``` + +1. Format the logical volume as ext4 + +``` +mkfs -t ext4 /dev/davidahw2-vg4/lv0 +``` + +2. Create a libvirt x86 64bits Ubuntu 22.04 machine mounting a LVM logical volume + +``` +<controller type='scsi' index='1' model='virtio-scsi'><driver queues='8' iothread='2'/></controller> + + +<disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/davidahw2-vg4/lv0'/> + <target dev='sdd' bus='scsi'/> + <blockio logical_block_size='512' physical_block_size='4096'/> + <address type='drive' controller='1' bus='0' target='1' unit='0'/> +</disk> +``` + + +**On the guest** + +3. Mount libvirt/qemu provided block device /dev/sdd as ext4 partition + +``` +mount /dev/sdd /mnt/test +``` + +4. Write **27G file** or larger **on the guest** causing the **2nd checksum to be different** + +``` +sync; head -c 27G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +8d3b4b263961d2c510390f99879be89b4b9134dc588139ede75573be1590115b myfile +a8e886b3c39d9b4721e582c5e2ca25c76ff6561750ac6dc7aa7e70404661d1cf myfile <== ERROR: Inconsistent checksum +``` + +5. Write **26G file** or larger **on the guest** and **both checksum are the same** + +``` +sync; head -c 26G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile <== CORRECT: Consistent checksum +``` + +**Important**: +- With the VM shutdown, the same commands on the same mounted ext4 partition **on the host** has consistent checksum every time for file sizes from 20G to 40G. +- The disk has no sign of failure (no badblocks reported to the filesystem, MD raid reports a healthy raid setup, smart reports on error) +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1367365 b/results/classifier/gemma3:12b/files/1367365 new file mode 100644 index 00000000..22b30a8b --- /dev/null +++ b/results/classifier/gemma3:12b/files/1367365 @@ -0,0 +1,10 @@ + +qemu-img fixed vhd issues + +qemu-img returns fixed vhd images file format to be raw. + +This happens because only the header is seeked for image signatures when getting the image format. In fact, unlike dynamic vhd images, differencing vhds don't have the footer copied in the header. + +An easy fix would be to just search the last 512B for the 'conectix' signature. + +Also, the fixed vhds created by qemu-img seem to be corrupted from Powershell POV. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1368815 b/results/classifier/gemma3:12b/files/1368815 new file mode 100644 index 00000000..af572da9 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1370585 b/results/classifier/gemma3:12b/files/1370585 new file mode 100644 index 00000000..81eb0c1c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1370585 @@ -0,0 +1,8 @@ + +qemu-img cannot create fixed vhdx + +When trying to create a fixed vhdx image, qemu-img fails with the following error: + + qemu-img: test.vhdx: Could not create image: Cannot allocate memory + +This happens because of a incorrect check in vhdx.c \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1371915 b/results/classifier/gemma3:12b/files/1371915 new file mode 100644 index 00000000..0deadcae --- /dev/null +++ b/results/classifier/gemma3:12b/files/1371915 @@ -0,0 +1,9 @@ + +Make Uninstall Rule Requested + +Environment: Ubuntu 14.04 - Qemu 2.1.1 +------------------ +I've configured qemu with some --prefix, compiled the sources and installed the binaries; now, for some reason, I need to uninstall qemu to configure it with the default prefix, recompile the sources and reinstall the binaries. +However, there's no rule to uninstall qemu. + +All other packages which I have compiled and installed on my system offer the possibility to uninstall it: why not Qemu? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1373362 b/results/classifier/gemma3:12b/files/1373362 new file mode 100644 index 00000000..38a3991b --- /dev/null +++ b/results/classifier/gemma3:12b/files/1373362 @@ -0,0 +1,28 @@ + +qemu-2.1.1 i386-softmmu compile error: q35_dsdt_applesmc_sta undeclared + +I try to compile qemu-2.1.1 (Gentoo/x86), but the i386-softmmu fails to compile: + + CPP i386-softmmu/q35-acpi-dsdt.dsl.i.orig + ACPI_PREPROCESS i386-softmmu/q35-acpi-dsdt.dsl.i + IASL i386-softmmu/q35-acpi-dsdt.dsl.i + ACPI_EXTRACT i386-softmmu/q35-acpi-dsdt.off + CAT i386-softmmu/hw/i386/q35-acpi-dsdt.hex + CC i386-softmmu/hw/i386/acpi-build.o +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c: In function 'acpi_get_dsdt': +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: error: 'q35_dsdt_applesmc_sta' undeclared (first use in this function) + applesmc_sta = q35_dsdt_applesmc_sta; + ^ +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: note: each undeclared identifier is reported only once for each function it appears in +make[1]: *** [hw/i386/acpi-build.o] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + +Something seems to go wrong when generating the file i386-softmmu/hw/i386/q35-acpi-dsdt.hex: + +# grep -r q35_dsdt_applesmc_sta ../ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../hw/i386/acpi-build.c: applesmc_sta = q35_dsdt_applesmc_sta; +../hw/i386/q35-acpi-dsdt.dsl:#define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1376938 b/results/classifier/gemma3:12b/files/1376938 new file mode 100644 index 00000000..682550b9 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1376938 @@ -0,0 +1,19 @@ + +detect-zeroes=unmap fails to discard in some cases + +Under certain circumstances, QEMU 2.1.2 fails to discard the underlaying block. The command to start QEMU is: + +qemu-system-x86_64 -machine pc,accel=kvm -m 2G -smp 2 -vga std -usb -usbdevice tablet -drive if=none,id=ff,aio=native,discard=unmap,detect-zeroes=unmap,file=/tmp/test.qcow2 -device virtio-scsi-pci -device scsi-disk,drive=ff -cdrom /media/iso/archlinux-2014.06.01-dual.iso -vnc :1 + +Steps to reproduce: + + 0. qemu-img create -f qcow2 /tmp/test.qcow2 4G + 1. Boot in the guest (Arch Linux x86_64 with Linux 3.14.4) + 2. cat /dev/zero > /dev/sda. Observe a file of 4109M (size measured with `du -m` + 3. cat /dev/zero > /dev/sda + 4. blkdiscard /dev/sda + 5. Observe that test.qcow2 grows larger than 1M (13M in my testing). + +The results are more severe when you write other kind of data in step 2, for instance `base64 /dev/zero > /dev/sda` and then continuing with step 3 and 4 will result in a file of 3642M, after blkdiscard. + +It makes not much of a difference if I create an ext4 filesystem on top of it and use fstrim (or rm). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1387 b/results/classifier/gemma3:12b/files/1387 new file mode 100644 index 00000000..f3755c4f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1387 @@ -0,0 +1,10 @@ + +QEMU - Add in the FAQ info how to compile Windows x86/x64 installer under Linux Ubuntu +Description of problem: +Please add in the FAQ + +https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds + +detailed info step by stepo how to create windows x86 and x64 instalelr under Ubuntu +Steps to reproduce: + diff --git a/results/classifier/gemma3:12b/files/1388 b/results/classifier/gemma3:12b/files/1388 new file mode 100644 index 00000000..aa67d82f --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1399191 b/results/classifier/gemma3:12b/files/1399191 new file mode 100644 index 00000000..23df7bda --- /dev/null +++ b/results/classifier/gemma3:12b/files/1399191 @@ -0,0 +1,40 @@ + +Large VHDX image size + +We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + +Why is that the VHDX generates large sized images for both the formats? + +The following commands were used to convert the vmdk image to VHDX format + +1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk Test-fixed.vhdx + +qemu-img info Test-fixed.vhdx +image: Test-fixed.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + + + +2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + +qemu-img info Test-dynamic.vhdx +image: Test-dynamic.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + +We tried this with the following version of qemu +1. qemu-2.0.0 +2. qemu-2.1.2 +3. qemu-2.2.0-rc4 + + +Please let us know how to create compact VHDX images using qemu-img. +Thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1401798 b/results/classifier/gemma3:12b/files/1401798 new file mode 100644 index 00000000..e4c72997 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1401798 @@ -0,0 +1,26 @@ + +Qemu 2.2.0 savevm crash. + +qemu 2.1.2 is good. + +(gdb) bt +#0 0x00007ffff4aae445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ffff4ab1bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000555555997951 in qcow2_cache_find_entry_to_replace (c=0x555556389780) at block/qcow2-cache.c:262 +#3 0x0000555555997a1a in qcow2_cache_do_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528, + read_from_disk=true) at block/qcow2-cache.c:285 +#4 0x0000555555997c45 in qcow2_cache_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528) + at block/qcow2-cache.c:331 +#5 0x0000555555991ca9 in l2_allocate (bs=0x5555563836f0, l1_index=1, table=0x7fffffffc5a0) at block/qcow2-cluster.c:247 +#6 0x000055555599290c in get_cluster_table (bs=0x5555563836f0, offset=549755813888, new_l2_table=0x7fffffffc610, + new_l2_index=0x7fffffffc62c) at block/qcow2-cluster.c:620 +#7 0x0000555555994213 in discard_single_l2 (bs=0x5555563836f0, offset=549755813888, nb_clusters=156, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1425 +#8 0x0000555555994491 in qcow2_discard_clusters (bs=0x5555563836f0, offset=549755813888, nb_sectors=638976, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1516 +#9 0x00005555559965c8 in qcow2_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/qcow2-snapshot.c:441 +#10 0x00005555559ad1ad in bdrv_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/snapshot.c:167 +#11 0x000055555565e90f in do_savevm (mon=0x555556992d20, qdict=0x5555599d5c00) at /vms/qemu/qemu-2.2.0/savevm.c:1126 + +(gdb) show args +Argument list to give program being debugged when it is started is "-name u1404-01 -S -machine pc,accel=kvm,usb=off -m 1024 -smp 2,sockets=2,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/u1404-01.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6". \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1403 b/results/classifier/gemma3:12b/files/1403 new file mode 100644 index 00000000..3732da14 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1403 @@ -0,0 +1,2 @@ + +qemu 7.2: test-io-channel-command fails sporadically diff --git a/results/classifier/gemma3:12b/files/1410288 b/results/classifier/gemma3:12b/files/1410288 new file mode 100644 index 00000000..3f72fd7a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/142 b/results/classifier/gemma3:12b/files/142 new file mode 100644 index 00000000..9265cb93 --- /dev/null +++ b/results/classifier/gemma3:12b/files/142 @@ -0,0 +1,2 @@ + +qemu -readconfig/-writeconfig cannot handle quotes in values diff --git a/results/classifier/gemma3:12b/files/1422307 b/results/classifier/gemma3:12b/files/1422307 new file mode 100644 index 00000000..bce0328d --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1429034 b/results/classifier/gemma3:12b/files/1429034 new file mode 100644 index 00000000..f628702a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1434779 b/results/classifier/gemma3:12b/files/1434779 new file mode 100644 index 00000000..8e90d1ac --- /dev/null +++ b/results/classifier/gemma3:12b/files/1434779 @@ -0,0 +1,29 @@ + +qemu hangs on live-migration with storage(virtual machine: windows Server 2008 with only one disk ) + +Hi, +We are using “Windows Server 2008” with qemu-kvm-2.0.1 (linux kernel:3.10.0) as a host of a VM. +Using drive_mirror to do live-migration on the same host for different disks +Local disk: /sf/data/local/ +Shared disk(iscsi): /sf/other/local/ --- the disk is busy, the IO rate is about 30MB/s +qemu-system-x86_64 -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm -drive file=/sf/data/local/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 + +Step 1: +Start migration: Drive_mirror -f drive-ide0 /sf/other/local/test.qcow2 + +Step 2: +When detect the migration has completed, then send cmd: block_job_complete -f drive-ide0 + +Step 3: +send cmd: info status +What surprised me is that the qemu monitor reports can’t be connected. + +Then find bellows: +The qemu process hangs on the mirror_run->bdrv_drain_all->aio_poll->qemu_poll_ns->ppoll (), +None events were received and poll forever. I don’t know why the aio can’t be responsed. This case is hardly to +be generated but it really happens sometimes . I’m looking forward to getting help from you . +The stack capture snapshot: + + +Thanks +MyAngle \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1443 b/results/classifier/gemma3:12b/files/1443 new file mode 100644 index 00000000..de87dbea --- /dev/null +++ b/results/classifier/gemma3:12b/files/1443 @@ -0,0 +1,2 @@ + +site download.qemu.org | non-adequate function applied for sorting by date-time diff --git a/results/classifier/gemma3:12b/files/1449687 b/results/classifier/gemma3:12b/files/1449687 new file mode 100644 index 00000000..2ec029f5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1449687 @@ -0,0 +1,8 @@ + +block migration of qcow2 VMs copies all empty space + +I'm running openstack 2012.1 'icehouse' which, ultimately, calls down into qemu-system-x86 2.0.0+dfsg-2ubuntu1.10. + +I primed the process by copying all necessary base images onto the destination host. Nonetheless, post-migration instances are much larger than the original image; the copy duplicated all the empty space that ought to have remained copy-on-write. + +It looks like there was some attempt to address this issue in the past (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1058173 ) but perhaps I'm conflating two different issues. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/145 b/results/classifier/gemma3:12b/files/145 new file mode 100644 index 00000000..1c17cd6d --- /dev/null +++ b/results/classifier/gemma3:12b/files/145 @@ -0,0 +1,2 @@ + +Issues with qemu-img, libgfapi, and encryption at rest diff --git a/results/classifier/gemma3:12b/files/1450891 b/results/classifier/gemma3:12b/files/1450891 new file mode 100644 index 00000000..3224763b --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1452062 b/results/classifier/gemma3:12b/files/1452062 new file mode 100644 index 00000000..1be2110d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1452062 @@ -0,0 +1,33 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1452230 b/results/classifier/gemma3:12b/files/1452230 new file mode 100644 index 00000000..7c9b37df --- /dev/null +++ b/results/classifier/gemma3:12b/files/1452230 @@ -0,0 +1,20 @@ + +Qemu 2.3.0 failes to compile with GCC 5.1.0 and -flto + +Compiling Qemu 2.3.0 failes with the following error: + +x86_64-pc-linux-gnu-g++ -I/usr/include/pixman-1 -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/libusb-1.0 -I/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/tests -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-z,relro -Wl,-z,now -pie -m64 -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-znow -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--enable-new-dtags -o qemu-img qemu-img.o async.o thread-pool.o nbd.o block.o blockjob.o main-loop.o iohandler.o qemu-timer.o aio-posix.o qemu-io-cmds.o qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o qemu-coroutine-sleep.o coroutine-ucontext.o block/raw_bsd.o block/qcow.o block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o block/vhdx-endian.o block/vhdx-log.o block/parallels.o block/blkdebug.o block/blkverify.o block/block-backend.o block/snapshot.o block/qapi.o block/raw-posix.o block/linux-aio.o block/null.o block/mirror.o block/nbd.o block/nbd-client.o block/sheepdog.o block/accounting.o block/write-threshold.o block/curl.o libqemuutil.a libqemustub.a -lz -lbz2 -laio -lcurl -lm -lgthread-2.0 -pthread -lglib-2.0 -lz -lrt -lz -lcap-ng -luuid -lutil +lto1: error: two or more sections for .gnu.lto_fprintf.2f4a95b725db6827 +(null):0: confused by earlier errors, bailing out +make[1]: *** [/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/temp/ccEUT6Vq.ltrans11.ltrans.o] Error 1 +make[1]: *** Waiting for unfinished jobs.... +lto-wrapper: fatal error: make returned 2 exit status +compilation terminated. +/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed +collect2: error: ld returned 1 exit status +/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/rules.mak:122: recipe for target 'qemu-img' failed +make: *** [qemu-img] Error 1 + +I've found an old GCC bugreport with the same error: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 (which has been marked as dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000) . I was able to reduce the object list to to three .o files which reproduce the error reliably: qemu-img.o qemu-io-cmds.o block/qapi.o. + +Please let me know if you need further information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1459622 b/results/classifier/gemma3:12b/files/1459622 new file mode 100644 index 00000000..925fe3fd --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1462640 b/results/classifier/gemma3:12b/files/1462640 new file mode 100644 index 00000000..6c633d31 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1462640 @@ -0,0 +1,36 @@ + +shmat fails on 32-to-64 setup + + +I am trying to run a guest mips32 program (user mode) on a x86_64 host. The program fails on a call to shmat() reproducibly. when digging into this problem, I could make a small guest POC that fails when compiled as i386 (-m32) running on a x86_64 host, but pass when compiled as 64bit. The problem has to do with mmap flags. + +From what I can understand, when running 32bits guests programs, qemu reserve the whole guest virtual space with an mmap call. That mmap call specifys MAP:PRIVATE flag. When shmat is called, it tries to make part of that region MAP_SHARED and that fails. + +As a possible fix, it looks like it is possible to first unmap the shm region before calling shmat. + +steps to reproduce: +1 - create a file shm.c with content below +2 - compile with: gcc -m32 shm.c -o shm32 +3 - run on a x86_64 host: qemu-i386 ./shm32 +4 - observe shmat fails, by returning ptr -1 + +5- compile without -m32: : gcc shm.c -o shm64 +6 - observe it pass: qemu-x84_64 ./shm64 + + + +#include <sys/ipc.h> +#include <sys/shm.h> +#include <sys/mman.h> +#include <stdio.h> + +int main() +{ + struct shmid_ds shm_desc; + int err = 0; + int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666); + err = shmctl(id, IPC_STAT, &shm_desc); + const void *at = 0x7f7df38ea000; + void* ptr = shmat(id, at, 0); + printf( "got err %d, ptr %p\n", err, ptr ); +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1463812 b/results/classifier/gemma3:12b/files/1463812 new file mode 100644 index 00000000..a0da98b4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1463812 @@ -0,0 +1,5 @@ + +qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption + +copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +Run the image on qemu 1.5.3, no problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1464 b/results/classifier/gemma3:12b/files/1464 new file mode 100644 index 00000000..bf4e5e8d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1464 @@ -0,0 +1,4 @@ + +qemu-img resize fails due to inconsistent bitmap(s) +Additional information: +This is on a oVirt env diff --git a/results/classifier/gemma3:12b/files/1467 b/results/classifier/gemma3:12b/files/1467 new file mode 100644 index 00000000..c0f2c3a6 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1467 @@ -0,0 +1,2 @@ + +guest agent file filtering diff --git a/results/classifier/gemma3:12b/files/1470481 b/results/classifier/gemma3:12b/files/1470481 new file mode 100644 index 00000000..f688dab4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1470481 @@ -0,0 +1,8 @@ + +qemu-img converts large vhd files into only approx. 127GB raw file causing the VM to crash + +I have a VHD file for Windows 2014 server OS. I use the following command to convert VHD file (20GB) to a RAW file for KVM. + +qemu-img convert -f vpc -O raw WIN-SNRGCQV6O3O.VHD disk.img + +The output file is about 127GB. When install the VM and boot it up, the OS crashes with STOP error after the intial screen. I found on the internet that the file limit of 127GB is an existing bug. Kindly fix the problem. The workaround to use a Hyper-V to convert to fixed disk is not a feasible solution. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1474263 b/results/classifier/gemma3:12b/files/1474263 new file mode 100644 index 00000000..865ed3dc --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1475 b/results/classifier/gemma3:12b/files/1475 new file mode 100644 index 00000000..54ddbd53 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1475 @@ -0,0 +1,15 @@ + +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +Description of problem: +Mixing driver=https with an http URL gives this assert fail in glib2: + +``` +$ ~/d/qemu/build/qemu-img convert -p -W -f qcow2 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }' -O raw jammy-server-cloudimg-amd64.img.raw +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed +qemu-img: Could not open 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }': https curl driver cannot handle the URL 'http://oirase.annexia.org/tmp/jammy-server-cloudimg-amd64.qcow2' (does not start with 'https://') +``` + +(It seems to be a warning rather than a crash) +Steps to reproduce: +1. Run the command above. diff --git a/results/classifier/gemma3:12b/files/1481654 b/results/classifier/gemma3:12b/files/1481654 new file mode 100644 index 00000000..4880136e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1481654 @@ -0,0 +1,39 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1484990 b/results/classifier/gemma3:12b/files/1484990 new file mode 100644 index 00000000..316295b1 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1490611 b/results/classifier/gemma3:12b/files/1490611 new file mode 100644 index 00000000..8c4af689 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1500265 b/results/classifier/gemma3:12b/files/1500265 new file mode 100644 index 00000000..26339ab8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1500265 @@ -0,0 +1,6 @@ + +nested 9p filesystem with security_model=mapped-xattr + +I do not know whether this is a bug or a feature request, but on a 9p virtfs with security_model=mapped-xattr, access to extended attributes starting with "user.virtfs" coming from the guest seem to be silently ignored. Would it not be more correct to use some sort of "escaping", say map to "user.virtfs.x" on guest to "user.virtfs.virtfs.x" on host or something like that, so that the guest can use arbitrary attributes. + +In particular, this would allow nested virtual machines to use nested 9p virtfs with security_model=mapped-xattr. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1502095 b/results/classifier/gemma3:12b/files/1502095 new file mode 100644 index 00000000..956d8e5a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1502095 @@ -0,0 +1,39 @@ + +Sporadic input / output error — x86-64 linux guest + +** Setup: ** + +→ Host + Qemu version 2.4.0.1 + Linux: 4.1.1 (Debian 8.2, GCC 4.9.2, x86_64) + filesystem ext3 and ext4 + +→ Guests (3 VMs) + architecture x86_64, Linux 3.16.0-4-amd64 (Debian 7.6) + virtual disk qcow2, uncompressed + guests filesystem ext3 + virtual disks size: VM1: 3GB, VM2: 5GB, VM3: 250GB + +→ Network + bridge (br0) and tap interfaces. + + +** Command line ** + +For all 3 VMs, the command line is similar to the following. Only RAM size and ID ("109") are changed. + + /usr/local/bin/qemu-system-x86_64 -hda /media/raid1/qemu-109 -m 8G -smp 4 -enable-kvm \ + -netdev bridge,id=br109 -device virtio-net-pci,netdev=br109,id=nic0,mac=00:00:00:00:01:09 \ + -k it -daemonize + + +** Problem ** + +Sporadic, unexplained input output error. +When I try to SSH to one of the instances, most of the times everything just works fine. Some other times, the SSH connection can be established, but as I interact with the guests via SSH (ls, cd, top) the guest reports "input / output error" on the SSH console. Sometimes, the SSH daemon on the guest answers "/bin/bash input output error". Sometimes the SSH client answers that the connection has been dropped by the host. + +When this happens, the web services I run on the VMs get unreachable, the VMs themselves are unreachable/unusable via SSH as described, and after killing the relative qemu processes and restarting the VMs, no recent logs are registered on /var/logs, arguably since the time of the crash. + +This only happens to one VM at a time, independently. The other VMs appear to run fine when one VM encounters the problem. + +I which instructions to further debug this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1507 b/results/classifier/gemma3:12b/files/1507 new file mode 100644 index 00000000..e72333d8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1507 @@ -0,0 +1,38 @@ + +export/fuse/fuse.c:fuse_fallocate does not do anything but returns success +Description of problem: +block/export/fuse.c:fuse_fallocate with `FALLOC_FL_PUNCH_HOLE` does not do anything even though it returns 0 (success). A later read incorrectly returns old data instead of zeros. +Should probably return EOPNOTSUPP. + +FALLOC_FL_PUNCH_HOLE: +>Within the specified range, partial filesystem blocks are zeroed, +and whole filesystem blocks are removed from the file. After a +successful call, subsequent reads from this range will return +zeros. +https://man7.org/linux/man-pages/man2/fallocate.2.html +Steps to reproduce: +```sh +touch /tmp/data /tmp/fuse_exp +dd if=/dev/random of=/tmp/data count=1000 bs=1M +qemu-storage-daemon --blockdev node-name=node0,driver=raw,file.driver=file,file.filename=/tmp/data --export type=fuse,id=node0-export,node-name=node0,mountpoint=/tmp/fuse_exp,writable=on + +hexdump /tmp/fuse_exp -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 +fallocate -l 1G --punch-hole /tmp/fuse_exp +echo $? +# 0 +hexdump /tmp/fuse_exp -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 + + +hexdump /tmp/data -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 +fallocate -l 1G --punch-hole /tmp/data +hexdump /tmp/data -n 16 +# 0000000 0000 0000 0000 0000 0000 0000 0000 0000 + +# sudo bpftrace -e 'uretprobe:/usr/bin/qemu-storage-daemon:blk_co_pdiscard { printf("ret=%d\n",retval); }' +# ret=0 +# sudo bpftrace -e 'kretfunc:fuse_file_fallocate { printf("len=%d \t mode=%d ret=%d\n", args->length , args->mode,retval); }' +# len=1073741824 mode=3 ret=0 +``` diff --git a/results/classifier/gemma3:12b/files/152 b/results/classifier/gemma3:12b/files/152 new file mode 100644 index 00000000..d52a3b27 --- /dev/null +++ b/results/classifier/gemma3:12b/files/152 @@ -0,0 +1,2 @@ + +qemu-img compare -m option is missing diff --git a/results/classifier/gemma3:12b/files/1524546 b/results/classifier/gemma3:12b/files/1524546 new file mode 100644 index 00000000..a8378567 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1538541 b/results/classifier/gemma3:12b/files/1538541 new file mode 100644 index 00000000..b90d4713 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1538541 @@ -0,0 +1,26 @@ + +qcow2 rejects request to use preallocation with backing file + +The 'preallocation=full' option to qemu-img / qcow2 block driver instructs QEMU to fully allocate the host file to the maximum size needed by the logical disk size. + +$ qemu-img create -f qcow2 -o preallocation=full base.qcow2 200M +Formatting 'base.qcow2', fmt=qcow2 size=209715200 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 + +$ ls -alhs base.qcow2 +201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2 + + +When specifying a backing file for the qcow2 file, however, it rejects the preallocation request + +$ qemu-img create -f qcow2 -o preallocation=full,backing_file=base.qcow2 front.qcow2 200M +Formatting 'front.qcow2', fmt=qcow2 size=209715200 backing_file='base.qcow2' encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 +qemu-img: front.qcow2: Backing file and preallocation cannot be used at the same time + + +It might seem like requesting full preallocation is redundant because most data associated with the image will be present in the backing file, as so the top layer is unlikely to ever need the full preallocation. Rejecting this, however, means it is not (officially) possible to reserve disk space for the top layer to guarantee that future copy-on-writes will never get ENOSPC. + +OpenStack in particular uses backing files with all images, in order to avoid the I/O overhead of copying the backing file contents into the per-VM disk image. It, however, still wants to have a guarantee that the per-VM image will never hit an ENOSPC scenario. + +Currently it has to hack around QEMU's refusal to allow backing_file + preallocation, by calling 'fallocate' on the qcow2 file after it has been created. This is an inexact fix though, because it doesn't take account of fact that qcow2 metadata can takes some MBs of space. + +Thus, it would like to see preallocation=full supported in combination with backing files. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/154 b/results/classifier/gemma3:12b/files/154 new file mode 100644 index 00000000..35976dd5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/154 @@ -0,0 +1,2 @@ + +readlink(2) returns incorrect size for /proc/self/exe diff --git a/results/classifier/gemma3:12b/files/1554 b/results/classifier/gemma3:12b/files/1554 new file mode 100644 index 00000000..8e26d830 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1554 @@ -0,0 +1,7 @@ + +I want get a qemu-img tool,which can run in Any linux operating system, what can i do? +Description of problem: +As we known,qemu-img depends on many dynamic libraries,it can't run in other os if libraries is not support.whether qemu can use static compilation to solve this problem？ + + +i refer to this [issue 1190](https://gitlab.com/qemu-project/qemu/-/issues/1190),but when compile over,it not generate a static qemu-img. Or it has other functions to get a qemu-img which can run in Any linux operating system? diff --git a/results/classifier/gemma3:12b/files/1554451 b/results/classifier/gemma3:12b/files/1554451 new file mode 100644 index 00000000..225952ff --- /dev/null +++ b/results/classifier/gemma3:12b/files/1554451 @@ -0,0 +1,15 @@ + +unable to create preallocated image with gluster network protocol + +Unable to create preallocated image with gluster protocol + +Version: qemu-img-0.12.1.2-2.479.el6.x86_64 +Platform: RHEL 6 +I have tried creating preallocated image as follows : + +qemu-img create -f qcow2 -o preallocation=full gluster://localhost/vol1/vm1.img 10G + +I see error a follows : +[root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://localhost/rep3vol/vm1.img 5G +Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' +Unknown option 'preallocation' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1561 b/results/classifier/gemma3:12b/files/1561 new file mode 100644 index 00000000..7b1709b7 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1561 @@ -0,0 +1,28 @@ + +Compile QEMU 6.2.0 fail for file not found +Description of problem: +Compile QEMU failed with error message: +``` +In file included from ../subprojects/libvhost-user/libvhost-user.c:45: +../subprojects/libvhost-user/libvhost-user.h:23:10: Fatal error：standard-headers/linux/virtio_ring.h：no such file or directory + 23 | #include "standard-headers/linux/virtio_ring.h" + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``` +Steps to reproduce: +1. Download qemu-6.2.0 tarball at https://download.qemu.org/qemu-6.2.0.tar.xz +2. unzip the tarball to dir ```qemu-6.2.0``` +2. cd ```qemu-6.2.0```, and then ```./configure && make -j2``` +Additional information: +In ```qemu-6.2.0/subprojects/libvhost-user/libvhost-user.c:45```, the included files are: + +``` +#include <stdint.h> +#include <stdbool.h> +#include <stddef.h> +#include <poll.h> +#include <linux/vhost.h> +#include <pthread.h> +#include "standard-headers/linux/virtio_ring.h" +``` + +```standard-headers``` are in ```qemu-6.2.0/include/standard-headers/```, but above #include assume it's in the same dir of ```libvhost-user.c```. diff --git a/results/classifier/gemma3:12b/files/1563931 b/results/classifier/gemma3:12b/files/1563931 new file mode 100644 index 00000000..3113b7a7 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1563931 @@ -0,0 +1,7 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1564 b/results/classifier/gemma3:12b/files/1564 new file mode 100644 index 00000000..6dfc6f03 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1564 @@ -0,0 +1,71 @@ + +stat64 on sparc64 failed to get correct major/minor dev +Description of problem: +The reported device major/minor is not correct, e.g: stat /dev/zero: +Reported: Device type: 0,10500000 +Correct : Device type: 1,5 +Steps to reproduce: +1. "stat /dev/zero" or "ls -l /dev/zero" +Additional information: +The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size): + +``` +--- qemu-20230327/linux-user/syscall_defs.h 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h.new 2023-03-27 21:43:25.615115126 +0200 +@@ -1450,7 +1450,7 @@ struct target_stat { + unsigned int st_dev; + abi_ulong st_ino; + unsigned int st_mode; +- unsigned int st_nlink; ++ short int st_nlink; + unsigned int st_uid; + unsigned int st_gid; + unsigned int st_rdev; +@@ -1465,8 +1465,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + uint64_t st_nlink; +@@ -1476,14 +1475,13 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ unsigned int __pad0; ++ uint64_t st_rdev; + + int64_t st_size; + int64_t st_blksize; + +- unsigned char __pad4[4]; +- unsigned int st_blocks; ++ int64_t st_blocks; + + abi_ulong target_st_atime; + abi_ulong target_st_atime_nsec; +@@ -1522,8 +1520,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + +@@ -1533,8 +1530,7 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ uint64_t st_rdev; + + unsigned char __pad3[8]; +``` diff --git a/results/classifier/gemma3:12b/files/1566 b/results/classifier/gemma3:12b/files/1566 new file mode 100644 index 00000000..1da381e9 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1566 @@ -0,0 +1,10 @@ + +qemo-8-0-0-rc2 error: redeclaration of 'enum fsconfig_command' +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1570134 b/results/classifier/gemma3:12b/files/1570134 new file mode 100644 index 00000000..4d15fb9d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1570134 @@ -0,0 +1,172 @@ + +While committing snapshot qemu crashes with SIGABRT + +Information: + +OS: Slackware64-Current +Compiled with: gcc version 5.3.0 (GCC) / glibc 2.23 +Compiled using: + +CFLAGS="-O2 -fPIC" \ +CXXFLAGS="-O2 -fPIC" \ +LDFLAGS="-L/usr/lib64" \ +./configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libdir=/usr/lib64 \ + --enable-spice \ + --enable-kvm \ + --enable-glusterfs \ + --enable-libiscsi \ + --enable-libusb \ + --target-list=x86_64-softmmu,i386-softmmu \ + --enable-debug + +Source: qemu-2.5.1.tar.bz2 + +Running as: + +/usr/bin/qemu-system-x86_64 -name test1,debug-threads=on -S -machine pc-1.1,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 4b30ec13-6609-4a56-8731-d400c38189ef -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-test1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/datastore/vm/test1/test1.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net pci,netdev=hostnet0,id=net0,mac=52:54:00:66:2e:0f,bus=pci.0,addr=0x3 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +File system: zfs v0.6.5.6 + +While running: +virsh blockcommit test1 vda --active --pivot --verbose + +VM running very heavy IO load + +GDB reporting: + +#0 0x00007fd80132c3f8 in raise () at /lib64/libc.so.6 +#1 0x00007fd80132dffa in abort () at /lib64/libc.so.6 +#2 0x00007fd801324c17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007fd801324cc2 in () at /lib64/libc.so.6 +#4 0x000055d9918d7572 in bdrv_replace_in_backing_chain (old=0x55d993ed9c10, new=0x55d9931ccc10) at block.c:2096 + __PRETTY_FUNCTION__ = "bdrv_replace_in_backing_chain" +#5 0x000055d991911869 in mirror_exit (job=0x55d993fef830, opaque=0x55d999bbefe0) at block/mirror.c:376 + to_replace = 0x55d993ed9c10 + s = 0x55d993fef830 + data = 0x55d999bbefe0 + replace_aio_context = <optimized out> + src = 0x55d993ed9c10 +#6 0x000055d9918da1dc in block_job_defer_to_main_loop_bh (opaque=0x55d9940ce850) at blockjob.c:481 + data = 0x55d9940ce850 + aio_context = 0x55d9931a2610 +#7 0x000055d9918d014b in aio_bh_poll (ctx=ctx@entry=0x55d9931a2610) at async.c:92 + bh = <optimized out> + bhp = <optimized out> + next = 0x55d99440f910 + ret = 1 +#8 0x000055d9918dc8c0 in aio_dispatch (ctx=0x55d9931a2610) at aio-posix.c:305 + node = <optimized out> + progress = false +#9 0x000055d9918d000e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at async.c:231 + ctx = <optimized out> +#10 0x00007fd8037cf787 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 +#11 0x000055d9918db03b in main_loop_wait () at main-loop.c:211 + context = 0x55d9931a3200 + pfds = <optimized out> + ret = 0 + spin_counter = 1 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#12 0x000055d9918db03b in main_loop_wait (timeout=<optimized out>) at main-loop.c:256 + ret = 0 + spin_counter = 1 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#13 0x000055d9918db03b in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:504 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#14 0x000055d991679cc4 in main () at vl.c:1923 + nonblocking = <optimized out> + last_io = 2 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 49 + optarg = 0x7fffc6d27f43 "timestamp=on" + loadvm = <optimized out> + machine_class = 0x55d993194d10 + cpu_model = <optimized out> + vga_model = 0x0 + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = false + log_mask = <optimized out> + log_file = <optimized out> + trace_events = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" +#15 0x000055d991679cc4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4699 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 49 + optarg = 0x7fffc6d27f43 "timestamp=on" + loadvm = <optimized out> + machine_class = 0x55d993194d10 + cpu_model = <optimized out> + vga_model = 0x0 + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = false + log_mask = <optimized out> + log_file = <optimized out> + trace_events = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" + + + +I can reproduce this at will, and can provide more information per a dev's request. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1581976 b/results/classifier/gemma3:12b/files/1581976 new file mode 100644 index 00000000..628632a5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1581976 @@ -0,0 +1,17 @@ + +man qemu contains a bug in description of "-virtfs" command line argument + +The description of command line argument looks like this: + + -virtfs + fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model][,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd] + + +note, that there is no "id" attribute in the list of parameters. + +later on the man there the "id" attribute is documented, as it were present: + + id=id + Specifies identifier for this device + +i think that it was copied from above section (about "-fsdev") without reviewing. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1587065 b/results/classifier/gemma3:12b/files/1587065 new file mode 100644 index 00000000..18b6ac44 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1587065 @@ -0,0 +1,51 @@ + +btrfs qemu-ga - multiple mounts block fsfreeze + +Having two mounts of the same device makes fsfreeze through qemu-ga impossible. +root@CmsrvMTA:/# mount -l | grep /dev/vda2 +/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) +/dev/vda2 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home) + +Having two mounts is rather common with btrfs, so the feature fsfreeze is unusable on these systems. + + +Below more information about how we encountered this issue... + +Message send to <email address hidden>: + +Message 1: +---------- +I use external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. + +With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: +"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" + +I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately after each other: + +$ grep qemu-ga syslog.1 +May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called + +This is the only entry of the qemu guest agent in syslog. + +$ sudo virsh version +Compiled against library: libvirt 1.3.1 +Using library: libvirt 1.3.1 +Gebruikte API: QEMU 1.3.1 +Draaiende hypervisor: QEMU 2.5.0 + +$ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}' +{"return":{"version":"2.5.0", ... ,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, ... } + +For making an external snapshot, I use this command: +$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1 + +Piece of reply 1: +----------------- +I have encountered this before. Some operating systems + may have bind-mounts that let a device appear multiple times in the mount list. Unfortunately the guest agent is not smart enough to consider a device that has been frozen as succesfull and keep going. This causes this specific error. + +Piece of reply 2: +----------------- +Ok, that seems to be it. + +I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on two separate sub volumes. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1592590 b/results/classifier/gemma3:12b/files/1592590 new file mode 100644 index 00000000..fbb99c1a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1595240 b/results/classifier/gemma3:12b/files/1595240 new file mode 100644 index 00000000..50813210 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1595240 @@ -0,0 +1,19 @@ + +Error by clone github.com qemu repository + +Hi. + +C:\Java\sources\kvm> git clone https://github.com/qemu/qemu.git +Cloning into 'qemu'... +remote: Counting objects: 279563, done. +remote: Total 279563 (delta 0), reused 0 (delta 0), pack-reused 279563R +Receiving objects: 100% (279563/279563), 122.45 MiB | 3.52 MiB/s, done. +Resolving deltas: 100% (221942/221942), done. +Checking connectivity... done. +error: unable to create file hw/misc/aux.c (No such file or directory) +error: unable to create file include/hw/misc/aux.h (No such file or directory) +Checking out files: 100% (4795/4795), done. +fatal: unable to checkout working tree +warning: Clone succeeded, but checkout failed. +You can inspect what was checked out with 'git status' +and retry the checkout with 'git checkout -f HEAD' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1596870 b/results/classifier/gemma3:12b/files/1596870 new file mode 100644 index 00000000..298f4a8b --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1599 b/results/classifier/gemma3:12b/files/1599 new file mode 100644 index 00000000..29e61373 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1599 @@ -0,0 +1,10 @@ + +7.2.1 - Windows installer +Description of problem: +Please release windows installer for new stable version 7.2.1 in + +https://www.qemu.org/download/ +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1599539 b/results/classifier/gemma3:12b/files/1599539 new file mode 100644 index 00000000..de0ef055 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/162 b/results/classifier/gemma3:12b/files/162 new file mode 100644 index 00000000..2ad8ab13 --- /dev/null +++ b/results/classifier/gemma3:12b/files/162 @@ -0,0 +1,2 @@ + +util/path.c/follow_path() does not handle "/" well diff --git a/results/classifier/gemma3:12b/files/1625 b/results/classifier/gemma3:12b/files/1625 new file mode 100644 index 00000000..ce5a8cef --- /dev/null +++ b/results/classifier/gemma3:12b/files/1625 @@ -0,0 +1,14 @@ + +[7.2.0] Qemu process hang with `defunct` when using `-blockdev` json property which file doesn't exists +Description of problem: +When using `throttle` and `throttle-group` to apply block device QOS, +there is something wrong with check file exists validation. +In upper commands, if the file which located `/mnt/b3b8dfb5-0a7c-4285-81d8-2bf8d33a3297/32c55f5a-96d1-4af4-a149-c95fd6652e3e/b016af76-f6b1-4614-b29a-78917924e55e` doesn't exist, it just hang with `defunct` process. + +Steps to reproduce: +1. Start Guest with upper command. +2. Hanged with defunct process +3. +Additional information: + +- With GDB stack, i can find `no such file` error, but process don't exit diff --git a/results/classifier/gemma3:12b/files/1626 b/results/classifier/gemma3:12b/files/1626 new file mode 100644 index 00000000..865e025b --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1634852 b/results/classifier/gemma3:12b/files/1634852 new file mode 100644 index 00000000..50222eba --- /dev/null +++ b/results/classifier/gemma3:12b/files/1634852 @@ -0,0 +1,47 @@ + +Qemu VirtFS mounts are not accessible after resuming guest from hibernation + +Host OS: Funtoo Linux +Host Kernel: 4.7.4-gentoo +Qemu Version: 2.7.0 +Guest OS: Ubuntu 14.04 +Guest Kernel: reproduced with both 4.4.0-42-generic and 3.13.0-98-generic + +Qemu command line: + +qemu-system-x86_64 \ + -machine type=pc,accel=kvm \ + -cpu host \ + -smp 3 \ + -m 8G \ + -netdev bridge,id=hn0,vhost=on \ + -device virtio-net-pci,netdev=hn0,mac=52:54:fa:70:35:f7 \ + -drive file=/dev/mapper/vg-ubuntu,format=raw,if=virtio,cache=none,discard=on \ + -virtfs local,path=/home/dharding/code,security_model=passthrough,mount_tag=code \ + -virtfs local,path=/home/dharding/xfer,security_model=passthrough,mount_tag=xfer \ + -display gtk + + +Relevant lines from guest /etc/fstab: +code /home/dharding/code 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0 +xfer /home/dharding/xfer 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0 + + +Steps to reproduce: +- start qemu using the above command line +- in the guest, run "sudo pm-hibernate" +- after qemu exits, run again using the same command line +- once the guest resumes from hibernation, run "ls /home/dharding/code" +- the ls command will hang forever + +The ls call stack is: + +[<ffffffffc00743a0>] p9_client_rpc+0x110/0x460 [9pnet] +[<ffffffffc0076a50>] p9_client_getattr_dotl+0x60/0x160 [9pnet] +[<ffffffffc009ef77>] v9fs_vfs_getattr_dotl+0x47/0xa0 [9p] +[<ffffffff81202a5c>] vfs_getattr_nosec+0x2c/0x40 +[<ffffffff81202b26>] vfs_getattr+0x26/0x30 +[<ffffffff81202bf5>] vfs_fstatat+0x65/0xa0 +[<ffffffff8120306f>] SYSC_newstat+0x1f/0x40 +[<ffffffff812032be>] SyS_newstat+0xe/0x10 +[<ffffffff817fa4f6>] entry_SYSCALL_64_fastpath+0x16/0x75 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1638 b/results/classifier/gemma3:12b/files/1638 new file mode 100644 index 00000000..e4bc7afb --- /dev/null +++ b/results/classifier/gemma3:12b/files/1638 @@ -0,0 +1,20 @@ + +BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together +Description of problem: +Segmentation Fault while booting VM. +Steps to reproduce: +1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G` +2. +3. +Additional information: +It might not be a bug, probably a feature. +The reason of this segfault is: +readonly would mmap the backend file using PROT_READ, make it readonly, +but the prealloc=on would touch_pages the memory mmaped by the file. +SO the segfault happens. + +But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.) + +And maybe there is a way to solve this problem, I think. +Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory. +change the prot to readonly if required. diff --git a/results/classifier/gemma3:12b/files/1639225 b/results/classifier/gemma3:12b/files/1639225 new file mode 100644 index 00000000..0b602c5d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1639225 @@ -0,0 +1,133 @@ + +qcow2 - filesize 8.1Petabyte + + +problem : + +Filesystem Size Used Avail Use% Mounted on + +/dev/sdd1 120G 63G 57G 53% /storage/kvmstorage4ssd + +# pwd +/storage/kvmstorage4ssd/images + +# qemu-img info vsys19_ssd1.qcow2 +image: vsys19_ssd1.qcow2 +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 11G +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: true +# ls -lah vsys19_* +-rw------- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2 + +# ls -la vsys19_* +-rw------- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2 + +# qemu-img check vsys19_ssd1.qcow2 +qemu-img: Check failed: File too large + +# xfs_repair /dev/sdd1 +Phase 1 - find and verify superblock... +Phase 2 - using internal log + - zero log... + - scan filesystem freespace and inode maps... + - found root inode chunk +Phase 3 - for each AG... + - scan and clear agi unlinked lists... + - process known inodes and perform inode discovery... + - agno = 0 + - agno = 1 + - agno = 2 + - agno = 3 + - process newly discovered inodes... +Phase 4 - check for duplicate blocks... + - setting up duplicate extent list... + - check for inodes claiming duplicate blocks... + - agno = 0 + - agno = 1 + - agno = 2 + - agno = 3 +Phase 5 - rebuild AG headers and trees... + - reset superblock... +Phase 6 - check inode connectivity... + - resetting contents of realtime bitmap and summary inodes + - traversing filesystem ... + - traversal finished ... + - moving disconnected inodes to lost+found ... +Phase 7 - verify and correct link counts... +done + + +# pwd +/storage/kvmstorage4ssd/images + + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/storage/kvmstorage4ssd/images/vsys19_ssd1.qcow2'/> + <target dev='vdn' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/> + </disk> + + +guest OS: + + +# uname -a +Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux +cat /etc/debian_version +stretch/sid + +Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272 +Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s +tarting block 1085897) +Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897 +Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898 +Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899 +Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900 +Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901 +Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902 +Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903 +Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904 +Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905 +Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906 +Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280 +Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023) +Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288 +Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149) +Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296 +Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275) +Nov 4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304 +Nov 4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401) + +KVM host : +# cat /etc/debian_version +stretch/sid + +Debian + + +# uname -a +Linux asus1 4.5.5-custom #1 SMP Sun May 22 21:14:57 CEST 2016 x86_64 GNU/Linux + +# dpkg -l | grep -i qemu +ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1 all PXE boot firmware - ROM images for qemu +ii qemu 1:2.5+dfsg-5+b1 amd64 fast processor emulator +ii qemu-kvm 1:2.5+dfsg-5+b1 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20151103+dfsg-2 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-mips 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (miscelaneous) +ii qemu-system-ppc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (x86) +ii qemu-user 1:2.5+dfsg-5+b1 amd64 QEMU user mode emulation binaries +ii qemu-user-binfmt 1:2.5+dfsg-5+b1 amd64 QEMU user mode binfmt registration for qemu-user +ii qemu-utils 1:2.5+dfsg-5+b1 amd64 QEMU utilities +ii qemubuilder 0.80 amd64 pbuilder using QEMU as backend \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1644754 b/results/classifier/gemma3:12b/files/1644754 new file mode 100644 index 00000000..b519d851 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1655764 b/results/classifier/gemma3:12b/files/1655764 new file mode 100644 index 00000000..1d308e95 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1661758 b/results/classifier/gemma3:12b/files/1661758 new file mode 100644 index 00000000..194baf3b --- /dev/null +++ b/results/classifier/gemma3:12b/files/1661758 @@ -0,0 +1,118 @@ + +qemu-nbd causes data corruption in VDI-format disk images + +Hi, + +This is a duplicate of #1422307. I can't figure out a way to re-open +it--the status of "Fix Released" is changeable only by a project +maintainer or bug supervisor--so I'm opening a new bug to make sure +this gets looked at again. + +qemu-nbd will sometimes corrupt VDI disk images. The bug was thought +to be fixed in commit f0ab6f109630940146cbaf47d0cd99993ddba824, but +I'm able to reproduce it in both that commit and in the latest commit +(a951316b8a5c3c63254f20a826afeed940dd4cba). I just needed to run more +iterations of the test. It's possible that it was partially fixed, or +that the added serialization made it harder to catch this +non-deterministic bug, but the same symptoms persist: data corruption +of VDI-format disk images. + +This affects at least qemu-nbd. I haven't tried reproducing the issue +with qemu proper or qemu-img, but the original bug report suggests +that the bug in the common VDI backend may corrupt data written by +those programs. + +Please let me know if I can provide any further information or help +with testing. Thank you very much for looking into this! + +Test procedure +************** + +The procedure used is the one given by Max Reitz (xanclic) in the +original bug report, comment 3 +(https://bugs.launchpad.net/qemu/+bug/1422307/comments/3), in the +section "VDI and NBD over /dev/nbd0", but with up to 1000 iterations +instead of 10: + + $ cd ~/qemu-origfix-f0ab6f1/bin + $ dd if=/dev/urandom of=blob.raw bs=1M count=64 + 64+0 records in + 64+0 records out + 67108864 bytes (67 MB) copied, 4.36475 s, 15.4 MB/s + $ sudo sh -c 'for i in $(seq 0 999); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; ./qemu-nbd -c /dev/nbd0 test.vdi; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo "done"' +27a66c3a8ac2cf06f2c925968ea9e964 test1.raw +2da9bf169041a7c2bd144c4ab3a29aea test2.raw +64 failed +done + +I've run this process a handful of times, and I've seen it take as +little as 10 iterations and as many as 161 (taking 32 minutes in the +latter case). Please be patient. Putting the images on tmpfs will +probably help it go faster, and I have successfully reproduced the +issue on tmpfs in addition to ext4. + +Nothing different was needed to reproduce the issue in a directory +containing a build of the latest commit. It still takes somewhere +around 1-200 iterations to find, in my testing. + +Build procedure +*************** + + $ git clone git://git.qemu-project.org/qemu.git + [omitted] + $ git clone qemu qemu-origfix-f0ab6f1 + Cloning into 'qemu-origfix-f0ab6f1'... + done. + $ cd qemu-origfix-f0ab6f1 + $ git checkout f0ab6f109630940146cbaf47d0cd99993ddba824 + Note: checking out 'f0ab6f109630940146cbaf47d0cd99993ddba824'. + + You are in 'detached HEAD' state. You can look around, make experimental + changes and commit them, and you can discard any commits you make in this + state without impacting any branches by performing another checkout. + + If you want to create a new branch to retain commits you create, you may + do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b new_branch_name + + HEAD is now at f0ab6f1... block/vdi: Add locking for parallel requests + $ mkdir bin + $ cd bin + $ script -c'time (../configure --enable-debug --target-list=x86_64-softmmu && make -j6; echo "result: $?")' + Script started, file is typescript + [omitted; the build typescript is attached separately] + LINK x86_64-softmmu/qemu-system-x86_64 + result: 0 + + real 1m5.733s + user 2m3.904s + sys 0m13.828s + Script done, file is typescript + +Nothing different was done when building the latest commit (besides +cloning to a different directory, and not running `git checkout`). + +Environment +*********** + + * Machine: x86_64 + + * Hypervisor: Xen 4.4 (Debian package xen-hypervisor-4.4-amd64, + version 4.4.1-9+deb8u8) + + * A Xen domU (guest) for building QEMU and reproducing the issue. + All testing was done within the virtual machine for convenience + and access to better hardware than what I have for my development + machine (I expected the build to take much longer than it really + does). + + - x86_64 architecture with six VCPUs and 1.2 GiB RAM allocated, + operating in HVM (fully virtualized) mode. + + - Distribution: Debian 8.7 Jessie amd64 + + - Kernel: Linux 3.16.0 x86_64 (Debian package + linux-image-3.16.0-4-amd64, version 3.16.39-1) + + - Compiler: GCC 4.9.2 (Debian package gcc-4.9, version 4.9.2-10) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1662050 b/results/classifier/gemma3:12b/files/1662050 new file mode 100644 index 00000000..c0405bcb --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1662468 b/results/classifier/gemma3:12b/files/1662468 new file mode 100644 index 00000000..9b9b5f64 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1662468 @@ -0,0 +1,4 @@ + +[feature request] qemu-img convert should respond to control-T like dd + +Since qemu-img convert is a long-running operation, it would be nice if it reported progress in response to control-T (SIGINFO) to show progress information, much like dd, fsck, dump, cp, etc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1665344 b/results/classifier/gemma3:12b/files/1665344 new file mode 100644 index 00000000..7a3987a5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1665344 @@ -0,0 +1,11 @@ + +documentation error:404 not found + +In http://wiki.qemu-project.org/Outreachy_2017_MayAugust the urls + http://www.qemu-project.org/images/4/4e/Q35.pdf and http://www.qemu-project.org/images/f/f6/PCIvsPCIe.pdf on opening displays: + + + + Not Found + +The requested URL /images/4/4e/Q35.pdf was not found on this server. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1668360 b/results/classifier/gemma3:12b/files/1668360 new file mode 100644 index 00000000..dd356998 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1668360 @@ -0,0 +1,4 @@ + +Documentation error :404 not found + +In http://wiki.qemu-project.org/Documentation/GettingStartedDevelopers the url http://www.linux-kvm.org/wiki/images/1/17/2010-forum-qmp-status-talk.pp.pdf displays a 404 NOt found error. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1672365 b/results/classifier/gemma3:12b/files/1672365 new file mode 100644 index 00000000..b2be9cd0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1672365 @@ -0,0 +1,47 @@ + +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? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1673957 b/results/classifier/gemma3:12b/files/1673957 new file mode 100644 index 00000000..13031a0d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1673957 @@ -0,0 +1,18 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1673976 b/results/classifier/gemma3:12b/files/1673976 new file mode 100644 index 00000000..2a0e3998 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1673976 @@ -0,0 +1,12 @@ + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) + +I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. + +locale-gen +Generating locales... + en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale + +I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1676 b/results/classifier/gemma3:12b/files/1676 new file mode 100644 index 00000000..4b10b0f5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1676 @@ -0,0 +1,8 @@ + +Signed release tarball for 8.0.2 is missing +Description of problem: +Hi! I package QEMU for Arch Linux. I usually rely on the signed tarballs (which are also linked to from the website). +For [8.0.2](https://gitlab.com/qemu-project/qemu/-/tags/v8.0.2) there does not seem to be a signed tarball though. +Steps to reproduce: +1. Try to update to 8.0.2 using a signed tarball +2. Find no signed tarball in https://download.qemu.org/ diff --git a/results/classifier/gemma3:12b/files/1684239 b/results/classifier/gemma3:12b/files/1684239 new file mode 100644 index 00000000..5c521b5c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1686364 b/results/classifier/gemma3:12b/files/1686364 new file mode 100644 index 00000000..c0a8e491 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1686364 @@ -0,0 +1,18 @@ + +qemu -readconfig/-writeconfig cannot handle quotes in values + +$ qemu-system-x86_64 -drive file=/tmp/foo\" -writeconfig - +# qemu config file + +[drive] + file = "/tmp/foo"" + +For bonus points, try to construct a value qemu config file that contains a quoted value. It's pretty clear (from looking at the code also) that this is not possible. + +Also: + +- maximum value length is hard-coded in the parser at 1023 characters (for no apparent reason) + +- the format is undocumented + +- don't use sscanf for parsing! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1687270 b/results/classifier/gemma3:12b/files/1687270 new file mode 100644 index 00000000..1dfc1382 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1689 b/results/classifier/gemma3:12b/files/1689 new file mode 100644 index 00000000..dface34c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1690 b/results/classifier/gemma3:12b/files/1690 new file mode 100644 index 00000000..79ac3add --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1690322 b/results/classifier/gemma3:12b/files/1690322 new file mode 100644 index 00000000..1f5fc120 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1690322 @@ -0,0 +1,15 @@ + +errors which can't backing storage for guest RAM with -mem-path + +I found it can't backup the guest RAM when i run simple ram test code with + +errors which can't backing storage for guest RAM with integratorcp, the commander is: + +qemu-system-arm -M integratorcp -m 1 -semihosting -nographic -mem-path mem.txt -kernel build/emu_ram_test.elf + +i wrote the patter "0x55" to all of the rest of RAM in my test, after run my test code, it just generate the 1048576 Bytes file, i split these file into 2kB, most of split file is black, some of them just display \00 after open with gedit. + +i don't know whether my commander is incorrect, anyone can confirm it for me? i just want to write the guest RAM and read it from host during the guest code is running. but my guest just has simple os without file system and network. so i want to try with this backend RAM ways. + +thanks. +js \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1695 b/results/classifier/gemma3:12b/files/1695 new file mode 100644 index 00000000..1a58914d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1695 @@ -0,0 +1,12 @@ + +Latest Windows MSI does not include libssp-0.dll +Description of problem: +The latest Qemu MSI installer for Windows (https://qemu.weilnetz.de/w64/2023/qemu-w64-setup-20230530.exe) does not include libssp-0.dll, which is why the executables fail to run. + +This Mingw library should be included when building the MSI if stack protection is enabled. +Steps to reproduce: +1. Install the latest qemu MSI +2. Try to invoke any qemu command +3. Use Dependency Walker to easily find missing dependencies (https://www.dependencywalker.com/) +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1695169 b/results/classifier/gemma3:12b/files/1695169 new file mode 100644 index 00000000..675d974c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1696180 b/results/classifier/gemma3:12b/files/1696180 new file mode 100644 index 00000000..6d89a85c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1696180 @@ -0,0 +1,20 @@ + +Issues with qemu-img, libgfapi, and encryption at rest + +Hi, + +Encryption-at-rest has been supported for some time now. The client is responsible for encrypting the files with a help of a master key file. I have a properly setup environment and everything appears to be working fine but when I use qemu-img to move a file to gluster I get the following: + + +# qemu-img convert -f raw -O raw linux.iso gluster://gluster01/virt0/linux.raw +[2017-06-06 16:52:25.489720] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.490778] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.492263] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.497226] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_create+0x44d) [0x7f30f7a3cf5d] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL + +On and on until I get this message: + +[2017-06-06 17:00:03.467361] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-0: All subvolumes are down. Going offline until atleast one of them comes back up. +[2017-06-06 17:00:03.467442] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-1: All subvolumes are down. Going offline until atleast one of them comes back up. + +I asked for help assuming it's a problem with glusterfs and was told it appears qemu-img's implementation of libgfapi doesn't call the xlator function correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1701973 b/results/classifier/gemma3:12b/files/1701973 new file mode 100644 index 00000000..f9878b94 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1701974 b/results/classifier/gemma3:12b/files/1701974 new file mode 100644 index 00000000..87b72d8d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1701974 @@ -0,0 +1,18 @@ + +pwrite does not work right under qemu-sh4 + +The pwrite system call has no effect when writing to a non-zero file position, 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-pwrite test-pwrite.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-pwrite + +Expected output: +buf = 01W3456789 + +Actual output: +buf = 0123456789 +test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1704658 b/results/classifier/gemma3:12b/files/1704658 new file mode 100644 index 00000000..5f421560 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1704658 @@ -0,0 +1,21 @@ + +O_CLOEXEC not handled in dup3 system call in user mode + +In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag. + +When the attached program runs, the expected output is: +errno=9=EBADF + +How to reproduce on hppa: +- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa +- Set environment variables for running qemu-hppa. +- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed + +How to reproduce on sparc64: +- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64 +- Set environment variables for running qemu-sparc64. +- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64 +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1706825 b/results/classifier/gemma3:12b/files/1706825 new file mode 100644 index 00000000..6abad192 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1706825 @@ -0,0 +1,13 @@ + +qemu-user fails to run wineserver on ppc64el host + +When attempting to run wineserver on a 64-bit ppc64el host via QEMU's user-mode i386 emulation, a file locking operation fails. + +Command line: +qemu-i386-static /usr/lib/wine-development/wineserver32 + +Output: +wineserver: fcntl /tmp/.wine-0/server-17-14d21bf/lock: Invalid argument + +Relevant portion of strace: +fcntl(6, F_SETLK64, 0x3fffe8802218) = -1 EINVAL (Invalid argument) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1708442 b/results/classifier/gemma3:12b/files/1708442 new file mode 100644 index 00000000..f1dcdf8d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1708442 @@ -0,0 +1,77 @@ + +Crash(assert) during reading image from http url through qemu-nbd + +Description: +During reading image from nbd device mounted by qemu-nbd server with url backend I/O error happens +"blk_update_request: I/O error, dev nbd0, sector 42117" dmesg. After some investigation I found that qemu-nbd server aborts in aio_co_enter() assert in util/async.c:468. + + +Steps to reproduce: + +1) sudo go run qemu-nbd-bug-report/qemu-nbd-bug.go (see qemu-nbd-bug-report.tar.gz) + +or try directly + +1) qemu-nbd -c /dev/nbd0 -r -v --aio=native -f qcow2 json:{"file.driver":"http","file.url":"http://localhost:9666/image","file.readahead":3276800 +2) try read whole nbd device while error in dmesg appears x + +Versions: + +1) qemu built from sources(/configure --target-list=x86_64-softmmu --disable-user --enable-curl --enable-linux-aio --enable-virtfs --enable-debug --disable-pie +, top commit 5619c179057e24195ff19c8fe6d6a6cbcb16ed28): + +qemu-nbd -v +qemu-nbd 2.9.90 (v2.10.0-rc0-67-g5619c17) + +2) libcurl(built from sources, top commit 1767adf4399bb3be29121435e1bb1cc2bc05f7bf): + +curl -V +curl 7.55.0-DEV (Linux) libcurl/7.55.0-DEV OpenSSL/1.0.2g zlib/1.2.8 + + +Backtrace: +(gdb) bt +#0 0x00007f7131426428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f713142802a in __GI_abort () at abort.c:89 +#2 0x00007f713141ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x54c924 "self != co", + file=file@entry=0x54c871 "util/async.c", line=line@entry=468, + function=function@entry=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:92 +#3 0x00007f713141ec82 in __GI___assert_fail (assertion=0x54c924 "self != co", file=0x54c871 "util/async.c", line=468, + function=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:101 +#4 0x00000000004fe6a2 in aio_co_enter (ctx=0xf0ddb0, co=0xf14650) at util/async.c:468 +#5 0x00000000004fe637 in aio_co_wake (co=0xf14650) at util/async.c:456 +#6 0x0000000000495c8a in curl_read_cb (ptr=0xf566d9, size=1, nmemb=16135, opaque=0xf1cb90) at block/curl.c:275 +#7 0x00007f713242ac24 in Curl_client_chop_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +#8 0x00007f713242ae03 in Curl_client_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +#9 0x00007f713244e1cf in readwrite_data () from /usr/lib/x86_64-linux-gnu/libcurl.so +#10 0x00007f713244eb6f in Curl_readwrite () from /usr/lib/x86_64-linux-gnu/libcurl.so +#11 0x00007f713245c1bb in multi_runsingle () from /usr/lib/x86_64-linux-gnu/libcurl.so +#12 0x00007f713245d819 in multi_socket () from /usr/lib/x86_64-linux-gnu/libcurl.so +#13 0x00007f713245e067 in curl_multi_socket_action () from /usr/lib/x86_64-linux-gnu/libcurl.so +#14 0x0000000000497555 in curl_setup_preadv (bs=0xf16820, acb=0x7f712d379860) at block/curl.c:918 +#15 0x00000000004975fb in curl_co_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/curl.c:935 +#16 0x000000000047730f in bdrv_driver_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:836 +#17 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1be20, req=0x7f712d379a60, offset=6556160, bytes=512, align=1, + qiov=0x7f712d379b40, flags=0) at block/io.c:1086 +#18 0x0000000000478109 in bdrv_co_preadv (child=0xf1be20, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:1180 +#19 0x0000000000437498 in qcow2_co_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/qcow2.c:1812 +#20 0x000000000047730f in bdrv_driver_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/io.c:836 +#21 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1c0d0, req=0x7f712d379d30, offset=21563904, bytes=512, align=1, + qiov=0x7f712d379e80, flags=0) at block/io.c:1086 +#22 0x0000000000478109 in bdrv_co_preadv (child=0xf1c0d0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/io.c:1180 +#23 0x00000000004645ad in blk_co_preadv (blk=0xf1be90, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/block-backend.c:991 +#24 0x00000000004646fa in blk_read_entry (opaque=0x7f712d379ea0) at block/block-backend.c:1038 +#25 0x000000000046481c in blk_prw (blk=0xf1be90, offset=21563904, +---Type <return> to continue, or q <return> to quit--- + buf=0xf7f000 "2,NV\241t!\ti\312\vp\364\017Kl*\354\021\a\177\021\260\b\027\212\347\027\004\322\nG\340b\\\306pG\332\313\060\341;\002\360\063L\240\027T \211\341\305\022АE\230\356DǮ}\211\bx\016\a\b\313\350\316\064.\017\372\032-R\376z\261\263\350|cQ<\016S_L\340A\221\366~L#\001+\271\204\065~\327\023\027I\211\343\361\276zT$4\336\273ˏ\353ʪ\234\016_Z|TMk\"\370\002\363~\334\332.\a\375\265mӌ{/%\304֎\374sF<E\371\031o&\202\217\226\276>I\356\302\375F\340\332\324\021\202\232>\026\261\233\303tv\023\304\006\243\037\062BϏ\b\324rs\360'"..., bytes=512, co_entry=0x4646aa <blk_read_entry>, flags=0) at block/block-backend.c:1074 +#26 0x0000000000464f81 in blk_pread (blk=0xf1be90, offset=21563904, buf=0xf7f000, count=512) at block/block-backend.c:1227 +#27 0x00000000004906cb in nbd_trip (opaque=0xf5a940) at nbd/server.c:1380 +#28 0x000000000051c0a5 in coroutine_trampoline (i0=15812176, i1=0) at util/coroutine-ucontext.c:79 +#29 0x00007f713143b5d0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#30 0x00007f712d47a770 in ?? () +#31 0x0000000000000000 in ?? () +Backtrace stopped: Cannot access memory at address 0x7f712d37a000 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1709170 b/results/classifier/gemma3:12b/files/1709170 new file mode 100644 index 00000000..bd68ec05 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1709170 @@ -0,0 +1,12 @@ + +QEMU fails to honor O_TMPFILE + +When making a call like + + open("/tmp", O_TMPFILE | O_RDWR); + +under QEMU, we ged -EISDIR. + +Under any kernel 3.11 or later, we are supposed to get an unnamed file in /tmp. In case the filesystem for /tmp does not support unnamed files, we are supposed to get EOPNOTSUPP. + +[I don't know the QEMU version, since this happened in a system I don't have access to] \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1711316 b/results/classifier/gemma3:12b/files/1711316 new file mode 100644 index 00000000..71217b18 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1711316 @@ -0,0 +1,84 @@ + +fbsd strip(1) segfaults on aarch64 + +Hello, + +During port builds ld.lld(devel/boost-libs, www/node), and strip (textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes these things do work, as they should: + +root@build-aarch64:~ # strip xmlcatalog +Segmentation fault (core dumped) + +All the cores fail at the same assembly instruction, here's strip's backtrace: +# lldb -c strip.core strip +(lldb) target create "strip" --core "strip.core" +Core file '/root/strip.core' (aarch64) was loaded. +(lldb) t 1 +* thread #1, name = 'strip', stop reason = signal SIGSEGV + frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192 +libc.so.7`memcpy: +-> 0x40312f40 <+192>: ldp x4, x3, [x4, #-0x10] + 0x40312f44 <+196>: stp x6, x7, [x0] + 0x40312f48 <+200>: stp x8, x9, [x0, #0x10] + 0x40312f4c <+204>: stp x10, x11, [x0, #0x20] +(lldb) bt +* thread #1, name = 'strip', stop reason = signal SIGSEGV + * frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192 + frame #1: 0x000000004017ac70 libelf.so.2`_libelf_cvt_HALF_tom(dst=<unavailable>, dsz=<unavailable>, src=<unavailable>, count=<unavailable>, byteswap=<unavailable>) at libelf_convert.c:794 + frame #2: 0x0000000040177b34 libelf.so.2`elf_getdata(s=0x0000000040f355a0, ed=<unavailable>) at elf_data.c:155 + frame #3: 0x00000000000283d4 strip`copy_data(s=0x0000000040f36a40) at sections.c:1176 + frame #4: 0x0000000000027ea4 strip`copy_content(ecp=<unavailable>) at sections.c:594 + frame #5: 0x0000000000023ff4 strip`create_elf(ecp=0x0000000040ed6000) at main.c:381 + frame #6: 0x000000000002558c strip`create_file(ecp=<unavailable>, src=<unavailable>, dst=<unavailable>) at main.c:705 + frame #7: 0x0000000000024e20 strip`main [inlined] strip_main(argc=<unavailable>, argv=<unavailable>) at main.c:1192 + frame #8: 0x0000000000024cc8 strip`main(argc=<unavailable>, argv=<unavailable>) at main.c:1590 + frame #9: 0x0000000000020190 strip`__start + 376 + frame #10: 0x0000000040050018 ld-elf.so.1`.rtld_start at rtld_start.S:41 + +Host system information: +# uname -a +FreeBSD marvin.harmless.hu 11.0-STABLE FreeBSD 11.0-STABLE #0 r311927: Wed Jan 11 14:53:55 CET 2017 <email address hidden>:/usr/obj/usr/src/sys/MARVIN amd64 + +# qemu-system-aarch64 --version +QEMU emulator version 2.9.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +# pkg info | grep qemu +qemu-2.9.0 QEMU CPU Emulator +I also had this happening with 2.8.0 and 2.8.1 + +Guest information: +# uname -a +FreeBSD build-aarch64.marvin.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r322578: Wed Aug 16 18:08:43 CEST 2017 <email address hidden>:/tank/rpi3/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG arm64 + +Startup: +zdev=/dev/zvol/tank/rpi3/qemu-image +qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ + -accel tcg,thread=single \ + -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ + -drive if=none,file=${image},id=hd0,format=raw \ + -device virtio-blk-device,drive=hd0 \ + -device e1000,netdev=net0 \ + -netdev tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh + +Tested with cortex A53 as well, does the same. + +I've attached a test image to reproduce with (340MB), if it's too big for an attachment, it can be downloaded from here: +http://czg.harmless.hu/qemu-bug-stripsigsegv/image.gz + +Reproduction steps: +1) log in as root, no password +2) strip xmlcatalog, it will segfault + +For a full reproduction with ld.lld as well, you need a ports tree, it's suggested to attach a bigger volume to /usr/ports over NFS first (it might need more space than the image has). Steps for it: +1) portsnap fetch extract +2) make -C /usr/ports/devel/boost-libs package-recursive +3) make -C /usr/ports/textproc/libxml2 package-recursive +4) make -C /usr/ports/www/node package-recursive + +Boost and node can take a day or more in a qemu VM. The build-time options I've be set already, /var/db/ports is populated, so you shouldn't have questions asked during the builds. + +I've saved the core dumps, those can be found at /root/cores/ in the image. + +I hope I've submitted all the required information. If anything else is needed, please let me know. + +Best regards, +Gergely \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1714750 b/results/classifier/gemma3:12b/files/1714750 new file mode 100644 index 00000000..036f9894 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1715 b/results/classifier/gemma3:12b/files/1715 new file mode 100644 index 00000000..172e28e2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1715 @@ -0,0 +1,2 @@ + +qemu-img convert about target_is_new diff --git a/results/classifier/gemma3:12b/files/1716028 b/results/classifier/gemma3:12b/files/1716028 new file mode 100644 index 00000000..56edabde --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1716767 b/results/classifier/gemma3:12b/files/1716767 new file mode 100644 index 00000000..8ab7eea8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1716767 @@ -0,0 +1,35 @@ + +file(1) fails with "Invalid argument" on qemu-sh4-user + +We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file: + +(sid_sh4)root@vs94:/# file /bin/bash +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +Running with "-d" yields more output: + +(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail +322: >> 7 byte&,=97,"(ARM)"] +0 == 97 = 0 +mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1) +mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000 + +323: >> 7 byte&,=-1,"(embedded)"] +0 == 18446744073709551615 = 0 +[try softmagic 1] +[try elf -1] +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +It seems that the comparison above has a bogus (overflown?) value. + +On actual hardware, it works: + +root@tirpitz:~> file /bin/bash +/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped +root@tirpitz:~> + +I have uploaded a chroot with Debian unstable which allows to reproduce the issue: + +> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1719870 b/results/classifier/gemma3:12b/files/1719870 new file mode 100644 index 00000000..a4e4bf3f --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1720747 b/results/classifier/gemma3:12b/files/1720747 new file mode 100644 index 00000000..48fafaaf --- /dev/null +++ b/results/classifier/gemma3:12b/files/1720747 @@ -0,0 +1,8 @@ + +cannot extract release tarball on case-insensitive filesystems + +Extracting the release tarball for qemu-2.10.0 results in an error on case-insensitive filesystems because of the files qemu-2.10.0/roms/u-boot/scripts/Kconfig and qemu-2.10.0/roms/u-boot/scripts/kconfig. + +All other files are extracted correctly, and the resulting source can be built correctly. + +But tar returns with an error, which creates difficulties when trying to automate the build process (e.g: homebrew). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1721788 b/results/classifier/gemma3:12b/files/1721788 new file mode 100644 index 00000000..9aba20aa --- /dev/null +++ b/results/classifier/gemma3:12b/files/1721788 @@ -0,0 +1,17 @@ + +Failed to get shared "write" lock with 'qemu-img info' + +When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error + +qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. + + +Why does displaying information about a disk image need a write lock for the file? + +Steps to reproduce: + +qemu-img create -f qcow2 test.qcow2 10M +qemu-system-x86_64 -nographic -drive file=test.qcow2 +qemu-img info test.qcow2 + +The above was tested with Qemu version 2.10.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1723161 b/results/classifier/gemma3:12b/files/1723161 new file mode 100644 index 00000000..3baa584e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1723161 @@ -0,0 +1,32 @@ + +Migration failing in qemu-2.10.1 but working qemu-2.9.1 and earlier with same options + + +Qemu-2.10.1 migration failing with the following error: +Receiving block device images +qemu-system-x86_64: error while loading section id 2(block) +qemu-system-x86_64: load of migration failed: Input/output error + +Migration is setup on the destination system of the migration using: +-incoming tcp:0:4444 + +Migration is initiated from the source using the following commands in its qemu monitor: +migrate -b "tcp:localhost:4444" + +The command-line used in both the source and destination is: +qemu-system-x86_64 \ + -nodefaults \ + -pidfile vm0.pid \ + -enable-kvm \ + -machine q35 \ + -cpu host -smp 2 \ + -m 4096M \ + -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly \ + -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \ + -drive file=${HDRIVE},format=qcow2 \ + -drive media=cdrom \ + -usb -device usb-tablet \ + -vga std -vnc :0 \ + -net nic,macaddr=${TAPMACADDR} -net user,net=192.168.2.0/24,dhcpstart=192.168.2.10 \ + -serial stdio \ + -monitor unix:${MONITORSOCKET},server,nowait \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1726733 b/results/classifier/gemma3:12b/files/1726733 new file mode 100644 index 00000000..187231ea --- /dev/null +++ b/results/classifier/gemma3:12b/files/1726733 @@ -0,0 +1,11 @@ + +‘qemu-img info replication:’ causes segfault + +Typing the literal command ‘qemu-img info replication:’ causes a segfault. Note that ‘replication:’ is not a filename. + +$ ./qemu-img info replication: +qemu-img: block.c:2609: bdrv_open_inherit: Assertion `!!(flags & BDRV_O_PROTOCOL) == !!drv->bdrv_file_open' failed. +Aborted (core dumped) + +This was originally found by Han Han and reported in Fedora: +https://bugzilla.redhat.com/show_bug.cgi?id=1505652 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1727250 b/results/classifier/gemma3:12b/files/1727250 new file mode 100644 index 00000000..e321aa40 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1727250 @@ -0,0 +1,146 @@ + +qemu-io-test 147 segfaults when configured with gcov + +Head is at 3d7196d43bfe12efe98568cb60057e273652b99b + +Steps to re-produce: +1. git clone +./configure --enable-gcov --target-list=ppc64-softmmu +make +cd tests/qemu-iotests + +2. export qemu binary, in my environment +export QEMU_PROG=/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 + +3. Run test 147 with format qcow2 +./check -qcow2 147 + +QEMU -- "/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +147 0s ... [failed, exit status 1] - output mismatch (see 147.out.bad) +--- /home/nasastry/qemu/tests/qemu-iotests/147.out 2017-10-25 14:04:54.978600753 +0530 ++++ /home/nasastry/qemu/tests/qemu-iotests/147.out.bad 2017-10-25 14:09:53.769783770 +0530 +@@ -1,5 +1,95 @@ +-...... ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++FFFFFF ++====================================================================== ++FAIL: test_fd (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 203, in test_fd ++ self.client_test(filename, flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 146, in test_inet ++ flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet6 (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 171, in test_inet6 ++ self.client_test(filename, flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_unix (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 179, in test_unix ++ flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet (__main__.QemuNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 96, in test_inet ++ flatten_sock_addr(address)) ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_unix (__main__.QemuNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 103, in test_unix ++ flatten_sock_addr(address)) ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ + ---------------------------------------------------------------------- + Ran 6 tests + +-OK ++FAILED (failures=6) +Failures: 147 +Failed 1 of 1 tests + +With out gcov configured, the above test get pass. +export QEMU_PROG=/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64 +./check -qcow2 147 +QEMU -- "/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +147 +Passed all 1 tests \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1727259 b/results/classifier/gemma3:12b/files/1727259 new file mode 100644 index 00000000..c2fa76a0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1727259 @@ -0,0 +1,84 @@ + +qemu-io-test 58 segfaults when configured with gcov + +Head is at 3d7196d43bfe12efe98568cb60057e273652b99b + +Steps to re-produce: +1. git clone +./configure --enable-gcov --target-list=ppc64-softmmu +make +cd tests/qemu-iotests + +2. export qemu binary, in my environment +export QEMU_PROG=/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 + +3. Run test 58 with format qcow2 +./check -qcow2 58 + +QEMU -- "/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu_gcov/qemu-img" +QEMU_IO -- "/home/nasastry/qemu_gcov/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu_gcov/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu_gcov/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu_gcov/tests/qemu-iotests/socket_scm_helper + +058 1s ... - output mismatch (see 058.out.bad) +--- /home/nasastry/qemu_gcov/tests/qemu-iotests/058.out 2017-10-09 14:09:04.262726912 +0530 ++++ /home/nasastry/qemu_gcov/tests/qemu-iotests/058.out.bad 2017-10-25 15:00:52.037515025 +0530 +@@ -19,16 +19,28 @@ + 4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + + == verifying the exported snapshot with patterns, method 1 == +-read 4096/4096 bytes at offset 4096 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 4096/4096 bytes at offset 8192 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++./common.rc: line 66: 36255 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) ++./common.rc: line 66: 36262 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) + + == verifying the exported snapshot with patterns, method 2 == +-read 4096/4096 bytes at offset 4096 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 4096/4096 bytes at offset 8192 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++./common.rc: line 66: 36274 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) ++./common.rc: line 66: 36282 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) + + == verifying the converted snapshot with patterns, method 1 == + read 4096/4096 bytes at offset 4096 +Failures: 058 +Failed 1 of 1 tests + +with out gcov configured this test case is pass. +# ./check -qcow2 58 +QEMU -- "/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +058 0s ... +Passed all 1 tests \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1728116 b/results/classifier/gemma3:12b/files/1728116 new file mode 100644 index 00000000..f9541309 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1728116 @@ -0,0 +1,48 @@ + +Empty /proc/self/auxv (linux-user) + +The userspace Linux API virtualization used to fake access to /proc/self/auxv, to provide meaningful data for the guest process. + +For newer qemu versions, this fails: The openat() is intercepted, but there's no content: /proc/self/auxv has length zero (i.e. reading from it returns 0 bytes). + +Good: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +256 /proc/self/auxv + +Bad: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +0 /proc/self/auxv + +This worked in 2.7.1, and fails in 2.10.1. + +This causes e.g. any procps-ng-based tool to segfault while reading from /proc/self/auxv in an endless loop (probably worth another bug report...) + +Doing a "git bisect" shows that this commit: https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem. + +It might be a simple logic (subtraction in the wrong direction?) or sign-ness error: Adding some logging (to v2.10.1) + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 9b6364a..49285f9 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd) + abi_ulong len = ts->info->auxv_len; + char *ptr; + ++ gemu_log(TARGET_ABI_FMT_lu"\n", len); ++ gemu_log(TARGET_ABI_FMT_ld"\n", len); ++ + /* + * Auxiliary vector is stored in target process stack. + * read in whole auxv vector and copy it to file + +shows this output: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +18446744073709551264 +-352 +0 + +And 352 could be the expected length. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1728639 b/results/classifier/gemma3:12b/files/1728639 new file mode 100644 index 00000000..b6f973fd --- /dev/null +++ b/results/classifier/gemma3:12b/files/1728639 @@ -0,0 +1,100 @@ + +qemu-io crashes with SIGSEGV when did -c truncate 320000 on a image_fuzzer image + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "truncate 320000" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +723 if (drv->bdrv_getlength) { +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 +(gdb) bt full +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 + drv = 0x0 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 + local_err = 0x0 + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_open_driver" + __func__ = "bdrv_open_driver" +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 + ret = 16383 + open_flags = 24578 + filename = 0x1fe8e2b1 "copy.img" + driver_name = 0x1fe54810 "qcow2" + node_name = 0x0 + discard = 0x0 + detect_zeroes = 0x0 + opts = 0x1fe93100 + drv = 0x102036f0 <bdrv_qcow2> + local_err = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_common" + __func__ = "bdrv_open_common" +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 + ret = 512 + file = 0x1fe92540 + bs = 0x1fe86f60 + drv = 0x102036f0 <bdrv_qcow2> + drvname = 0x0 + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +No locals. +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 + blk = 0x1fe79410 + bs = 0x0 + perm = 3 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 + local_err = 0x0 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 + readonly = 0 + sopt = 0x101b2608 "hVc:d:f:rsnCmkt:T:U" + lopt = {{name = 0x101b26d0 "driver", has_arg = 0, flag = 0x0, val = 104}, {name = 0x101b26d8 "help", has_arg = 0, flag = 0x0, val = 86}, { + name = 0x101b26e0 "version", has_arg = 1, flag = 0x0, val = 99}, {name = 0x101b26e8 "cmd", has_arg = 1, flag = 0x0, val = 102}, { + name = 0x101b26f0 "format", has_arg = 0, flag = 0x0, val = 114}, {name = 0x101b2700 "y", has_arg = 0, flag = 0x0, val = 115}, { + name = 0x101b2710 "", has_arg = 0, flag = 0x0, val = 110}, {name = 0x101b2718 "nocache", has_arg = 0, flag = 0x0, val = 67}, { +---Type <return> to continue, or q <return> to quit--- + name = 0x101b2728 "read", has_arg = 0, flag = 0x0, val = 109}, {name = 0x101b2738 "", has_arg = 0, flag = 0x0, val = 107}, { + name = 0x101b2748 "io", has_arg = 1, flag = 0x0, val = 100}, {name = 0x101b2750 "discard", has_arg = 1, flag = 0x0, val = 116}, { + name = 0x101b2758 "cache", has_arg = 1, flag = 0x0, val = 84}, {name = 0x101b25e8 "object", has_arg = 1, flag = 0x0, val = 256}, { + name = 0x101b2760 "trace", has_arg = 0, flag = 0x0, val = 257}, {name = 0x101b1c48 "force-share", has_arg = 0, flag = 0x0, val = 85}, {name = 0x0, + has_arg = 0, flag = 0x0, val = 0}} + c = -1 + opt_index = 0 + flags = 16386 + writethrough = true + local_error = 0x0 + opts = 0x0 + format = 0x0 + trace_file = 0x0 + force_share = false +(gdb) +(gdb) quit + +Will attach image_fuzzer image. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1728643 b/results/classifier/gemma3:12b/files/1728643 new file mode 100644 index 00000000..0f73c413 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1728643 @@ -0,0 +1,105 @@ + +qemu-io fails with Assertion `*host_offset != 0' failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# cp test.img copy.img +# qemu-io <path to>/copy.img -c "write 884736 34816" + +from gdb: +(gdb) bt +#0 0x00003fffad63eff0 in raise () from /lib64/libc.so.6 +#1 0x00003fffad64136c in abort () from /lib64/libc.so.6 +#2 0x00003fffad634c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fffad634d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x000000001006426c in qcow2_alloc_cluster_offset (bs=0x391e9ad0, offset=884736, bytes=0x3fffaa89fb4c, host_offset=0x3fffaa89fb58, m=0x3fffaa89fb60) + at block/qcow2-cluster.c:1524 +#5 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=0) at block/qcow2.c:1919 +#6 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=16) at block/io.c:898 +#7 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x391f51a0, req=0x3fffaa89fdd8, offset=884736, bytes=34816, align=1, qiov=0x3fffce0e2940, flags=16) + at block/io.c:1440 +#8 0x00000000100ac4ac in bdrv_co_pwritev (child=0x391f51a0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/io.c:1691 +#9 0x000000001008da0c in blk_co_pwritev (blk=0x391d9410, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#10 0x000000001008db68 in blk_write_entry (opaque=0x3fffce0e2958) at block/block-backend.c:1110 +#11 0x00000000101aa444 in coroutine_trampoline (i0=958427472, i1=0) at util/coroutine-ucontext.c:79 +#12 0x00003fffad652b9c in makecontext () from /lib64/libc.so.6 +#13 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffad63eff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fffad64136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fffad634c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fffad634d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x000000001006426c in qcow2_alloc_cluster_offset (bs=0x391e9ad0, offset=884736, bytes=0x3fffaa89fb4c, host_offset=0x3fffaa89fb58, m=0x3fffaa89fb60) + at block/qcow2-cluster.c:1524 + s = 0x391f5d80 + start = 919552 + remaining = 0 + cluster_offset = 399360 + cur_bytes = 34816 + ret = 1 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#5 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=0) at block/qcow2.c:1919 + s = 0x391f5d80 + offset_in_cluster = 360448 + ret = 0 + cur_bytes = 34816 + cluster_offset = 0 + hd_qiov = {iov = 0x391b85a0, niov = 0, nalloc = 1, size = 0} + bytes_done = 0 + cluster_data = 0x0 + l2meta = 0x392074c0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#6 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 958319760 + nb_sectors = 2340082071 + ret = 743104256 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#7 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x391f51a0, req=0x3fffaa89fdd8, offset=884736, bytes=34816, align=1, qiov=0x3fffce0e2940, flags=16) + at block/io.c:1440 + bs = 0x391e9ad0 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 1796 + bytes_remaining = 34816 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#8 0x00000000100ac4ac in bdrv_co_pwritev (child=0x391f51a0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x391e9ad0 + req = {bs = 0x391e9ad0, offset = 884736, bytes = 34816, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 884736, + overlap_bytes = 34816, list = {le_next = 0x0, le_prev = 0x391ecd48}, co = 0x39207150, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fffaa89fe20}}, waiting_for = 0x0} + align = 1 +---Type <return> to continue, or q <return> to quit--- + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fffaa89fdb0, niov = -1433797136, nalloc = 16383, size = 884736} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#9 0x000000001008da0c in blk_co_pwritev (blk=0x391d9410, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x391e9ad0 +#10 0x000000001008db68 in blk_write_entry (opaque=0x3fffce0e2958) at block/block-backend.c:1110 + rwco = 0x3fffce0e2958 +#11 0x00000000101aa444 in coroutine_trampoline (i0=958427472, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x39207150, i = {958427472, 0}} + self = 0x39207150 + co = 0x39207150 +#12 0x00003fffad652b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#13 0x0000000000000000 in ?? () +No symbol table info available. + + +Will be attaching image_fuzzer images. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1728657 b/results/classifier/gemma3:12b/files/1728657 new file mode 100644 index 00000000..bebc2d08 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1728657 @@ -0,0 +1,116 @@ + +qemu-io: block/qcow2-cluster.c:1109: handle_copied: Assertion failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "write 4105728 2791936" + +from gdb: +(gdb) bt +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +#14 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 + s = 0x42bb5d80 + l2_index = 0 + cluster_offset = 4210688 + l2_table = 0x0 + nb_clusters = 1119575424 + keep_clusters = 0 + ret = 0 + __PRETTY_FUNCTION__ = "handle_copied" +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 + s = 0x42bb5d80 + start = 4210688 + remaining = 2686976 + cluster_offset = 4294983168 + cur_bytes = 2686976 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 + s = 0x42bb5d80 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 2703360 + cluster_offset = 4294950912 + hd_qiov = {iov = 0x42b74fb0, niov = 1, nalloc = 1, size = 16384} + bytes_done = 88576 + cluster_data = 0x0 + l2meta = 0x42bb5d20 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 1119538320 + nb_sectors = 2841469356 + ret = 2116577536 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 + bs = 0x42ba9ad0 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 +---Type <return> to continue, or q <return> to quit--- + end_sector = 13472 + bytes_remaining = 2791936 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x42ba9ad0 + req = {bs = 0x42ba9ad0, offset = 4105728, bytes = 2791936, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 4105728, + overlap_bytes = 2791936, list = {le_next = 0x0, le_prev = 0x42bacd48}, co = 0x42bb50b0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fffaf4bfe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fffaf4bfdb0, niov = -1353974288, nalloc = 16383, size = 4105728} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x42ba9ad0 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 + rwco = 0x3fffc7cc9ef8 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x42bb50b0, i = {1119572144, 0}} + self = 0x42bb50b0 + co = 0x42bb50b0 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#14 0x0000000000000000 in ?? () +No symbol table info available. + +will attach images_fuzzer image. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1728661 b/results/classifier/gemma3:12b/files/1728661 new file mode 100644 index 00000000..3c1c17e0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1728661 @@ -0,0 +1,107 @@ + +qemu-io segfaults at block/qcow2.h:533 + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "truncate 66560" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 +533 return s->refcount_table[index] & REFT_OFFSET_MASK; +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 +#1 0x000000001005df4c in qcow2_discard_refcount_block (bs=0x32c96f60, discard_block_offs=9223372036854775296) at block/qcow2-refcount.c:3070 +#2 0x000000001005e5c4 in qcow2_shrink_reftable (bs=0x32c96f60) at block/qcow2-refcount.c:3169 +#3 0x0000000010051184 in qcow2_truncate (bs=0x32c96f60, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/qcow2.c:3155 +#4 0x0000000010016480 in bdrv_truncate (child=0x32ca6270, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block.c:3585 +#5 0x0000000010090800 in blk_truncate (blk=0x32c89410, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/block-backend.c:1845 +#6 0x0000000010023028 in truncate_f (blk=0x32c89410, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:1580 +#7 0x000000001001e648 in command (blk=0x32c89410, ct=0x32c96e30, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:117 +#8 0x0000000010024d64 in qemuio_command (blk=0x32c89410, cmd=0x3fffc052f66e "truncate 66560") at qemu-io-cmds.c:2291 +#9 0x000000001000b540 in command_loop () at qemu-io.c:374 +#10 0x000000001000c05c in main (argc=4, argv=0x3fffc051f618) at qemu-io.c:630 +(gdb) bt full +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 + index = 4294967295 +#1 0x000000001005df4c in qcow2_discard_refcount_block (bs=0x32c96f60, discard_block_offs=9223372036854775296) at block/qcow2-refcount.c:3070 + s = 0x32ca3210 + refblock_offs = 852111520 + cluster_index = 16384 + block_index = 3226593616 + refblock = 0x32cb9570 + ret = 16384 + __PRETTY_FUNCTION__ = "qcow2_discard_refcount_block" +#2 0x000000001005e5c4 in qcow2_shrink_reftable (bs=0x32c96f60) at block/qcow2-refcount.c:3169 + s = 0x32ca3210 + reftable_tmp = 0x32cb9570 + i = 0 + ret = 0 +#3 0x0000000010051184 in qcow2_truncate (bs=0x32c96f60, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/qcow2.c:3155 + last_cluster = 70367675804416 + old_file_size = 70367675804416 + s = 0x32ca3210 + old_length = 1048576 + new_l1_size = 1 + ret = 0 + __func__ = "qcow2_truncate" + __PRETTY_FUNCTION__ = "qcow2_truncate" + __FUNCTION__ = "qcow2_truncate" +#4 0x0000000010016480 in bdrv_truncate (child=0x32ca6270, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block.c:3585 + bs = 0x32c96f60 + drv = 0x102036f0 <bdrv_qcow2> + ret = 16383 + __PRETTY_FUNCTION__ = "bdrv_truncate" + __func__ = "bdrv_truncate" +#5 0x0000000010090800 in blk_truncate (blk=0x32c89410, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/block-backend.c:1845 + __func__ = "blk_truncate" +#6 0x0000000010023028 in truncate_f (blk=0x32c89410, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:1580 + local_err = 0x0 + offset = 66560 + ret = 0 +#7 0x000000001001e648 in command (blk=0x32c89410, ct=0x32c96e30, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:117 + cmd = 0x32c684c0 "truncate" +#8 0x0000000010024d64 in qemuio_command (blk=0x32c89410, cmd=0x3fffc052f66e "truncate 66560") at qemu-io-cmds.c:2291 + ctx = 0x32c924d0 + input = 0x32c684c0 "truncate" + ct = 0x32c96e30 + v = 0x32c685a0 + c = 2 + done = false +#9 0x000000001000b540 in command_loop () at qemu-io.c:374 + i = 0 + done = 0 + fetchable = 0 +---Type <return> to continue, or q <return> to quit--- + prompted = 0 + input = 0x0 +#10 0x000000001000c05c in main (argc=4, argv=0x3fffc051f618) at qemu-io.c:630 + readonly = 0 + sopt = 0x101b2608 "hVc:d:f:rsnCmkt:T:U" + lopt = {{name = 0x101b26d0 "driver", has_arg = 0, flag = 0x0, val = 104}, {name = 0x101b26d8 "help", has_arg = 0, flag = 0x0, val = 86}, { + name = 0x101b26e0 "version", has_arg = 1, flag = 0x0, val = 99}, {name = 0x101b26e8 "cmd", has_arg = 1, flag = 0x0, val = 102}, { + name = 0x101b26f0 "format", has_arg = 0, flag = 0x0, val = 114}, {name = 0x101b2700 "y", has_arg = 0, flag = 0x0, val = 115}, { + name = 0x101b2710 "", has_arg = 0, flag = 0x0, val = 110}, {name = 0x101b2718 "nocache", has_arg = 0, flag = 0x0, val = 67}, { + name = 0x101b2728 "read", has_arg = 0, flag = 0x0, val = 109}, {name = 0x101b2738 "", has_arg = 0, flag = 0x0, val = 107}, { + name = 0x101b2748 "io", has_arg = 1, flag = 0x0, val = 100}, {name = 0x101b2750 "discard", has_arg = 1, flag = 0x0, val = 116}, { + name = 0x101b2758 "cache", has_arg = 1, flag = 0x0, val = 84}, {name = 0x101b25e8 "object", has_arg = 1, flag = 0x0, val = 256}, { + name = 0x101b2760 "trace", has_arg = 0, flag = 0x0, val = 257}, {name = 0x101b1c48 "force-share", has_arg = 0, flag = 0x0, val = 85}, {name = 0x0, + has_arg = 0, flag = 0x0, val = 0}} + c = -1 + opt_index = 0 + flags = 16386 + writethrough = true + local_error = 0x0 + opts = 0x0 + format = 0x0 + trace_file = 0x0 + force_share = false + +image_fuzzer image will be attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/173 b/results/classifier/gemma3:12b/files/173 new file mode 100644 index 00000000..33ad0b85 --- /dev/null +++ b/results/classifier/gemma3:12b/files/173 @@ -0,0 +1,2 @@ + +unable to read symlinks when mounting 9p filesystem with security_model=mapped diff --git a/results/classifier/gemma3:12b/files/1734 b/results/classifier/gemma3:12b/files/1734 new file mode 100644 index 00000000..cde507e7 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1734 @@ -0,0 +1,17 @@ + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/gemma3:12b/files/1736376 b/results/classifier/gemma3:12b/files/1736376 new file mode 100644 index 00000000..0e626a2d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1736376 @@ -0,0 +1,11 @@ + +CVE-2017-7471 repeated? + +In the hw/9pfs/9p-proxy.c file I can see the following which is changed because of CVE-2017-7471 in the hw/9pfs/9p-local.c. I might be wrong but I guess that should be changed as well. + +if(dir_path){ +v9fs_path_sprintf(target,"%s/%s",dir_path->data,name); +} +else{ +v9fs_path_sprintf(target,"%s",name); +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1739304 b/results/classifier/gemma3:12b/files/1739304 new file mode 100644 index 00000000..aa9c27b2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1739378 b/results/classifier/gemma3:12b/files/1739378 new file mode 100644 index 00000000..3ed03c05 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1739378 @@ -0,0 +1,40 @@ + +migration state save/load of sdcard device is broken + +I'm having different issues trying to have QEMU snapshots working using qemu-system-arm with vexpress-a15 board. + +In this opportunity, I'm trying the git master head version: +# git rev-parse HEAD +af352675efb7e92a1f5f6461a042a12015ab3d12 + +$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb +audio: Could not init `oss' audio driver + +Later on, when the machine finishes booting I savevm ss and quit. However, when I try to restore it, I have that Missing section footer error: + +$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb -loadvm ss +audio: Could not init `oss' audio driver +qemu-system-arm: Missing section footer for sd-card +qemu-system-arm: Error -22 while loading VM state + + +OS: Ubuntu 16.04.3 LTS (xenial) + +$ gcc --version +gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 + +I've also tried a different ./configure line, explicitly enabling some of the features, i.e. smartcard, with the same results: + +./configure '--disable-user' '--enable-system' '--enable-linux-user' '--enable-modules' '--enable-linux-aio' '--audio-drv-list=pa' '--enable-attr' '--enable-brlapi' '--enable-virtfs' '--enable-cap-ng' '--enable-curl' '--enable-fdt' '--enable-gnutls' '--disable-gtk' '--disable-vte' '--enable-libiscsi' '--enable-curses' '--enable-smartcard' '--enable-rbd' '--enable-vnc-sasl' '--enable-seccomp' '--enable-spice' '--enable-libusb' '--enable-usb-redir' '--enable-xfsctl' '--enable-vnc' '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-kvm' '--enable-vhost-net' + +How have I built it? +# git clone git://git.qemu.org/qemu.git +# cd qemu +# git submodule update --init --checkout +# make clean && ./configure --target-list=arm-softmmu && make -j8 +# sudo make install + +As a reference, and just in case these may be in some way related, I've just submitted another ticket for a different issue with snapshots using Ubuntu Qemu version (https://bugs.launchpad.net/qemu/+bug/1739371) + +Cheers, +Gus \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1740364 b/results/classifier/gemma3:12b/files/1740364 new file mode 100644 index 00000000..f158930f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1740364 @@ -0,0 +1,443 @@ + +qemu-img: fails to get shared 'write' lock + +Description of problem: +Somewhere in F27 (did not see it happening before), I'm getting while running libguestfs (via libvirt or direct), a qemu-img failure. Note: multiple qcow2 snapshots are on the same backing file, and a parallel libguestfs command is running on all. However, it seems to be failing to get a lock on the leaf, which is unique, non-shared. + +The VM is up and running. I'm not sure why qemu-img is even trying to get a write lock on it. Even 'info' fails: +ykaul@ykaul ovirt-system-tests]$ qemu-img info /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +qemu-img: Could not open '/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2': Failed to get shared "write" lock +Is another process using the image? +[ykaul@ykaul ovirt-system-tests]$ lsof |grep qcow2 +[ykaul@ykaul ovirt-system-tests]$ file /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/lago/store/phx_repo:el7.4-base:v1), 6442450944 bytes + + +And it's OK if I kill the VM of course. + + + + +Version-Release number of selected component (if applicable): +[ykaul@ykaul ovirt-system-tests]$ rpm -qa |grep qemu +qemu-block-nfs-2.10.1-2.fc27.x86_64 +qemu-block-dmg-2.10.1-2.fc27.x86_64 +qemu-guest-agent-2.10.1-2.fc27.x86_64 +qemu-system-x86-core-2.10.1-2.fc27.x86_64 +qemu-block-curl-2.10.1-2.fc27.x86_64 +qemu-img-2.10.1-2.fc27.x86_64 +qemu-common-2.10.1-2.fc27.x86_64 +qemu-kvm-2.10.1-2.fc27.x86_64 +qemu-block-ssh-2.10.1-2.fc27.x86_64 +qemu-block-iscsi-2.10.1-2.fc27.x86_64 +libvirt-daemon-driver-qemu-3.7.0-3.fc27.x86_64 +qemu-block-gluster-2.10.1-2.fc27.x86_64 +ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch +qemu-system-x86-2.10.1-2.fc27.x86_64 +qemu-block-rbd-2.10.1-2.fc27.x86_64 + + +How reproducible: +Sometimes. + +Steps to Reproduce: +1. Running Lago (ovirt-system-tests) on my laptop, it happens quite a lot. + +Additional info: +libguestfs: trace: set_verbose true +libguestfs: trace: set_verbose = 0 +libguestfs: trace: set_backend "direct" +libguestfs: trace: set_backend = 0 +libguestfs: create: flags = 0, handle = 0x7f1314006430, program = python2 +libguestfs: trace: set_program "lago" +libguestfs: trace: set_program = 0 +libguestfs: trace: add_drive_ro "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" +libguestfs: trace: add_drive "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" "readonly:true" +libguestfs: creating COW overlay to protect original drive content +libguestfs: trace: get_tmpdir +libguestfs: trace: get_tmpdir = "/tmp" +libguestfs: trace: disk_create "/tmp/libguestfsWrA7Dh/overlay1.qcow2" "qcow2" -1 "backingfile:/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" +libguestfs: command: run: qemu-img +libguestfs: command: run: \ create +libguestfs: command: run: \ -f qcow2 +libguestfs: command: run: \ -o backing_file=/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +libguestfs: command: run: \ /tmp/libguestfsWrA7Dh/overlay1.qcow2 +qemu-img: /tmp/libguestfsWrA7Dh/overlay1.qcow2: Failed to get shared "write" lock +Is another process using the image? +Could not open backing image to determine size. +libguestfs: trace: disk_create = -1 (error) +libguestfs: trace: add_drive = -1 (error) +libguestfs: trace: add_drive_ro = -1 (error) + + +And: +[ykaul@ykaul ovirt-system-tests]$ strace qemu-img info /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +execve("/usr/bin/qemu-img", ["qemu-img", "info", "/home/ykaul/ovirt-system-tests/d"...], 0x7fffb36ccfc0 /* 59 vars */) = 0 +brk(NULL) = 0x562790488000 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20cea08000 +access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) +openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 +fstat(3, {st_mode=S_IFREG|0644, st_size=93275, ...}) = 0 +mmap(NULL, 93275, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f20ce9f1000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320#\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=94232, ...}) = 0 +mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce5cc000 +mprotect(0x7f20ce5e2000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce7e1000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f20ce7e1000 +mmap(0x7f20ce7e2000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20ce7e2000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libaio.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\5\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=6312, ...}) = 0 +mmap(NULL, 2101328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce3ca000 +mprotect(0x7f20ce3cb000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce5ca000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f20ce5ca000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgmodule-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\20\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=15264, ...}) = 0 +mmap(NULL, 2109528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce1c6000 +mprotect(0x7f20ce1c9000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce3c8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f20ce3c8000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\256\1\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1145520, ...}) = 0 +mmap(NULL, 3223752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdeb2000 +mprotect(0x7f20cdfc3000, 2097152, PROT_NONE) = 0 +mmap(0x7f20ce1c3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x111000) = 0x7f20ce1c3000 +mmap(0x7f20ce1c5000, 200, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20ce1c5000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgthread-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\6\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=6832, ...}) = 0 +mmap(NULL, 2101256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdcb0000 +mprotect(0x7f20cdcb1000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cdeb0000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f20cdeb0000 +mmap(0x7f20cdeb1000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cdeb1000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240!\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=43696, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9ef000 +mmap(NULL, 2128800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdaa8000 +mprotect(0x7f20cdaaf000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cdcae000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f20cdcae000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libcap-ng.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\25\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=23544, ...}) = 0 +mmap(NULL, 2117640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd8a2000 +mprotect(0x7f20cd8a6000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cdaa6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f20cdaa6000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libnettle.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\233\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=229728, ...}) = 0 +mmap(NULL, 2322496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd66a000 +mprotect(0x7f20cd6a0000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd89f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35000) = 0x7f20cd89f000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\336\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1516168, ...}) = 0 +mmap(NULL, 3599400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd2fb000 +mprotect(0x7f20cd45c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd65b000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x160000) = 0x7f20cd65b000 +mmap(0x7f20cd669000, 3112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cd669000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\16\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=14344, ...}) = 0 +mmap(NULL, 2105608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd0f8000 +mprotect(0x7f20cd0fa000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd2f9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f20cd2f9000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\301\10\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1586584, ...}) = 0 +mmap(NULL, 3694592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ccd72000 +mprotect(0x7f20cceea000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd0e9000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x177000) = 0x7f20cd0e9000 +mmap(0x7f20cd0f5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cd0f5000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200x\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1503544, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9ed000 +mmap(NULL, 3490600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cca1d000 +mprotect(0x7f20ccb71000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ccd70000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153000) = 0x7f20ccd70000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300*\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=92800, ...}) = 0 +mmap(NULL, 2188336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc806000 +mprotect(0x7f20cc81c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cca1b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f20cca1b000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220a\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=153128, ...}) = 0 +mmap(NULL, 2221160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc5e7000 +mprotect(0x7f20cc601000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc800000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f20cc800000 +mmap(0x7f20cc802000, 13416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cc802000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \21\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=2245824, ...}) = 0 +mmap(NULL, 4074112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc204000 +mprotect(0x7f20cc3de000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc5dd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d9000) = 0x7f20cc5dd000 +mmap(0x7f20cc5e3000, 14976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cc5e3000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=19264, ...}) = 0 +mmap(NULL, 2109680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc000000 +mprotect(0x7f20cc003000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc202000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f20cc202000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\26\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=471816, ...}) = 0 +mmap(NULL, 2564360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cbd8d000 +mprotect(0x7f20cbdfe000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cbffe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x71000) = 0x7f20cbffe000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\271\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1261200, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9eb000 +mmap(NULL, 3334480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cba5e000 +mprotect(0x7f20cbb78000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cbd77000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x119000) = 0x7f20cbd77000 +mmap(0x7f20cbd8c000, 336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cbd8c000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\26\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=118104, ...}) = 0 +mmap(NULL, 2211856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb841000 +mprotect(0x7f20cb85d000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cba5c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7f20cba5c000 +mmap(0x7f20cba5d000, 16, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cba5d000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\17\1\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1513480, ...}) = 0 +mmap(NULL, 3608840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb4cf000 +mprotect(0x7f20cb63c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cb83b000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16c000) = 0x7f20cb83b000 +mmap(0x7f20cb840000, 264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cb840000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260,\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=77536, ...}) = 0 +mmap(NULL, 2171592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb2bc000 +mprotect(0x7f20cb2cd000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cb4cd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x7f20cb4cd000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libhogweed.so.4", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360w\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=188072, ...}) = 0 +mmap(NULL, 2281480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb08e000 +mprotect(0x7f20cb0ba000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cb2ba000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7f20cb2ba000 +mmap(0x7f20cb2bb000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cb2bb000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\305\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=495800, ...}) = 0 +mmap(NULL, 2584736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cae16000 +mprotect(0x7f20cae8c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cb08b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x75000) = 0x7f20cb08b000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libffi.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\27\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=31896, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e9000 +mmap(NULL, 2127048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cac0e000 +mprotect(0x7f20cac15000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cae14000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f20cae14000 +close(3) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e7000 +mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e4000 +arch_prctl(ARCH_SET_FS, 0x7f20ce9e4900) = 0 +mprotect(0x7f20cc5dd000, 16384, PROT_READ) = 0 +mprotect(0x7f20cae14000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb08b000, 8192, PROT_READ) = 0 +mprotect(0x7f20cd89f000, 8192, PROT_READ) = 0 +mprotect(0x7f20cb2ba000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb4cd000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb83b000, 16384, PROT_READ) = 0 +mprotect(0x7f20cba5c000, 4096, PROT_READ) = 0 +mprotect(0x7f20cc800000, 4096, PROT_READ) = 0 +mprotect(0x7f20cc202000, 4096, PROT_READ) = 0 +mprotect(0x7f20cbd77000, 45056, PROT_READ) = 0 +mprotect(0x7f20cbffe000, 4096, PROT_READ) = 0 +mprotect(0x7f20cca1b000, 4096, PROT_READ) = 0 +mprotect(0x7f20ccd70000, 4096, PROT_READ) = 0 +mprotect(0x7f20cd0e9000, 40960, PROT_READ) = 0 +mprotect(0x7f20cd2f9000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce7e1000, 4096, PROT_READ) = 0 +mprotect(0x7f20cd65b000, 53248, PROT_READ) = 0 +mprotect(0x7f20cdaa6000, 4096, PROT_READ) = 0 +mprotect(0x7f20cdcae000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce1c3000, 4096, PROT_READ) = 0 +mprotect(0x7f20cdeb0000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce3c8000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce5ca000, 4096, PROT_READ) = 0 +mprotect(0x56278f387000, 24576, PROT_READ) = 0 +mprotect(0x7f20cea0a000, 4096, PROT_READ) = 0 +munmap(0x7f20ce9f1000, 93275) = 0 +set_tid_address(0x7f20ce9e4bd0) = 4326 +set_robust_list(0x7f20ce9e4be0, 24) = 0 +rt_sigaction(SIGRTMIN, {sa_handler=0x7f20cc5ecc10, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f20cc5f9a80}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {sa_handler=0x7f20cc5eccb0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f20cc5f9a80}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +futex(0x7f20cbd8c0c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +brk(NULL) = 0x562790488000 +brk(0x5627904a9000) = 0x5627904a9000 +brk(0x5627904ca000) = 0x5627904ca000 +getrandom("\xc2", 1, GRND_NONBLOCK) = 1 +stat("/etc/crypto-policies/back-ends/gnutls.config", {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +openat(AT_FDCWD, "/etc/crypto-policies/back-ends/gnutls.config", O_RDONLY) = 3 +fstat(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +lseek(3, 0, SEEK_CUR) = 0 +fstat(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +read(3, "SYSTEM=NONE:+AEAD:+SHA1:+SHA256:"..., 4096) = 465 +read(3, "", 4096) = 0 +close(3) = 0 +rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f20cc23b6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-img", 4095) = 17 +prctl(PR_SET_TIMERSLACK, 1) = 0 +rt_sigprocmask(SIG_BLOCK, [BUS USR1 ALRM IO], NULL, 8) = 0 +signalfd(-1, [BUS ALRM IO], 8) = 3 +fcntl(3, F_GETFD) = 0 +fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) +fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +epoll_create1(EPOLL_CLOEXEC) = 4 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 5 +epoll_create1(EPOLL_CLOEXEC) = 6 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 7 +futex(0x7f20ce1c4e88, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 8 +brk(NULL) = 0x5627904ca000 +brk(0x5627904eb000) = 0x5627904eb000 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 9 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +close(9) = 0 +stat("/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 9 +read(9, "\364\275^\0\226\321$\2337\356\311\301li\305\206", 16) = 16 +close(9) = 0 +futex(0x7f20ce1c4e88, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +openat(AT_FDCWD, "/dev/null", O_RDWR) = 9 +fcntl(9, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0, l_pid=0}) = 0 +close(9) = 0 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_CLOEXEC) = 9 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_CLOEXEC) = 10 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +lseek(9, 0, SEEK_END) = 43122688 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1, l_pid=0}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce8e3000 +mprotect(0x7f20ce8e3000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f20ca40d000 +mprotect(0x7f20ca40e000, 8388608, PROT_READ|PROT_WRITE) = 0 +clone(child_stack=0x7f20cac0cdf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f20cac0d9d0, tls=0x7f20cac0d700, child_tidptr=0x7f20cac0d9d0) = 4327 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +futex(0x5627904beb20, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8) = 1 ([{fd=7, revents=POLLIN}]) +read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1, l_pid=0}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=2, l_pid=18446744073709551615}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ca30c000 +mprotect(0x7f20ca30c000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +close(9) = 0 +close(10) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ca20b000 +mprotect(0x7f20ca20b000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 +write(2, "qemu-img: Could not open '/home/"..., 180qemu-img: Could not open '/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2': Failed to get shared "write" lock +) = 180 +write(2, "Is another process using the ima"..., 36Is another process using the image? +) = 36 +exit_group(1) = ? ++++ exited with 1 +++ + + +[ykaul@ykaul ovirt-system-tests]$ stat /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 + File: /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 + Size: 43122688 Blocks: 84112 IO Block: 4096 regular file +Device: fd03h/64771d Inode: 4718904 Links: 1 +Access: (0666/-rw-rw-rw-) Uid: ( 107/ qemu) Gid: ( 107/ qemu) +Context: system_u:object_r:svirt_image_t:s0:c635,c936 +Access: 2017-12-28 09:28:17.892598375 +0200 +Modify: 2017-12-28 09:31:10.456906255 +0200 +Change: 2017-12-28 09:31:10.456906255 +0200 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1743337 b/results/classifier/gemma3:12b/files/1743337 new file mode 100644 index 00000000..afe1e8ab --- /dev/null +++ b/results/classifier/gemma3:12b/files/1743337 @@ -0,0 +1,5 @@ + +OS/2 Warp 4 HPFS corruption + +How to reproduce: +Install OS/2 Warp 4 onto HPFS-formatted partition. After reboot there will be messages about "missing" files and OS2.INI not found. Chkdsk C: complains about FS corruption. Nothing changes evwn after fixing errors and next reboot. If you install OS/2 onto FAT partition instead, everything will be OK. I also tried booting images with OS/2 pre-installed through VBOX with same results. Is that HPFS driver or QEMU fault? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1748 b/results/classifier/gemma3:12b/files/1748 new file mode 100644 index 00000000..030867d2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1749016 b/results/classifier/gemma3:12b/files/1749016 new file mode 100644 index 00000000..e4443e3e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1749016 @@ -0,0 +1,38 @@ + +VHDX BAT and Metadata Region Header Required Bit Not Set + +When converting a VMDK to VHDX the resulting VHDX's Region table has a small error. According to the VHDX specification the BAT and Metadata entries for the region header required bit should be set to 1. In a VHDX created by qemu-img, this bit is not set. + +See Table 4: Known Region Properties of the VHDX specification. + +The structure format is as following from Structure 4: Region Table Entry: + +struct VHDX_REGION_TABLE_ENTRY { +GUID Guid; +UINT64 FileOffset; +UINT32 Length; +UINT32 Required:1; +UINT32 Reserved:31; +} + +The Required bit for VHDX specified BAT and Metadata Regions Required bit in the entry is not set as required in the current specification. + +VHDX Region Table in a valid VHDX + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 + +VHDX Region Table in a VHDX converted by qemu-img from VMDK + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 + +The fist bit at 0x0003002A and 0x0003004A should be set to 1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1753 b/results/classifier/gemma3:12b/files/1753 new file mode 100644 index 00000000..b1032dff --- /dev/null +++ b/results/classifier/gemma3:12b/files/1753 @@ -0,0 +1,4 @@ + +Does the qemu have luks2 support? +Description of problem: +Does the qemu have luks2 support? diff --git a/results/classifier/gemma3:12b/files/1753186 b/results/classifier/gemma3:12b/files/1753186 new file mode 100644 index 00000000..21c60b05 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1753186 @@ -0,0 +1,17 @@ + +qemu-nbd: always first snapshot loaded from VDI images with snapshots + +When mounting a virtual box disk image of a VM with snapshots, always the state of the first snapshot is shown. + +How to reproduce: +1. Create a new VirtualBox VM or use an existing one, while choosing VDI as the disk image format. +2. Create a snapshot of the VM. +3. Modify the file system from within the VM enough that differences to the snapshotted version are apparent. +4. Create another snapshot. +5. Shut down the VM. +6. Mount the partition from the disk image with `qemu-nbd -c /dev/nbd0 /path/to/disk.vdi; mount /dev/nbd0pX /mnt` + +Expected result: The mounted disk image shall represent the latest state of the VM +Actual result: The mounted disk image represents the VM state at the first snapshot + +version information: qemu-nbd-2.11.1(openSUSE Tumbleweed) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1759337 b/results/classifier/gemma3:12b/files/1759337 new file mode 100644 index 00000000..2ab3d3eb --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1759522 b/results/classifier/gemma3:12b/files/1759522 new file mode 100644 index 00000000..f148216f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1759522 @@ -0,0 +1,57 @@ + +windows qemu-img create vpc/vhdx error + +On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: + +1. Install qemu-w64-setup-20180321.exe + +2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create a vhdx: + Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` is incorrect): + image: disk.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 1.4M + cluster_size: 8388608 + +4. On Windows 10 (V1709), double click disk.vhdx gives an error: + Make sure the file is in an NTFS volume and isn't in a compressed folder or volume. + + Using Disk Management -> Action -> Attach VHD gives an error: + The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and uneccrypted and must not be sparse. + +Comparison with Windows 10 created VHDX: + +1. Using Disk Management -> Action -> Create VHD: + File name: win.vhdx + Virtual hard disk size: 512MB + Virtual hard disk format: VHDX + Virtual hard disk type: Fixed size + +2. Detach VHDX + +3. Execute `qemu-img info win.vhdx` gives the result: + image: win.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 516M + cluster_size: 33554432 + +Comparison with qemu-img under Ubuntu: + +1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard + +2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M + Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. qemu-img info lin.vhdx + image: lin.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 520M + cluster_size: 8388608 + +4. Load lin.vhdx under Windows 10 is ok + +The same thing happens on `vpc` format with or without `oformat=fixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1761153 b/results/classifier/gemma3:12b/files/1761153 new file mode 100644 index 00000000..4319fa9c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1761153 @@ -0,0 +1,24 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1770417 b/results/classifier/gemma3:12b/files/1770417 new file mode 100644 index 00000000..491cb372 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1770417 @@ -0,0 +1,31 @@ + +Qemu can not parse long fqdns during drive-mirror + +During migration of an openstack booted instance, I got the following error: + +Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+0000: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud-mk.local:49153' + +A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939 + +To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block-operations.rst#id21. On dest and source compute nodes, I launched an instance: + +qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node-TargetDisk,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./test-instance-mirror.qcow2 -device virtio-blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost:6666 + +Then on dest node I launched nbd server: + +(qemu) nbd_server_start cmp0:49153 +(qemu) nbd_server_add -w node-TargetDisk + +On the source node: + +(qemu) drive_mirror -n node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk +error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153' + +When using short host name instead of FQDN address seems to be parsed fine: + +(qemu) drive_mirror -n node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2 +Image is not in qcow2 format + +(not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated) + +QEMU version is 2.11.1 from bionic \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1771570 b/results/classifier/gemma3:12b/files/1771570 new file mode 100644 index 00000000..aa23c90f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1771570 @@ -0,0 +1,12 @@ + +qemu-aarch64 $program > $file doesn't pipe output to file in 2.12.0 + +Running qemu-aarch64 $program > $file doesn't pipe anything to $file. The file is created but empty. + +qemu-aarch64 --help > $file works, so piping output in my system seems to work. +qemu-x86_64 $program > $file works, too. + +I'm running version 2.12.0 build from source with ./configure && make + +Output of uname -a: +Linux zhostname> 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1772075 b/results/classifier/gemma3:12b/files/1772075 new file mode 100644 index 00000000..219327ef --- /dev/null +++ b/results/classifier/gemma3:12b/files/1772075 @@ -0,0 +1,13 @@ + +Segmentation fault on aarch64 vm at powerdown + +OS Arch Linux +x86_64 +qemu version: 2.12 + +cmdline: +qemu-system-aarch64 -nographic -cpu cortex-a57 -m 2048 -M virt,gic_version=3 -machine virtualization=true -bios /usr/share/ovmf/AARCH64/QEMU_EFI.fd -drive file=fat:rw:/opt/simonpiemu/kernels/rpi-3,if=none,format=raw,cache=none,id=hd0 -device virtio-blk-device,drive=hd0 -drive file=/home/morfeo/.simonpi/sd-arch-rpi-3-qemu.img,if=none,format=raw,cache=none,id=hd1 -device virtio-blk-device,drive=hd1 -kernel /opt/simonpiemu/kernels/rpi-3/Image -append "root=/dev/vda2 fstab=no rootfstype=ext4 rw console=ttyAMA0" -initrd /home/morfeo/.simonpi/rpi-3/boot/initramfs-linux.img -device virtio-net-device,mac=52:54:26:11:72:9b,netdev=net0 -netdev tap,id=net0,ifname=rasp-tap0,script=no,downscript=no + +error: + +qemu-system-aarch64: /build/qemu/src/qemu-2.12.0/block.c:3375: bdrv_close_all: Assertion `QTAILQ_EMPTY(&all_bdrv_states)' failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1774853 b/results/classifier/gemma3:12b/files/1774853 new file mode 100644 index 00000000..5781153a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1776920 b/results/classifier/gemma3:12b/files/1776920 new file mode 100644 index 00000000..d9c01ff1 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1781463 b/results/classifier/gemma3:12b/files/1781463 new file mode 100644 index 00000000..66ef2d6a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1781463 @@ -0,0 +1,100 @@ + +qemu don't start *.abs firmware files + +Hello Devs, + +I'm here to report this bug/issue because i'm using Win64 Qemu but i can't start a *.abs firmware at normally this firmware is based in Linux Kernel and this type of firmware is made for STB Receivers, + +So this is all information i provide to get support. + +Files extracted by ( binwalk -e ) + + +Terminal output: + +# binwalk -e AMIKO_HD8150_2.4.43_emu.abs + +DECIMAL HEXADECIMAL DESCRIPTION + +-------------------------------------------------------------------------------- +196736 0x30080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 11883876 bytes +3866752 0x3B0080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 3255512 bytes +5636224 0x560080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 87904 bytes + + +Files extracted with ALI TOOLS or Ali FirmwareDecriptor. + +Windows files output: + +Software used: Ali Main Code Decrypter 8.9 + +Files unpacked: + +bootloader +MemCfg +maincode(AV) +seecode +default_lang +cipluskey +countryband +logo_user +logo_menu +logo_radio +logo_boot +patch +defaultdb(PRC) +userdb(64+64) + + +Terminal OUTPUT: + +# hexdump -C + +part of file + + +00b51a30 00 00 00 00 4c 69 62 63 6f 72 65 20 76 65 72 73 |....Libcore vers| +00b51a40 69 6f 6e 20 31 33 2e 31 36 2e 30 40 53 44 4b 34 |ion 13.16.0@SDK4| +00b51a50 2e 30 66 61 2e 31 33 2e 31 36 5f 32 30 31 36 31 |.0fa.13.16_20161| +00b51a60 30 31 39 28 67 63 63 20 76 65 72 73 69 6f 6e 20 |019(gcc version | +00b51a70 33 2e 34 2e 34 20 6d 69 70 73 73 64 65 2d 36 2e |3.4.4 mipssde-6.| +00b51a80 30 36 2e 30 31 2d 32 30 30 37 30 34 32 30 29 28 |06.01-20070420)(| +00b51a90 41 64 6d 69 6e 69 73 74 72 61 74 6f 72 40 20 46 |Administrator@ F| +00b51aa0 72 69 2c 20 4a 75 6c 20 32 38 2c 20 32 30 31 37 |ri, Jul 28, 2017| +00b51ab0 20 31 32 3a 35 33 3a 32 38 20 41 4d 29 0a 00 00 | 12:53:28 AM)...| +00b51ac0 44 4d 58 5f 53 33 36 30 31 5f 30 00 00 a1 03 18 |DMX_S3601_0.....| + + +When I use readelf it says files isn't an ELF file, so i can't run it like a kernel (Bootloader,Maincode, and etc. ) + +so this is the cmd output when i use qemu Win64 (I don't whant to use linux to do the emulation about this *.abs extension firmware so please help me for win64 version from Qemu) + +CMD OUTPUT: + + C:\Program Files\qemu>qemu-system-mips.exe -machine mips -cpu mips32r6-generic -drive file=C:\30080.bin,index=0,media=disk,format=raw + +qemu-system-mips.exe: warning: could not load MIPS bios 'mips_bios.bin' + +I also tried a lot of diferents qemu-system... and a lot of diferent configs like -machine -cpu -kernel -driver root= -PFLASH and etc... and nothing hapenned + +How can i reproduce this issue ? +Reply:. + +Donwload *.abs firmware in amikoreceiver.com (only *.abs) and download AliDekompressor in http://www.satedu.cba.pl/ + +Direct tools: + +FirmwareDecrypter_v8.9.zip : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=FirmwareDecrypter_v8.9.zip&directory=Test%20Folder& + +Ali__tools_Console_v4.0__CRC_FIXER.rar : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=Ali__tools_Console_v4.0__CRC_FIXER.rar&directory=Test%20Folder& + + +so if Qemu can explain how can i fix this issue this can be highly helpfull. + +With my best regards, +David Martins +Screamfox \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1784919 b/results/classifier/gemma3:12b/files/1784919 new file mode 100644 index 00000000..c5f91a16 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1785902 b/results/classifier/gemma3:12b/files/1785902 new file mode 100644 index 00000000..b38756ff --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1786 b/results/classifier/gemma3:12b/files/1786 new file mode 100644 index 00000000..07e19d6e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1786 @@ -0,0 +1,25 @@ + +Impossible to create an uncompressed QCOW2 disk +Description of problem: +An QCOW2 image is created compressed unconditionally. There is no way to disable compression, albeit the QCOW format specification allows this. + +``` +$ qemu-img --version +qemu-img version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-img create -f qcow2 test.qcow2 1G +Formatting 'test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +$ +``` + +Same is applicable for 8-x qemu-img version (I built it for testing purposes) +``` +$ ./build/qemu-img create -f qcow2 disk.qcow2 1G +Formatting 'disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +$ ./build/qemu-img --version +qemu-img version 8.0.90 (v8.1.0-rc0-21-gd1181d2937) +Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers +$ +``` +Steps to reproduce: +Create a QCOW2 disk with `qemu-img` of never versions. diff --git a/results/classifier/gemma3:12b/files/1790268 b/results/classifier/gemma3:12b/files/1790268 new file mode 100644 index 00000000..afe3f8ec --- /dev/null +++ b/results/classifier/gemma3:12b/files/1790268 @@ -0,0 +1,20 @@ + +the vhd generated by qemu-img not align with MB again. + +I'm using this version on xenial, +andy@bastion:~/temp$ qemu-img -h +qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c) 2004-2008 Fabrice Bellard + +steps to repro: + +dd if=/dev/zero of=/tmp/azure_config_disk_image20180901-22672-16zxelu bs=1048576 count=24 +mkfs.ext4 -F /tmp/azure_config_disk_image20180901-22672-16zxelu -L azure_cfg_dsk +sudo -n mount -o loop /tmp/azure_config_disk_image20180901-22672-16zxelu /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +sudo -n chown andy /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +mkdir -p /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat/configs +sudo -n umount /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +qemu-img convert -f raw -O vpc -o subformat=fixed,force_size /tmp/azure_config_disk_image20180901-22672-16zxelu papapa2.vhd + +unfortunately the papapa2.vhd size is 25166336!=25165824 which means it's not aligned in MiB. + +could you please help? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1790617 b/results/classifier/gemma3:12b/files/1790617 new file mode 100644 index 00000000..06d60ca7 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1791 b/results/classifier/gemma3:12b/files/1791 new file mode 100644 index 00000000..b6a4a8ea --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1793016 b/results/classifier/gemma3:12b/files/1793016 new file mode 100644 index 00000000..78607e62 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1793016 @@ -0,0 +1,23 @@ + +vmdk to cqow2 invalid VMDK image descriptor + +Greetings, + +CentOS 7.5.1804 +Linux 3.10.0-862.11.6.el7.x86_64 +qemu-img version 3.0.50 (v3.0.0-614-g19b599f) + +When trying to convert a vmdk flat file to qcow2 format, I get the following error message: +qemu-img: Could not open './sk-R12-flat.vmdk': invalid VMDK image descriptor + +The command line used is +root@s11kvm:/home/goinfre> qemu-img convert -f vmdk -O qcow2 ./sk-R12-flat.vmdk ./sk-R12-flat.qcow2 + + +"file sk-R12-flat.vmdk" returns: +sk-R12-flat.vmdk: x86 boot sector; +GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x40, GRUB version 0.97; +partition 1: ID=0x63, active, starthead 1, startsector 63, 16002 sectors; +partition 2: ID=0x83, starthead 0, startsector 16065, 3084480 sectors; +partition 3: ID=0x83, starthead 0, startsector 3100545, 3084480 sectors; +partition 4: ID=0x5, starthead 0, startsector 6185025, 161581770 sectors, code offset 0x48 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1793904 b/results/classifier/gemma3:12b/files/1793904 new file mode 100644 index 00000000..eb70ef4c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1794086 b/results/classifier/gemma3:12b/files/1794086 new file mode 100644 index 00000000..78332540 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1796 b/results/classifier/gemma3:12b/files/1796 new file mode 100644 index 00000000..9e4e6e1c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1803872 b/results/classifier/gemma3:12b/files/1803872 new file mode 100644 index 00000000..6ec1301f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1803872 @@ -0,0 +1,17 @@ + +gcc 8.2 reports stringop-truncation when building qemu + +QEMU 3.0 + +block/sheepdog.c: In function 'find_vdi_name': +block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +If this is the intended behavior, please suppress the warning. For example: + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstringop-truncation" + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +#pragma GCC diagnostic pop \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1805913 b/results/classifier/gemma3:12b/files/1805913 new file mode 100644 index 00000000..01773a74 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1806196 b/results/classifier/gemma3:12b/files/1806196 new file mode 100644 index 00000000..100f1795 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1807073 b/results/classifier/gemma3:12b/files/1807073 new file mode 100644 index 00000000..8206a098 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1808563 b/results/classifier/gemma3:12b/files/1808563 new file mode 100644 index 00000000..a80c575a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1808563 @@ -0,0 +1,18 @@ + +Listing the contents of / lists QEMU_LD_PREFIX instead + +Seeing this in qemu-user version 3.1.0 + +Demo: +$ QEMU_LD_PREFIX=$(pwd)/usr/armv7a-cros-linux-gnueabi ../run/qemu-arm /tmp/coreutils --coreutils-prog=ls / +etc lib usr +$ ls / +boot etc lib lib64 lost+found mnt root sbin sys usr +bin dev export home lib32 net proc run tmp var +$ ls usr/armv7a-cros-linux-gnueabi +etc lib usr + +In strace, the openat for "/" is remapped to the directory specified in QEMU_LD_PREFIX: +[pid 5302] openat(AT_FDCWD, "/tmp/qemu/usr/armv7a-cros-linux-gnueabi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 + +As an aside, if I change the code to do chdir("/"); opendir("."); it works fine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1808565 b/results/classifier/gemma3:12b/files/1808565 new file mode 100644 index 00000000..9f3ed61d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1808565 @@ -0,0 +1,8 @@ + +Reading /proc/self/task/<pid>/maps is not remapped to the target + +Seeing this in qemu-user 3.1.0 + +The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly. + +These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1808928 b/results/classifier/gemma3:12b/files/1808928 new file mode 100644 index 00000000..0b690c56 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1809304 b/results/classifier/gemma3:12b/files/1809304 new file mode 100644 index 00000000..dbcc6de9 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/181 b/results/classifier/gemma3:12b/files/181 new file mode 100644 index 00000000..11f1f283 --- /dev/null +++ b/results/classifier/gemma3:12b/files/181 @@ -0,0 +1,2 @@ + +qemu crashes when doing iotest on virtio-9p filesystem diff --git a/results/classifier/gemma3:12b/files/1810343 b/results/classifier/gemma3:12b/files/1810343 new file mode 100644 index 00000000..78090feb --- /dev/null +++ b/results/classifier/gemma3:12b/files/1810343 @@ -0,0 +1,13 @@ + +qemu-nbd -l and -s options don't work together + +When using qemu-nbd with -l to load a snapshot along with -s to create new active layer the tool fails to find the snapshot specified on the command line: + +For example the following does not work: + sudo qemu-nbd -s --load-snapshot=files --connect /dev/nbd0 rootfs.qcow2 + Failed to load snapshot: Can't find snapshot + +However, the following option works + sudo qemu-nbd -s --connect /dev/nbd0 rootfs.qcow2 +and so does + sudo qemu-nbd --load-snapshot=files --connect /dev/nbd0 rootfs.qcow2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1810405 b/results/classifier/gemma3:12b/files/1810405 new file mode 100644 index 00000000..dcc17268 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1810405 @@ -0,0 +1,23 @@ + +source tarball has errors when untarring + +If you download qemu-2.10.0.tar.xv and/or qemu-2.10.1.tar.xv, and follow the directions at https://www.qemu.org/download/, you get a tar error. + + +To repro: +$ wget https://download.qemu.org/qemu-2.10.0.tar.xz +$ tar xJf qemu-2.10.0.tar.xz +tar: qemu-2.10.0/roms/u-boot/scripts/Kconfig: Cannot open: File exists +tar: Exiting with failure status due to previous errors + +$ tar --version +tar (GNU tar) 1.29 +Copyright (C) 2015 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. + +Written by John Gilmore and Jay Fenlason. + + +Apologies if I'm being an idiot here. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1810433 b/results/classifier/gemma3:12b/files/1810433 new file mode 100644 index 00000000..29912e5d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1810433 @@ -0,0 +1,48 @@ + +aarch64-linux-user master: inconsistent pwrite behaviour + +Hello, + +I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 + +And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +Minimal reproducible sample is the following: + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <string.h> + +/* + System | Result +-------------------------+---------------- + Native x86_64 4.12.14 | pwrite ret = 0 + Native aarch64 4.4.159 | pwrite ret = 0 + qemu-aarch64 at x86_64 | pwrite ret = -1 + ( 20d6c7312f1b8 ) | +*/ + +int main(int argc, char** argv) { + int fd = open("test.dat", O_CREAT | O_RDWR, 0644); + if (fd < 0) { + perror("open"); + return 1; + } + + int ret = fallocate(fd, 0, 0, 1000); + if (ret < 0) { + perror("fallocate"); + return 1; + } + + ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); + printf("pwrite ret = %ld\n", ret_pwrite); + + close(fd); + + return 0; +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1810590 b/results/classifier/gemma3:12b/files/1810590 new file mode 100644 index 00000000..4e3e40e1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1810590 @@ -0,0 +1,22 @@ + +Record/replay example does not work + +Trying the record part of the record/replay example at https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu immediately hangs with no guest output displayed. This is with qemu from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8). + +To reproduce: + + wget https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2 + + mv debian_squeeze_i386_standard.qcow2 disk.qcow2 + + qemu-system-i386 \ + -icount shift=7,rr=record,rrfile=replay.bin \ + -drive file=disk.qcow2,if=none,id=img-direct \ + -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ + -device ide-hd,drive=img-blkreplay \ + -netdev user,id=net1 -device rtl8139,netdev=net1 \ + -object filter-replay,id=replay,netdev=net1 + +The above qemu command line is exactly the same as in the example. + +Tested on a Debian 9 x86_64 host. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1811711 b/results/classifier/gemma3:12b/files/1811711 new file mode 100644 index 00000000..0434249b --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1813307 b/results/classifier/gemma3:12b/files/1813307 new file mode 100644 index 00000000..ead96217 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1813307 @@ -0,0 +1,22 @@ + +util/path.c/follow_path() does not handle "/" well + +Hello, + +I noticed that qemu does not handle "/" very well in follow_path(). + +Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. + +Indeed it does something like + if (__lstat ("/", &st) < 0) +..... +and then loops from current dir toward the top using lstat("..") + +On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot). +OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails. + +I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so? + +If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ? + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1813406 b/results/classifier/gemma3:12b/files/1813406 new file mode 100644 index 00000000..9d96d730 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1814418 b/results/classifier/gemma3:12b/files/1814418 new file mode 100644 index 00000000..5de0c422 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1814418 @@ -0,0 +1,22 @@ + +persistent bitmap will be inconsistent when qemu crash, + +Follow these steps to reappear the bug: + +1. start qemu +2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}' +3. kill -9 qemu (simulate Host crash, eg. lose power) +4. restart qemu + +Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can understand at this point, because the bitmap0 has not been synchronized yet. + +But, when I try to add persistent bitmap0 again: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}', It failed: + +{"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the same name is already stored"}} + +In other word, when qemu crash, the qcow2 image remain the incomplete persistent bitmap. + +--- + +qemu version: 2.12.0 and 3.1.0, other version I does not test yet. +qemu command: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1814420 b/results/classifier/gemma3:12b/files/1814420 new file mode 100644 index 00000000..0070ffe1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1814420 @@ -0,0 +1,28 @@ + +drive-backup with iscsi, it will failed "Could not create image: Invalid argument" + +I use iscsi protocol to drive-backup: + +---iscsi target--- +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target +targetcli /iscsi create iqn.2019-01.com.iaas +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.1 3260 +targetcli /backstores/fileio create file1 /opt/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/file1 +------------------- + +Now, '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.1:3260/iqn.2019-01.com.iaas/0" } }' + +It may failed: {"id":"libvirt-1785","error":{"class":"GenericError","desc":"Could not create image: Invalid argument"}} + +But, This abnormal will be appear at the first time. Because when I retry again, It works very well. + +Then, I re-start the vm, It still be failed 'Could not create image: Invalid argument' on the first try, and the second try it will work very well. + +--- +Host: centos 7.5 +qemu version: 2.12 and 3.1.0 +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1815252 b/results/classifier/gemma3:12b/files/1815252 new file mode 100644 index 00000000..3be0dedc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1815252 @@ -0,0 +1,65 @@ + +virtio-9p-pci passthrough fsync hang + +Tested against QEMU: e47f81b617684c4546af286d307b69014a83538a + +and $qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + ++ exec sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -cpu host -smp sockets=1,cpus=4,cores=2 -m 2048 -vga none -nographic -chardev socket,id=chrtpm0,path=/tmp/clrwifi/swtpm2/tpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 -device virtio-rng-pci -netdev user,id=mynet0,hostfwd=tcp::10022-:22 -device virtio-net-pci,netdev=mynet0 -kernel /home/.../Documents/c/iwd/tools/bzImage -append 'console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw' -fsdev local,id=fsdev-root,path=mnt,security_model=passthrough -device virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root +[ 0.000000] Linux version 4.19.0-rc2 (...) (gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)) #10 SMP Fri Feb 8 13:55:20 PST 2019 +[ 0.000000] Command line: console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007e87efff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e87f000-0x000000007e888fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e889000-0x000000007e889fff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007e88a000-0x000000007e88bfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e88c000-0x000000007e88ffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e890000-0x000000007e8a9fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8aa000-0x000000007e8b9fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e8ba000-0x000000007e8bafff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8bb000-0x000000007e9e5fff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e9e6000-0x000000007e9edfff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e9ee000-0x000000007eb1afff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007eb1b000-0x000000007fb9afff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fb9b000-0x000000007fbf2fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fbf3000-0x000000007fbfafff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007fbfb000-0x000000007fbfefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007fbff000-0x000000007ff3ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007ff40000-0x000000007ff5ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007ff60000-0x000000007fffffff] ACPI NVS +[ 0.352469] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed +Started bpfilter +bash: cannot set terminal process group (-1): Inappropriate ioctl for device +bash: no job control in this shell +grep: /proc/cpuinfo: No such file or directory +grep: /proc/cpuinfo: No such file or directory +root@clr / # passwd +... +openat(AT_FDCWD, "/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 +umask(077) = 077 +openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CREAT|O_CLOEXEC, 000) = 5 +fcntl(5, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +fchown(4, 0, 0) = 0 +fchmod(4, 0100644) = 0 +lseek(5, 0, SEEK_CUR) = 0 +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +read(5, "", 8192) = 0 +close(5) = 0 +fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +write(4, "root:$6$jihvB1NonG88C5Yt$kvDCqF7"..., 124) = 124 +fsync(4 <- hung here \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1817 b/results/classifier/gemma3:12b/files/1817 new file mode 100644 index 00000000..f1d81e92 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1817 @@ -0,0 +1,2 @@ + +meson complains about use of install_subdir in docs/meson.build diff --git a/results/classifier/gemma3:12b/files/1817345 b/results/classifier/gemma3:12b/files/1817345 new file mode 100644 index 00000000..ee5a1120 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1818122 b/results/classifier/gemma3:12b/files/1818122 new file mode 100644 index 00000000..7aa042d0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1818122 @@ -0,0 +1,89 @@ + +QEMU 3.1 makes libxslt to crash on ppc64 + +Host: clean Ubuntu Disco with QEMU 3.1 + +Guest: Alpine Linux edge with xmlto + +Steps to set up guest: +curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/vmlinuz-vanilla +curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/initramfs-vanilla +qemu-system-ppc64 -m 1G -kernel vmlinuz-vanilla -initrd initramfs-vanilla -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/edge/main/ modloop=http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/modloop-vanilla" -device virtio-rng-pci -nographic +This brings up an VM with an in-memory Alpine Linux. + +Steps to reproduce: +Login as root and execute the following commands. +apk add xmlto +ntpd -nqp time.google.com // For TLS OCSP +wget https://ddosolitary.org/manpage-base.xsl +wget https://ddosolitary.org/shadowsocks-libev.xml +xmlto -m manpage-base.xsl man shadowsocks-libev.xml +The downloaded files are from this project: https://github.com/shadowsocks/shadowsocks-libev The former is directly taken from the "doc" directory and the latter is an intermediate build output generated by asciidoc from doc/shadowsocks-libev.asciidoc + +Expected behavior: The command silently succeeds producing shadowsocks-libev.8 + +Actual behavior: +runtime error: file file:///usr/share/xml/docbook/xsl-stylesheets-1.79.1/manpages/tbl.xsl line 450 element text +xsltApplySequenceConstructor: A potential infinite template recursion was detected. +You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000). +Templates: +#0 name process.colspan +#1 name process.colspan +#2 name process.colspan +#3 name process.colspan +#4 name process.colspan +#5 name process.colspan +#6 name process.colspan +#7 name process.colspan +#8 name process.colspan +#9 name process.colspan +#10 name process.colspan +#11 name process.colspan +#12 name process.colspan +#13 name process.colspan +#14 name process.colspan +Variables: +#0 +type +colspan +#1 +colspan +#2 +type +colspan +#3 +colspan +#4 +type +colspan +#5 +colspan +#6 +type +colspan +#7 +colspan +#8 +type +colspan +#9 +colspan +#10 +type +colspan +#11 +colspan +#12 +type +colspan +#13 +colspan +#14 +type +colspan +error: file /root/shadowsocks-libev.xml +xsltRunStylesheet : run failed + +Note: +I tried increasing --maxdepth as suggested in the error output but that will result in a segfault. +This error doesn't occur with an older QEMU (I tested QEMU 2.12 on Ubuntu Cosmic) or different architectures on QEMU 3.1 (I tested x86, x86_64, arm, aarch64, s390x). Also it didn't help to use an older Alpine Linux (I tested v3.8). So I think it is caused by a bug in QEMU rather than the distro/package. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1818483 b/results/classifier/gemma3:12b/files/1818483 new file mode 100644 index 00000000..4c77a69e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1818483 @@ -0,0 +1,43 @@ + +qemu user mode does not support binfmt_misc config with flags include "P" + +Hi Sir: +During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. +For example in test module "Devscripts" +the test item for broken tarball expected the warning info: +<tar: This does not look like a tar archive +tar: ******* > +but the output was: +</bin/tar: This does not look like a tar archive +/bin/tar: ******> +the cause is the config file of binfmt_misc was set not to send argv0, for example: +type command "tar" after chroot: +========================== +lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . +[sudo] password for lpeng: +root@lpeng-VirtualBox:/# tar +/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options +Try '/bin/tar --help' or '/bin/tar --usage' for more information. +root@lpeng-VirtualBox:/# +=========================== + +by adding output log in main()@qemu/Linux-user/main.c +we found the original input command was changed, and qemu do not know that, we got the input args: +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----NULL--- + +Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. +But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" + + +After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----tar--- + +We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? +looking forward your suggestions. + +Thanks +luyou \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1819182 b/results/classifier/gemma3:12b/files/1819182 new file mode 100644 index 00000000..d09bb4d3 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1819343 b/results/classifier/gemma3:12b/files/1819343 new file mode 100644 index 00000000..8fb9efb9 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1822 b/results/classifier/gemma3:12b/files/1822 new file mode 100644 index 00000000..01c03ab0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1822 @@ -0,0 +1,8 @@ + +Signed source tarball for 8.0.4 missing +Description of problem: +Hi! I package this project for Arch Linux. I would like to upgrade to 8.0.4, but unfortunately there is no signed source tarball for that version available yet. +Steps to reproduce: +1. Go to https://download.qemu.org/ and find no source tarball for 8.0.4 +Additional information: + diff --git a/results/classifier/gemma3:12b/files/1823169 b/results/classifier/gemma3:12b/files/1823169 new file mode 100644 index 00000000..661ba2fc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1823169 @@ -0,0 +1,6 @@ + +qemu displays message "Setup failed, please check external storage is available and has enough room." + +I tried to launch the Android app PokerStarsFR, and after it began initialization, the launch failed with the above error. I'm running qemu on a Dell XPS 13 (9370) laptop running Ubuntu 16.04 LTS. The standard apps launch OK, but this one does not. I had downloaded it from the PokerStars site https://www.pokerstars.fr/en/poker/download/android/. + +I am running qemu version 2.5.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1825 b/results/classifier/gemma3:12b/files/1825 new file mode 100644 index 00000000..cee75e12 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1825 @@ -0,0 +1,15 @@ + +pigz crashes when running in an aarch64 chroot (entered through qemu-binfmt) with qemu 8.1.0-rc*, qemu 8.0.3 is ok +Description of problem: +If qemu 8.1.0-rc1, -rc2 or -rc3 is used, pigz crashes. +``` +# chroot /chroot/aarch64 pigz /tmp/test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +With qemu 8.0.3 on the same chroot enviroment, it works and produces the expected /chroot/aarch64/tmp/test.gz +Steps to reproduce: +1. Install an aarch64 chroot environment on x86_64 +2. Try using pigz to compress a file inside the chroot environment using qemu-binfmt +Additional information: +Unfortunately `git bisect`-ing the issue isn't easy because many snapshots between 8.0.0 (good) and 8.1.0-rc1 (first known bad) don't compile. diff --git a/results/classifier/gemma3:12b/files/1826200 b/results/classifier/gemma3:12b/files/1826200 new file mode 100644 index 00000000..3473b664 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1829242 b/results/classifier/gemma3:12b/files/1829242 new file mode 100644 index 00000000..5bdbabb0 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1830415 b/results/classifier/gemma3:12b/files/1830415 new file mode 100644 index 00000000..d519f8bc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1830415 @@ -0,0 +1,15 @@ + +linux-user elf loader issue + +all versions up to 4.0 (I didn't test others) +file affected linux-user/elfload.c +function load_elf_image + +if (phdr[i].p_type == PT_LOAD) { + +- abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; ++ abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; + if (a < loaddr) { + loaddr = a; + +To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1831354 b/results/classifier/gemma3:12b/files/1831354 new file mode 100644 index 00000000..7a2133a6 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1832914 b/results/classifier/gemma3:12b/files/1832914 new file mode 100644 index 00000000..b8d9924e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1832914 @@ -0,0 +1,12 @@ + +Wrong error log when drive is specified qcow but qcow2 image file used. + +On archlinux qemu version 4.0.0 when I type: + +$ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ... + +I get this output in stderr + +qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3 + +image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1833048 b/results/classifier/gemma3:12b/files/1833048 new file mode 100644 index 00000000..8d46c393 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1833048 @@ -0,0 +1,9 @@ + +Guest Agent get-fsinfo doesn't show ZFS volumes + +Calling get-fsinfo on a virtual machine does not include ZFS volumes. Calling on a system with a single ZFS disk (ZFS as root fs) simply returns '[]', if other disks exist on the guest it only shows these. + +Expected behaviour: Show file system details like with other fs formats. + +Tried with debian stretch default qemu-guest-agent package and v4.0.0 from git, compiled locally - result is the same. +Host is using QEMU 3.0.1, but that shouldn't matter, right? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1833871 b/results/classifier/gemma3:12b/files/1833871 new file mode 100644 index 00000000..f6c26d3d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1833871 @@ -0,0 +1,17 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1836430 b/results/classifier/gemma3:12b/files/1836430 new file mode 100644 index 00000000..67d5c46d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1836430 @@ -0,0 +1,9 @@ + +Can't install on Windows 10 + +Latest release (20190712) 64-bit doesn't install: + +The setup seems to work fine at first and actually extract all the files needed for qemu in the correct location, but after it has done that, it proceeds to delete every file and leaves no trace of qemu except the installation folder. +The setup then finishes and notifies the user that it has been installed succesfully. + +I downloaded the previous release and it installs correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1836453 b/results/classifier/gemma3:12b/files/1836453 new file mode 100644 index 00000000..06d2014f --- /dev/null +++ b/results/classifier/gemma3:12b/files/1836453 @@ -0,0 +1,34 @@ + +"qemu-nsis\*.bmp" -> no files found" when building with MXE + +Already reported for 4.0: +https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07005.html + +host: Docker qemu:debian-win32-cross + +$ make installer +(cd /tmp/qemu-nsis; \ + for i in qemu-system-*.exe; do \ + arch=${i%.exe}; \ + arch=${arch#qemu-system-}; \ + echo Section \"$arch\" Section_$arch; \ + echo SetOutPath \"\$INSTDIR\"; \ + echo File \"\${BINDIR}\\$i\"; \ + echo SectionEnd; \ + done \ + ) >/tmp/qemu-nsis/system-emulations.nsh +makensis -V2 -NOCD \ + -DCONFIG_DOCUMENTATION="y" \ + \ + -DBINDIR="/tmp/qemu-nsis" \ + \ + -DSRCDIR="/source/qemu" \ + -DOUTFILE="qemu-setup-4.0.90.exe" \ + -DDISPLAYVERSION="4.0.90" \ + /source/qemu/qemu.nsi +File: "/tmp/qemu-nsis\*.bmp" -> no files found. +Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] | + /oname=outfile one_file_only) +Error in script "/source/qemu/qemu.nsi" on line 122 -- aborting creation process +Makefile:1077: recipe for target 'qemu-setup-4.0.90.exe' failed +make: *** [qemu-setup-4.0.90.exe] Error 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1838703 b/results/classifier/gemma3:12b/files/1838703 new file mode 100644 index 00000000..765eedac --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1839294 b/results/classifier/gemma3:12b/files/1839294 new file mode 100644 index 00000000..30f46de9 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1840648 b/results/classifier/gemma3:12b/files/1840648 new file mode 100644 index 00000000..2ca6f0d2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1840865 b/results/classifier/gemma3:12b/files/1840865 new file mode 100644 index 00000000..a5209862 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1842925 b/results/classifier/gemma3:12b/files/1842925 new file mode 100644 index 00000000..774d3523 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1842925 @@ -0,0 +1,105 @@ + +no batmap on convertion from qcow2 to vhd + +we run following version of qemu-img: +$ qemu-img --version +qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.41), Copyright (c) 2004-2008 Fabrice Bellard +$ + +Here is os version: +$ cat /etc/os-release +NAME="Ubuntu" +VERSION="16.04.6 LTS (Xenial Xerus)" +ID=ubuntu +ID_LIKE=debian +PRETTY_NAME="Ubuntu 16.04.6 LTS" +VERSION_ID="16.04" +HOME_URL="http://www.ubuntu.com/" +SUPPORT_URL="http://help.ubuntu.com/" +BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" +VERSION_CODENAME=xenial +UBUNTU_CODENAME=xenial +$ + +When we use qemu-img for conversion of qcow2 to vhd newly created file doesnt show batmap summary when we run: + +# vhd-util read -p -n centos76.vhd +VHD Footer Summary: +------------------- +Cookie : conectix +Features : (0x00000002) <RESV> +File format version : Major: 1, Minor: 0 +Data offset : 512 +Timestamp : Mon Mar 4 13:21:27 2019 +Creator Application : 'qemu' +Creator version : Major: 5, Minor: 3 +Creator OS : Windows +Original disk size : 8192 MB (8590417920 Bytes) +Current disk size : 8192 MB (8590417920 Bytes) +Geometry : Cyl: 16645, Hds: 16, Sctrs: 63 + : = 8192 MB (8590417920 Bytes) +Disk type : Dynamic hard disk +Checksum : 0xfffff119|0xfffff119 (Good!) +UUID : 23772822-a66c-45a2-be37-8474604147c7 +Saved state : No +Hidden : 0 + +VHD Header Summary: +------------------- +Cookie : cxsparse +Data offset (unusd) : 18446744073709 +Table offset : 1536 +Header version : 0x00010000 +Max BAT size : 4097 +Block size : 2097152 (2 MB) +Parent name : +Parent UUID : 00000000-0000-0000-0000-000000000000 +Parent timestamp : Fri Dec 31 19:00:00 1999 +Checksum : 0xfffff466|0xfffff466 (Good!) + +# + +I am not so strong in VHD format details and not exactly sure how batmap is needed, but when I do conversion of qcow2 image by using vhd-util at the end I get file with proper batmap summary. + +In our environment we use CloudStack and Citrix and we use those converted from qcow2 to vhd images as templates. In general there is no problems, but whenever we create snapshot out of VM created from such template vhd-util read command starts giving us error like below: + +# +------------------- +Cookie : conectix +Features : (0x00000002) <RESV> +File format version : Major: 1, Minor: 0 +Data offset : 512 +Timestamp : Thu Aug 29 16:04:30 2019 +Creator Application : 'tap' +Creator version : Major: 1, Minor: 3 +Creator OS : Unknown! +Original disk size : 8194 MB (8592031744 Bytes) +Current disk size : 8194 MB (8592031744 Bytes) +Geometry : Cyl: 16648, Hds: 16, Sctrs: 63 + : = 8193 MB (8591966208 Bytes) +Disk type : Dynamic hard disk +Checksum : 0xfffff074|0xfffff074 (Good!) +UUID : 2b3cac7d-16e1-4771-b8cd-bb8c7876c761 +Saved state : No +Hidden : 0 + +VHD Header Summary: +------------------- +Cookie : cxsparse +Data offset (unusd) : 18446744073709 +Table offset : 1536 +Header version : 0x00010000 +Max BAT size : 4097 +Block size : 2097152 (2 MB) +Parent name : +Parent UUID : 00000000-0000-0000-0000-000000000000 +Parent timestamp : Sat Jan 1 00:00:00 2000 +Checksum : 0xfffff466|0xfffff466 (Good!) + +failed to get batmap header + +# + +With the templates that show correct batmap summary that are created by conversion of qcow2 image by vhd-util convert we don't have such problems. + +So I wanted to check with community if not existence of the batmap can cause (be the reason of) this behaviour later on snapshot creation stage? Should we always have batmap summary on output of vhd-util read command? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1845580 b/results/classifier/gemma3:12b/files/1845580 new file mode 100644 index 00000000..60339603 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1845580 @@ -0,0 +1,10 @@ + +issue with QEMU on Raspberry Pi failing to access CDROM + +I am trying to access the CDROM (iso) from QEMU using FreeDOS and I get an error when doing a directory for: + +i can boot from the iso but if i exit to access the files from the CDROM ISO i get the attached error. + +I believe there is an issue with the QEMU for the Raspberry Pi. + +I am using a Raspberry Pi3 with the latest full Raspbian Buster load \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1847793 b/results/classifier/gemma3:12b/files/1847793 new file mode 100644 index 00000000..c1c224e1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1847793 @@ -0,0 +1,46 @@ + +qemu 4.1.0 - Corrupt guest filesystem after new vm install + +When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. + +Testet with: +- RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) +Guided install with the graphical installer, no lvm selected. +- Debian Stable/Buster (Debian uses ext4 for / and /home partition) +Guidet install with the graphical installer and default options. + +Used commandline to create the vm disk image: +qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G + +Used qemu commandline for vm installation: +#!/bin/sh +# vmtest10 Installation +# +/usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ + -soundhw hda \ + -M q35 \ + -k de \ + -vga qxl \ + -machine accel=kvm \ + -m 4096 \ + -display gtk \ + -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ + -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ + -boot once=d,menu=off \ + -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ + -netdev bridge,br=br0,id=vlan0 \ + -rtc base=localtime \ + -name "vmtest10" \ + -usb -device usb-tablet \ + -spice disable-ticketing \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent $* + +Host OS: +Archlinux (last updated at 10.10.2019) +Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux +No libvirt in use. + + +With qemu 4.0.0 it works fine without any errors. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1848556 b/results/classifier/gemma3:12b/files/1848556 new file mode 100644 index 00000000..6a11acc4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1848556 @@ -0,0 +1,11 @@ + +qemu-img check failing on remote image in Eoan + +The "qemu-img check" function is failing on remote (HTTP-hosted) images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils version 1:3.1+dfsg-2ubuntu3.5, the following worked: + +$ /usr/bin/qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img +No errors were found on the image. +19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters +Image end offset: 514064384 + +The 10.193.37.117 server holds an Apache server that hosts the cloud images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-0ubuntu9, the same command never returns. (I've left it for up to an hour with no change.) I'm able to wget the image from the same server and installation on which qemu-img check fails. I've tried several .img files on the server, ranging from Bionic to Eoan, with the same results with all of them. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1850000 b/results/classifier/gemma3:12b/files/1850000 new file mode 100644 index 00000000..f04995c9 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1855 b/results/classifier/gemma3:12b/files/1855 new file mode 100644 index 00000000..aac850bc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1855 @@ -0,0 +1,60 @@ + +io-qcow2-iothreads-commit-active test fails in a "minimal" build of QEMU +Description of problem: +The build fails because of the `io-qcow2-iothreads-commit-active` test failure: + +``` +343/412 qemu:block / io-qcow2-iothreads-commit-active ERROR 1.66s exit status 1 +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +--- /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active.out ++++ /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/iothreads-commit-active.out.bad +@@ -11,13 +11,27 @@ + 10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + + Launching VM... +-Creating some background I/O... +-{"return": {}} +-Starting active commit... +-{"return": {}} +-{"execute": "job-complete", "arguments": {"id": "job1"}} +-{"return": {}} +-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_READY", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}} +-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}} +-{"execute": "job-dismiss", "arguments": {"id": "job1"}} +-{"return": {}} ++Traceback (most recent call last): ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 436, in launch ++ self._launch() ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 463, in _launch ++ self._pre_launch() ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/iotests.py", line 841, in _pre_launch ++ super()._pre_launch() ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 143, in _pre_launch ++ self._qtest = QEMUQtestProtocol(self._qtest_path, server=True) ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 54, in __init__ ++ self._sock.bind(self._address) ++OSError: AF_UNIX path too long ++ ++The above exception was the direct cause of the following exception: ++ ++Traceback (most recent call last): ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active", line 65, in <module> ++ vm.launch() ++ File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 449, in launch ++ raise VMLaunchFailure( ++qemu.machine.machine.VMLaunchFailure: OSError: AF_UNIX path too long ++ Command: /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/tests/qemu-iotests/../../qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=3 -mon chardev=mon,mode=control -qtest unix:path=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/tmptfjmlerc/qcow2-file-iothreads-commit-active/qemu-58979-qtest.sock -accel qtest -nodefaults -display none -accel qtest -object iothread,id=iothread0 -object throttle-group,x-bps-write=1048576,id=tg0 -blockdev file,node-name=disk0-file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0.img -blockdev qcow2,node-name=disk0-fmt,file=disk0-file -drive if=none,id=drive0,file=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0-snap.img,format=qcow2,cache=writeback,aio=threads,backing=disk0-fmt,node-name=disk0 -device virtio-scsi,iothread=iothread0 -device scsi-hd,drive=drive0 -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-src.img,node-name=mirror-src-file -blockdev qcow2,file=mirror-src-file,node-name=mirror-src -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-dst.img,node-name=mirror-dst-file -blockdev qcow2,file=mirror-dst-file,node-name=mirror-dst-fmt -blockdev throttle,throttle-group=tg0,file=mirror-dst-fmt,node-name=mirror-dst -device scsi-hd,drive=mirror-src ++ Output: ++ + +(test program exited with status code 1) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` +Steps to reproduce: +1. Install GNU Guix on your GNU/Linux machine. +2. `guix time-machine --url=https://gitlab.com/Apteryks/guix --branch=qemu-minimal-io-qcow2-iothreads-commit-active-test-failure -- build qemu-minimal --keep-failed` +3. Observe the test failure. The build artifacts are left under /tmp/guix-build-qemu-minimal-8.1.0.drv-0 to inspect. +Additional information: +Attached is the complete build log +[8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz](/uploads/59a0f88a05715c18a6bdb44845b83a18/8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz) diff --git a/results/classifier/gemma3:12b/files/1858046 b/results/classifier/gemma3:12b/files/1858046 new file mode 100644 index 00000000..0ad58493 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1858046 @@ -0,0 +1,29 @@ + +qemu-aarch64 hangs on cptofs during a build of NixOS SD card image + +First, thank you for this incredible project. + +While following this guide to build my own image of NixOS: https://nixos.wiki/wiki/NixOS_on_ARM#Compiling_through_QEMU on ARM Aarch64. + +I encountered a very strange behavior, qemu is correctly used and build most of the binaries until it executes this exact line over qemu: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-ext4-fs.nix#L55 + +At this step, the qemu process goes to 100 % of CPU, hangs in a certain syscall I don't know which one (according to strace & gdb which has no symbols so breaking and looking the backtrace was useless). + +According to iotop, no I/O was done. + +And it spent all its time in this syscall during more than 10 hours, which looks anomalous to me. + +I attach some of my CPU info: + +model : 142 +model name : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz +stepping : 10 +microcode : 0x96 +cpu MHz : 3107.071 +cache size : 8192 KB + +I'm using a ThinkPad T480 to perform those builds, I'm uncertain of how to debug further this issue, I discussed this with some people over #nixos-aarch64 and they told me they didn't know how to debug it further too. + +I tried all with this package: https://aur.archlinux.org/packages/qemu-arm-static/ — I'm currently compiling qemu-git to see if it happens on upstream too. Will comment when it's done. + +Thank you in advance! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1859989 b/results/classifier/gemma3:12b/files/1859989 new file mode 100644 index 00000000..e9b6e6e5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1859989 @@ -0,0 +1,11 @@ + +qemu-img has broken output with large snapshot names + +On Qemu 4.1.1 the output of snalshots breaks if the chosen state name is too long: + +# qemu-img snapshot -l /mnt/local/some_image.qcow2 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 online_provider_with_dhcp747 MiB 2020-01-15 12:05:01 00:00:45.873 + +Prior to 4.1.1 this used to work with extra tabs for the VM SIZE values. The collision is also disabling us from using a regex on top of this input to detect the snapshot. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1860759 b/results/classifier/gemma3:12b/files/1860759 new file mode 100644 index 00000000..b0315315 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1860759 @@ -0,0 +1,16 @@ + +[REGRESSION] option `-snapshot` ignored with blockdev + +After upgrade of qemu 3.1.0 → 4.2.0 I found that running with libvirt doesn't honor `-snapshot` option anymore. I.e. disk images get modified. +Using `-hda` option honors `-snapshot` + +So I made a test case without libvirt. Testcase using 4.2.0: + +> qemu -hda tmp-16G.img -cdrom regular-rescue-latest-x86_64.iso -m 2G + +This works fine and tmp-16G.img stays unmodified. + +But: +> /usr/bin/qemu-system-x86_64 -name guest=test-linux,debug-threads=on -S -machine pc-i440fx-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,xsaveopt=on,pdpe1gb=on,abm=on -m 2048 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid d32a9191-f51d-4fae-a419-b73d85b49198 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/regular-rescue-latest-x86_64.iso\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-2-format\",\"read-only\":true,\"driver\":\"raw\",\"file\":\"libvirt-2-storage\"} -device ide-cd,bus=ide.0,unit=0,drive=libvirt-2-format,id=ide0-0-0,bootindex=1 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/tmp-2G.img\",\"node-name\":\"libvirt-1-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-1-format\",\"read-only\":false,\"driver\":\"qcow2\",\"file\":\"libvirt-1-storage\",\"backing\":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:d8:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -snapshot -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +This modifies tmp-16G.img. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1861341 b/results/classifier/gemma3:12b/files/1861341 new file mode 100644 index 00000000..981b86aa --- /dev/null +++ b/results/classifier/gemma3:12b/files/1861341 @@ -0,0 +1,31 @@ + +ARM QEMU: Unknown syscall 397 + +QEMU is reporting + +``` +Unknown syscall 397 +``` + +(statx if I read tables right) when used via flatpak for ARM images on x86_64. This has been reproduced on Fedora and Gentoo. + +To reproduce: + +- get flatpak KDE 5.12 for arm: + +flatpak install --user org.kde.Sdk/arm/5.12 org.kde.Platform/arm/5.12 + + +- run qmake inside Sdk: + +QEMU_STRACE=1 flatpak run --filesystem=host --command=qmake org.kde.Sdk/arm/5.12 . + + +You will get a host of messages with unknown syscall. In practice, qmake will fail to find .pro files if you have them in that folder and libraries in the system. + +As far as I understand, Flatpak images are built on AARCH64 hardware. + +My config on Gentoo: + +kernel: 4.19.86-gentoo x86_64 +app-emulation/qemu: ~4.2.0-r1 , same with 4.0.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1865048 b/results/classifier/gemma3:12b/files/1865048 new file mode 100644 index 00000000..02d60140 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1865048 @@ -0,0 +1,43 @@ + +qemu-img --force-share does not disable file locking + +The new option "--force-share" for qemu-img does not disable file locking. + +I tried it with version qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.21~cloud0) and I traced the source code of the current git trunk. + +Sample to demonstrate: + +# strace qemu-img info --force-share testfile.qcow2 2>&1 | grep F_RDLCK +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 + +I traced the passing of the --force-share option through the source code (I used commit 6c599282f8 as of Mon Feb 17 13:32:25 2020 +0000) + +qemu-img.c:img_info() + force_share = true; +qemu-img.c:collect_image_info_list(force_share) +qemu-img.c:img_open(force_share) +qemu-img.c:img_open_file(force_share) + qdict_put_bool(options, BDRV_OPT_FORCE_SHARE, true); +block/block-backend.c:blk_new_open(options) +block.c:bdrv_open(options) +block.c:bdrv_open_inheritoptions() +block.c:bdrv_open_common(options) + bs->force_share = qemu_opt_get_bool(opts, BDRV_OPT_FORCE_SHARE, false); +block.c:bdrv_open_driver(bs) +include/block/block_int.h:int (*bdrv_file_open)(BlockDriverState *bs, QDict *options, int flags, +block/file-posix.c:.bdrv_file_open = raw_open, +block/file-posix.c:raw_open_common(bs) + locking = qapi_enum_parse(&OnOffAuto_lookup, + qemu_opt_get(opts, "locking"), + ON_OFF_AUTO_AUTO, &local_err); + ignoring bs->force_share + +At the end, bs->force_share is ignored in determining the locking value. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1865348 b/results/classifier/gemma3:12b/files/1865348 new file mode 100644 index 00000000..f0ea8eb7 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1865348 @@ -0,0 +1,44 @@ + +virsh domfsinfo testdom crashes the guest agent + + + +[@ ~]# virsh qemu-agent-command vps-01 '{"execute":"guest-get-fsinfo"}' + + +error: Guest agent is not responding: Guest agent disappeared while executing command + +[@ ~]# virsh domfsinfo vps-01 +error: Unable to get filesystem information +error: Guest agent is not responding: Guest agent disappeared while executing command + + +Fault bucket , type 0 +Event Name: APPCRASH +Response: Not available +Cab Id: 0 + +Problem signature: +P1: qemu-ga.exe +P2: 100.0.0.0 +P3: 5c473543 +P4: KERNELBASE.dll +P5: 6.1.7601.24545 +P6: 5e0eb6bd +P7: c0000005 +P8: 000000000000c4d2 +P9: +P10: + +Attached files: + +These files may be available here: +C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_qemu-ga.exe_bd2e6535bdb93328680e0285e89e08f2866db83_49df29e2 + +Analysis symbol: +Rechecking for solution: 0 +Report Id: 2ad29522-5bcc-11ea-bca6-525400e83365 +Report Status: 0 + + +guest os: windows server std 2008r2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1865350 b/results/classifier/gemma3:12b/files/1865350 new file mode 100644 index 00000000..68694139 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1865350 @@ -0,0 +1,32 @@ + +fstrim not working with image mounted to path? + + +guest os: windows server standard 2016 +qemu agent version 100.0.0 + +os supports trimming +path mounted image does not support trimming + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 1 + + +[@ ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + + +Looks like the fstrim does not like/check images mounted on a path? Nor detects if image trimming is supported. xxxx is a ReFS mounted image without trimming support. + +If I enable trimming on the ReFS image, and configure it win2016, the result is still the same. + + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 0 + +[root@c03 ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + +PS. tried this on a win 2016 std server with just one fs, no problems then. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1869073 b/results/classifier/gemma3:12b/files/1869073 new file mode 100644 index 00000000..91fc5f19 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1869073 @@ -0,0 +1,8 @@ + +qemu-arm-static crashes "segmentation fault" when running "git clone -s" + +I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". + +The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". + +I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1869241 b/results/classifier/gemma3:12b/files/1869241 new file mode 100644 index 00000000..effdd870 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1869782 b/results/classifier/gemma3:12b/files/1869782 new file mode 100644 index 00000000..5399f3bc --- /dev/null +++ b/results/classifier/gemma3:12b/files/1869782 @@ -0,0 +1,14 @@ + +qemu-arm-static crashes "segmentation fault" when running "svn checkout" + +I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this. + +Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420 + +I don't get this error with an armv7h chroot. + +Maybe now I'll just try to remove all uses of svn in my build scripts... + +Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it... + +Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1870039 b/results/classifier/gemma3:12b/files/1870039 new file mode 100644 index 00000000..596702ce --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1871 b/results/classifier/gemma3:12b/files/1871 new file mode 100644 index 00000000..35cad615 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1871 @@ -0,0 +1,2 @@ + +Browse qcow2 image contents and add/remove files diff --git a/results/classifier/gemma3:12b/files/1872790 b/results/classifier/gemma3:12b/files/1872790 new file mode 100644 index 00000000..9400b89a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1872790 @@ -0,0 +1,10 @@ + +empty qcow2 + +I plugged multiple qcow2 to a Windows guest. On the Windows disk manager all disks are listed perfectly, with their data, their real space, I even can explore all files on the Explorer, all cool + +On third party disk manager (all of them), I only have the C:\ HDD who act normally, all the other plugged qcow2 are seen as fully unallocated, so I can't manipulate them + +I want to move some partitions, create others, but on Windows disk manager I can't extend or create partition and on third party I didn't see the partitions at all + +Even guestfs doesn't recognize any partition table `libguestfs: error: inspect_os: /dev/sda: not a partitioned device` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1874486 b/results/classifier/gemma3:12b/files/1874486 new file mode 100644 index 00000000..96484c3a --- /dev/null +++ b/results/classifier/gemma3:12b/files/1874486 @@ -0,0 +1,100 @@ + +Bug in qemu-img when converting to streamOptimized vmdk images + +I reviewed #1006655, and I think I'm already on a newer version, so this is either a regression or a new bug. + +I have been recently attempting to convert images from raw and qcow2 formats to vmdk. It appears that the option "subformat=streamOptimized" produces a broken or corrupted disk image. + +Current versions, running on Devuan testing: + +ii ipxe-qemu 1.0.0+git-20190125.36a4c85-1 all PXE boot firmware - ROM images for qemu +ii qemu 1:3.1+dfsg-8+deb10u4 amd64 fast processor emulator, dummy package +ii qemu-efi-aarch64 0~20181115.85588389-3 all UEFI firmware for 64-bit ARM virtual machines +ii qemu-efi-arm 0~20181115.85588389-3 all UEFI firmware for 32-bit ARM virtual machines +ii qemu-kvm 1:3.1+dfsg-8+deb10u4 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20180702+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:3.1+dfsg-8+deb10u4 all QEMU full system emulation (data files) +ii qemu-system-gui 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (user interface and audio support) +ii qemu-system-mips 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:3.1+dfsg-8+deb10u4 amd64 QEMU utilities + +Current uname -a: +Linux laptop-dev 5.4.0-0.bpo.3-amd64 #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) x86_64 GNU/Linux + +Current CPU info: +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 158 +model name : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz +stepping : 10 +microcode : 0xca +cpu MHz : 800.109 +cache size : 9216 KB +physical id : 0 +siblings : 12 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 4399.99 +clflush size : 64 +cache_alignment : 64 +address sizes : 39 bits physical, 48 bits virtual +power management: + +$ cat /proc/meminfo +MemTotal: 16098356 kB +MemFree: 2292720 kB +MemAvailable: 12323616 kB + + +Steps to reproduce: +1) Create a base o/s image in .qcow2 or raw format. I am using a Debian 10 (buster) image, and my images are created using packer 1.5.5. +2) Verify that the base image in .qcow2 format boots correctly in virt-manager when attached to a new VM. +3) Convert the image to vmdk using the following command: +qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,hwversion=6 <image name>.qcow2 <image name>.vmdk +4) Create a new VM using the newly-created .vmdk, being sure to make the storage adapter SCSI +Result: The image, on boot, will display many disk read errors. It will boot, but will start in read-only mode. + +This same image will also not boot correctly in ESXi or VirtualBox. In any of the three hypervisor environments, the bootloader menu (grub2) shows up correctly, but the machine will fail to boot correctly. + + +I reviewed the vmdk header, and the output is here: + +dd if=base.vmdk of=output-vm-disk1.descriptor bs=1 skip=512 count=1024 + +$ cat output-vm-disk1.descriptor +# Disk DescriptorFile +version=1 +CID=2120740c +parentCID=ffffffff +createType="streamOptimized" + +# Extent description +RW 61440000 SPARSE "base.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "6" +ddb.geometry.cylinders = "3824" +ddb.geometry.heads = "255" +ddb.geometry.sectors = "63" +ddb.adapterType = "lsilogic" + +Removing the "subformat=streamOptimized" argument from the qemu-img conversion command results in a working, albeit much larger image, with no disk read errors. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1874678 b/results/classifier/gemma3:12b/files/1874678 new file mode 100644 index 00000000..f9d58269 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1874678 @@ -0,0 +1,4 @@ + +[Feature request] python-qemu package + +It would be useful to have the python/qemu/ files publish as a Python pip package, so users from distribution can also use the QEMU python methods (in particular for testing) without having to clone the full repository. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1877384 b/results/classifier/gemma3:12b/files/1877384 new file mode 100644 index 00000000..89f187ff --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1877418 b/results/classifier/gemma3:12b/files/1877418 new file mode 100644 index 00000000..48cadfe0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1877418 @@ -0,0 +1,7 @@ + +qemu-nbd freezes access to VDI file + +Mounted Oracle Virtualbox .vdi drive, which has GTP+BTRFS: +sudo qemu-nbd -c /dev/nbd0 /storage/btrfs.vdi + +Then I am operating on the btrfs filesystem and suddenly it freezes. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1877688 b/results/classifier/gemma3:12b/files/1877688 new file mode 100644 index 00000000..2a5cd439 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1881648 b/results/classifier/gemma3:12b/files/1881648 new file mode 100644 index 00000000..ff742262 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1883083 b/results/classifier/gemma3:12b/files/1883083 new file mode 100644 index 00000000..90fe7923 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1883083 @@ -0,0 +1,46 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1883414 b/results/classifier/gemma3:12b/files/1883414 new file mode 100644 index 00000000..9a801858 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1884169 b/results/classifier/gemma3:12b/files/1884169 new file mode 100644 index 00000000..534de920 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1884169 @@ -0,0 +1,6 @@ + +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' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1884982 b/results/classifier/gemma3:12b/files/1884982 new file mode 100644 index 00000000..d98a20c0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1884982 @@ -0,0 +1,15 @@ + +User-emu documentation mentions inexistent "runtime" downloads + +The official documentation for the user-space emulator[1] contains many references to binary blobs no longer provided by QEMU.org for download. The parts mentioning them should be rephrased to avoid confusion and instructions for building these components should be provided (maybe as a reference to the LFS book with some scripts). The specific parts are: + +* qemu-XXX-i386-wine.tar.gz, a wine build under the prefix /wine. +* qemu-runtime-i386-XXX-.tar.gz, a glibc build. + + [1]: https://www.qemu.org/docs/master/user/main.html + +In addition, the documentation contains many other instances of inexistent "tar.gz" files, such as in "Network emulation". Most of these are inherited from the days of texi documentation more than 10 years ago, and they are so old that GitHub's blame have become unreliable. Someone really should run `fgrep -r 'tar.gz' doc' on the QEMU source tree. + +The issue was previously reported as [2], but nobody bother enough to google the filename to find out where the confused user got the idea from. + + [2]: https://<email address hidden>/msg569174.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1888467 b/results/classifier/gemma3:12b/files/1888467 new file mode 100644 index 00000000..5dbefd01 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1888467 @@ -0,0 +1,13 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1888728 b/results/classifier/gemma3:12b/files/1888728 new file mode 100644 index 00000000..7e8acee5 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1889421 b/results/classifier/gemma3:12b/files/1889421 new file mode 100644 index 00000000..1395498c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1893010 b/results/classifier/gemma3:12b/files/1893010 new file mode 100644 index 00000000..612aa669 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1893667 b/results/classifier/gemma3:12b/files/1893667 new file mode 100644 index 00000000..2d7d4e99 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1893667 @@ -0,0 +1,30 @@ + +Btrfs commands don't work when using user-space emulation of other architectures + +Description of problem: +When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. + +This is especially important for being able to do cross-arch image builds. + +How reproducible: +Always (on Fedora 33 with qemu-5.1.0-2.fc33) + +Steps to Reproduce: + +$ sudo dnf install mock qemu-user-static wget +$ sudo usermod -a -G mock $USER +$ newgrp mock +$ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux +$ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' + + +Actual results: +Fails with errors like "ERROR: cannot create subvolume: Function not implemented" + +Expected results: +Succeeds and creates subvolumes properly. + +Additional info: +There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... + +https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1893807 b/results/classifier/gemma3:12b/files/1893807 new file mode 100644 index 00000000..edb3816a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1895122 b/results/classifier/gemma3:12b/files/1895122 new file mode 100644 index 00000000..4eb3a820 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1895399 b/results/classifier/gemma3:12b/files/1895399 new file mode 100644 index 00000000..5887ef9b --- /dev/null +++ b/results/classifier/gemma3:12b/files/1895399 @@ -0,0 +1,26 @@ + +Docfix: add missing virtiofsd cache default 'auto' + +The usage command line for virtiofsd has: + +void fuse_cmdline_help(void) +{ + printf(" -h --help print help\n" +... + " -o cache=<mode> cache mode. could be one of \"auto, " + "always, none\"\n" + " default: auto\n" + + +But the default: auto info is missing from the man page. I suggest this patch: + +--- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 ++++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +@@ -106,6 +106,7 @@ + forbids the FUSE client from caching to achieve best coherency at the cost of + performance. ``auto`` acts similar to NFS with a 1 second metadata cache + timeout. ``always`` sets a long cache lifetime at the expense of coherency. ++ The default is ``auto``. + + Examples + -------- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1896096 b/results/classifier/gemma3:12b/files/1896096 new file mode 100644 index 00000000..86421d9d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1896096 @@ -0,0 +1,28 @@ + +Git version: Build process is broken in block_curl.c.o + +Gcc version: 10.2.0 +Glusterfs: 8.1 +Libguestfs: 1.42 + +Configure options used: + +configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --extra-ldflags="$LDFLAGS" \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +Error log attached. Here is the beginning: + +/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/Scrt1.o: in function `_start': +(.text+0x24): undefined reference to `main' +/usr/bin/ld: libblock-curl.a(block_curl.c.o): in function `curl_block_init': \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1901892 b/results/classifier/gemma3:12b/files/1901892 new file mode 100644 index 00000000..23802fe8 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1905979 b/results/classifier/gemma3:12b/files/1905979 new file mode 100644 index 00000000..58fe462e --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1907776 b/results/classifier/gemma3:12b/files/1907776 new file mode 100644 index 00000000..f1c04397 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1907776 @@ -0,0 +1,21 @@ + +Mounting VFat drive yields error messages. + +Mounting a virtual Fat drive results in error messages (see attached image). + +* https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. + + Archlinux 5.9.11-arch2-1 (64-bit) + qemu-headless 5.1.0-3 + + qemu-system-x86_64 -boot order=d -name test \ + -enable-kvm -m 2G -cpu host -k sv \ + -daemonize \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ + -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ + -vnc :1 \ + -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ + -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1911666 b/results/classifier/gemma3:12b/files/1911666 new file mode 100644 index 00000000..d8d2e8c5 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1912224 b/results/classifier/gemma3:12b/files/1912224 new file mode 100644 index 00000000..ee7d6e0e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1912224 @@ -0,0 +1,128 @@ + +qemu may freeze during drive-mirroring on fragmented FS + + +We have odd behavior in operation where qemu freeze during long +seconds, We started an thread about that issue here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05623.html + +It happens at least during openstack nova snapshot (qemu blockdev-mirror) +or live block migration(which include network copy of disk). + +After further troubleshoots, it seems related to FS fragmentation on host. + +reproducible at least on: +Ubuntu 18.04.3/4.18.0-25-generic/qemu-4.0 +Ubuntu 16.04.6/5.10.6/qemu-5.2.0-rc2 + +# Lets create a dedicated file system on a SSD/Nvme 60GB disk in my case: +$sudo mkfs.ext4 /dev/sda3 +$sudo mount /dev/sda3 /mnt +$df -h /mnt +Filesystem Size Used Avail Use% Mounted on +/dev/sda3 59G 53M 56G 1% /mnt + +#Create a fragmented disk on it using 2MB Chunks (about 30min): +$sudo python3 create_fragged_disk.py /mnt 2 +Filling up FS by Creating chunks files in: /mnt/chunks +We are probably full as expected!!: [Errno 28] No space left on device +Creating fragged disk file: /mnt/disk + +$ls -lhs +59G -rw-r--r-- 1 root root 59G Jan 15 14:08 /mnt/disk + +$ sudo e4defrag -c /mnt/disk + Total/best extents 41971/30 + Average size per extent 1466 KB + Fragmentation score 2 + [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag] + This file (/mnt/disk) does not need defragmentation. + Done. + +# the tool^^^ says it is not enough fragmented to be able to defrag. + +#Inject an image on fragmented disk +sudo chown ubuntu /mnt/disk +wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img +qemu-img convert -O raw bionic-server-cloudimg-amd64.img \ + bionic-server-cloudimg-amd64.img.raw +dd conv=notrunc iflag=fullblock if=bionic-server-cloudimg-amd64.img.raw \ + of=/mnt/disk bs=1M +virt-customize -a /mnt/disk --root-password password:xxxx + +# logon run console activity ex: ping -i 0.3 127.0.0.1 +$qemu-system-x86_64 -m 2G -enable-kvm -nographic \ + -chardev socket,id=test,path=/tmp/qmp-monitor,server,nowait \ + -mon chardev=test,mode=control \ + -drive file=/mnt/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none,discard\ + -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on + +$sync +$echo 3 | sudo tee -a /proc/sys/vm/drop_caches + +#start drive-mirror via qmp on another SSD/nvme partition +nc -U /tmp/qmp-monitor +{"execute":"qmp_capabilities"} +{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","target":"/home/ubuntu/mirror","sync":"full","format":"qcow2"}} +^^^ qemu console may start to freeze at this step. + +NOTE: + - smaller chunk sz and bigger disk size the worst it is. + In operation we also have issue on 400GB disk size with average 13MB/extent + - Reproducible also on xfs + + +Expected behavior: +------------------- +QEMU should remain steady, eventually only have decrease storage Performance +or mirroring, because of fragmented fs. + +Observed behavior: +------------------- +Perf of mirroring is still quite good even on fragmented FS, +but it breaks qemu. + + +###################### create_fragged_disk.py ############ +import sys +import os +import tempfile +import glob +import errno + +MNT_DIR = sys.argv[1] +CHUNK_SZ_MB = int(sys.argv[2]) +CHUNKS_DIR = MNT_DIR + '/chunks' +DISK_FILE = MNT_DIR + '/disk' + +if not os.path.exists(CHUNKS_DIR): + os.makedirs(CHUNKS_DIR) + +with open("/dev/urandom", "rb") as f_rand: + mb_rand=f_rand.read(1024 * 1024) + +print("Filling up FS by Creating chunks files in: ",CHUNKS_DIR) +try: + while True: + tp = tempfile.NamedTemporaryFile(dir=CHUNKS_DIR,delete=False) + for x in range(CHUNK_SZ_MB): + tp.write(mb_rand) + os.fsync(tp) + tp.close() +except Exception as ex: + print("We are probably full as expected!!: ",ex) + +chunks = glob.glob(CHUNKS_DIR + '/*') + +print("Creating fragged disk file: ",DISK_FILE) +with open(DISK_FILE, "w+b") as f_disk: + for chunk in chunks: + try: + os.unlink(chunk) + for x in range(CHUNK_SZ_MB): + f_disk.write(mb_rand) + os.fsync(f_disk) + except IOError as ex: + if ex.errno != errno.ENOSPC: + raise +###########################################################3 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1913 b/results/classifier/gemma3:12b/files/1913 new file mode 100644 index 00000000..aab9e5bd --- /dev/null +++ b/results/classifier/gemma3:12b/files/1913 @@ -0,0 +1,20 @@ + +Regression in 8.1.1: qemu-aarch64-static running ldconfig +Description of problem: +Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) +Steps to reproduce: +1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ +2. Extract it +3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 + +```bash +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.0 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<works> +$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.1 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<segfault> +``` diff --git a/results/classifier/gemma3:12b/files/1913012 b/results/classifier/gemma3:12b/files/1913012 new file mode 100644 index 00000000..d2fd77e7 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1916501 b/results/classifier/gemma3:12b/files/1916501 new file mode 100644 index 00000000..8b2e5a3e --- /dev/null +++ b/results/classifier/gemma3:12b/files/1916501 @@ -0,0 +1,31 @@ + +qemu-img convert segfaults with specific URL + +Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +0000) + +$ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img +Segmentation fault (core dumped) + + +Backtrace for convenience: +qemu: qemu_mutex_lock_impl: Invalid argument + +Thread 1 "qemu-img" received signal SIGABRT, Aborted. +0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +#1 0x00007ffff77ae8a4 in abort () from /lib64/libc.so.6 +#2 0x00005555556705b2 in error_exit (err=<optimized out>, msg=msg@entry=0x5555556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 +#3 0x0000555555670945 in qemu_mutex_lock_impl (mutex=0x555555ae3758, file=0x5555556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 +#4 0x000055555559a05b in curl_multi_do (arg=0x555555aad2a0) at ../block/curl.c:406 +#5 0x000055555566193a in aio_dispatch_handler (ctx=ctx@entry=0x555555737790, node=0x555555b14150) at ../util/aio-posix.c:329 +#6 0x0000555555662072 in aio_dispatch_handlers (ctx=0x555555737790) at ../util/aio-posix.c:372 +#7 aio_dispatch (ctx=0x555555737790) at ../util/aio-posix.c:382 +#8 0x000055555564442e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 +#9 0x00007ffff7cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#10 0x000055555566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=4397000000) at ../util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 +#13 0x0000555555581edd in convert_do_copy (s=0x7fffffffd3a0) at ../qemu-img.c:2139 +#14 img_convert (argc=<optimized out>, argv=<optimized out>) at ../qemu-img.c:2738 +#15 0x00005555555783b1 in main (argc=7, argv=<optimized out>) at ../qemu-img.c:5536 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1916655 b/results/classifier/gemma3:12b/files/1916655 new file mode 100644 index 00000000..69462997 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1916655 @@ -0,0 +1,32 @@ + +Compilation fails due to zstd qcow2 compression + +Compilation of QEMU fails when using recent versions of zstd. + +I use the following commands to compile QEMU: +$ mkdir build +$ cd build +$ ../configure --enable-debug --target-list=x86_64-softmmu +$ make -j $(nproc) + +Here is a paste from the ../configure output: +https://paste.ubuntu.com/p/dHsWzGV7TH/ + +And one from the make output: +https://paste.ubuntu.com/p/89qKk4NrFz/ + +In short the error boils down to: +../block/qcow2-threads.c: In function ‘qcow2_zstd_compress’: +../block/qcow2-threads.c:225:16: error: implicit declaration of function ‘ZSTD_compressStream2’; did you mean ‘ZSTD_compressStream’? [-Werror=implicit-function-declaration] + 225 | zstd_ret = ZSTD_compressStream2(cctx, &output, &input, ZSTD_e_end); + | ^~~~~~~~~~~~~~~~~~~~ + | ZSTD_compressStream +../block/qcow2-threads.c:225:16: error: nested extern declaration of ‘ZSTD_compressStream2’ [-Werror=nested-externs] +../block/qcow2-threads.c:225:60: error: ‘ZSTD_e_end’ undeclared (first use in this function) + 225 | zstd_ret = ZSTD_compressStream2(cctx, &output, &input, ZSTD_e_end); + | + +System info: +QEMU commit: 7ef8134565dccf9186d5eabd7dbb4ecae6dead87 (from Github) +Kernel: 5.10.15 +zstd: 1.4.8 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1920211 b/results/classifier/gemma3:12b/files/1920211 new file mode 100644 index 00000000..247dd585 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1923 b/results/classifier/gemma3:12b/files/1923 new file mode 100644 index 00000000..caf094ed --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1923583 b/results/classifier/gemma3:12b/files/1923583 new file mode 100644 index 00000000..bc2f2aa2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1923583 @@ -0,0 +1,38 @@ + +colo: pvm flush failed after svm killed + +Hi, + Primary vm flush failed after killing svm, which leads primary vm guest filesystem unavailable. + +qemu versoin: 5.2.0 +host/guest os: CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm (don't remove nbd child from quorum on primary vm)and wait for a minute. the interval depends on guest os. +result: primary vm file system shutdown because of flush cache error. + +After serveral tests, I found that qemu-5.0.0 worked well, and it's the commit https://git.qemu.org/?p=qemu.git;a=commit;h=883833e29cb800b4d92b5d4736252f4004885191(block: Flush all children in generic code) leads this change, and both virtio-blk and ide turned out to be bad. + +I think it's nbd(replication) flush failed leads bdrv_co_flush(quorum_bs) failed, here is the call stack. +#0 bdrv_co_flush (bs=0x56242b3cc0b0=nbd_bs) at ../block/io.c:2856 +#1 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242b3c7e00=replication_bs) at ../block/io.c:2920 +#2 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242a4ad800=quorum_bs) at ../block/io.c:2920 +#3 0x0000562428b70d56 in blk_do_flush (blk=0x56242a4ad4a0) at ../block/block-backend.c:1672 +#4 0x0000562428b70d87 in blk_aio_flush_entry (opaque=0x7fd0980073f0) at ../block/block-backend.c:1680 +#5 0x0000562428c5f9a7 in coroutine_trampoline (i0=-1409269904, i1=32721) at ../util/coroutine-ucontext.c:173 + +While i am not sure whether i use colo inproperly? Can we assume that nbd child of quorum immediately removed right after svm crashed? Or it's really a bug? Does the following patch fix? Help is needed! Thanks a lot！ + +diff --git a/block/quorum.c b/block/quorum.c +index cfc1436..f2c0805 100644 +--- a/block/quorum.c ++++ b/block/quorum.c +@@ -1279,7 +1279,7 @@ static BlockDriver bdrv_quorum = { + .bdrv_dirname = quorum_dirname, + .bdrv_co_block_status = quorum_co_block_status, + +- .bdrv_co_flush_to_disk = quorum_co_flush, ++ .bdrv_co_flush = quorum_co_flush, + + .bdrv_getlength = quorum_getlength, \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1924987 b/results/classifier/gemma3:12b/files/1924987 new file mode 100644 index 00000000..4421959d --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/1933 b/results/classifier/gemma3:12b/files/1933 new file mode 100644 index 00000000..8fbadd31 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1933 @@ -0,0 +1,42 @@ + +qemu 8.1.1 and 7.2.6 live migration with qcow2 attached to vm using postcopy crashes +Description of problem: +Live migrating a vm with a qcow2 disk attached using postcopy will cause vm to crash during migration. +Steps to reproduce: +1. Create a generic vm and attach a qcow2 file to the vm. +<disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/var/lib/libvirt/images/jlow2.qcow2'/> + <target dev='vda' bus='virtio'/> + <boot order='1'/> +</disk> + +2. virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error --postcopy --postcopy-after-precopy --timeout 1 --timeout-postcopy qemu+tcp://10.18.64.118/system + +vm will start migrating and then pause on the source and be shut down on the target once migration switches to postcopy + +Migration: [33.08 %]error: internal error: QEMU unexpectedly closed the monitor (vm='jlow2'): 2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable +2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable +qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed. + + +Logs from source + +2023-10-12 06:23:43.412+0000: initiating migration + +2023-10-12T06:23:44.362392Z qemu-system-x86_64: failed to save SaveStateEntry with id(name): 3(ram): -5 + +2023-10-12T06:23:44.362485Z qemu-system-x86_64: Detected IO failure for postcopy. Migration paused. + +Logs from target + +2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable + +2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable + +qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed. +2023-10-12 06:23:44.408+0000: shutting down, reason=failed + +If postcopy is disabled with command below, migration will succeed: + +virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error qemu+tcp://10.18.64.118/system diff --git a/results/classifier/gemma3:12b/files/1936977 b/results/classifier/gemma3:12b/files/1936977 new file mode 100644 index 00000000..9fb8f2fe --- /dev/null +++ b/results/classifier/gemma3:12b/files/1936977 @@ -0,0 +1,8 @@ + + qemu-arm-static crashes "segmentation fault" when running "git clone" + +This is a reopen of #1869073 for `qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.17 amd64`. + +`git clone` reproducably segfaults in `qemu-arm-static` chroot. + +#1869073 mentions this should have been fixed for newer versions of QEMU, but for `focal` there's no newer version available, even in `focal-backports`. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/1940 b/results/classifier/gemma3:12b/files/1940 new file mode 100644 index 00000000..84c91f54 --- /dev/null +++ b/results/classifier/gemma3:12b/files/1940 @@ -0,0 +1,21 @@ + +Saving vm with shared folder results in Error: State blocked by non-migratable device '000.../vhost-user-fs' +Description of problem: +Saving a vm with savevm in the QEMU Monitor with a shared folder causes the following error message: +`Error: State blocked by non-migratable device '0000:00:05.0/vhost-user-fs'` +Steps to reproduce: +1. Get an qcow2 image that can boot (not sure if working qcow2 image is actually needed) +2. Start virtiofsd with this /usr/libexec/virtiofsd --socket-path=/tmp/virtiofs_socket -o source=/path/to/share +3. Run qemu-system-x86_64 -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem -smp 2 -hda image.qcow2 -vga qxl -virtfs local,path=/path/to/share,mount_tag=share,security_model=passthrough,id=virtiofs -chardev socket,id=char0,path=/tmp/virtiofs_socket -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=share +4. Let the image boot and/or go into the QEMU monitor. +5. type savevm testvm +6. See error. +Additional information: +This happens with both the legacy virtio-fs and the rust version. + +According to the first reply to https://gitlab.com/virtio-fs/virtiofsd/-/issues/81 there needs to be "a lot of changes not only in virtiofsd but also in the rust-vmm crates and qemu (and maybe in the vhost-user protocol)" so I'm reporting this here in the hopes it will speed something up. + +I followed the following to get virtiofsd working with command line QEMU: +https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system + +This is blocking our migration from VirtualBox because it doesn't have problems like this. The least I need is a work around or alternative shared filesystem. We are trying to avoid networked shares. diff --git a/results/classifier/gemma3:12b/files/1959 b/results/classifier/gemma3:12b/files/1959 new file mode 100644 index 00000000..2074fb6d --- /dev/null +++ b/results/classifier/gemma3:12b/files/1959 @@ -0,0 +1,2 @@ + +qemu-img: support ZSTD compression level customization diff --git a/results/classifier/gemma3:12b/files/1997 b/results/classifier/gemma3:12b/files/1997 new file mode 100644 index 00000000..7714543c --- /dev/null +++ b/results/classifier/gemma3:12b/files/1997 @@ -0,0 +1,21 @@ + +Disk corruption on ARM64 (Apple Silicon) Linux VMs +Description of problem: +aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS. This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug. +Steps to reproduce: +1. Install an aarch64 Linux VM using BTRFS as the root filesystem. ZFS might recognize silent corruption readily as well. +2. Run `stress-ng --iomix 4` +3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption. +Additional information: +This is discussed in two other tickets, but I'm hoping to get more attention to the problem here. +[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957) +[](https://github.com/utmapp/UTM/issues/4840) + + + + + +I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow... + + +``` diff --git a/results/classifier/gemma3:12b/files/2001 b/results/classifier/gemma3:12b/files/2001 new file mode 100644 index 00000000..991397d1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2001 @@ -0,0 +1,44 @@ + +qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster. +Description of problem: +qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster. +Steps to reproduce: +create raw and qcow2 disk + +1. qemu-img create -f raw lvm_volume_1.raw 12G +2. qemu-img create -f qcow2 lvm_volume_1.qcow2 12G + + install a centos OS + +3. qemu-system-x86_64 -m 4096 -drive file=lvm_volume_1.qcow2,format=qcow2,index=0 -nographic -cdrom CentOS-8.3.2011-x86_64-dvd1.iso -vnc :25 + + convert the qcow2 OS disk to q raw OS disk + +4. qemu-img convert -f qcow2 -O raw ./lvm_volume_1.qcow2 ./lvm_volume_1.raw + + create a qemu-rbd process + +5. qemu-nbd --fork -x node1 -p 1238 rbd:cephpool- test/volume_1:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx + + boot the raw OS disk + +6. qemu-system-x86_64 -hda ./lvm_volume_1.raw -m 4096 -smp 4 -vnc :25 -monitor stdio + + migrate the raw OS disk to a ceph volume + +7. drive_mirror -n -f #block125 nbd:localhost:1238:exportname=node1 raw + + check the rbd volume USED size in ceph cluster + "rbd du cephpool-test/volume_1" + the ceph rbd volume PROVISION and USED are the same size + + convert the raw OS disk to a ceph volume + +8. qemu-img convert -n -f raw -O raw ./lvm_volume_1.raw rbd:cephpool- +test/volume_2:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx + + check the rbd volume USED size in ceph cluster + "rbd du cephpool-test/volume_2" + the ceph rbd volume PROVISION and USED are different PROVISION > USED +Additional information: + diff --git a/results/classifier/gemma3:12b/files/2004 b/results/classifier/gemma3:12b/files/2004 new file mode 100644 index 00000000..fd47a066 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2004 @@ -0,0 +1,34 @@ + +do_guest_openat /proc interposition doesn't work for openat +Description of problem: +For instance, trying with hppa emulated on top of x86: + +``` +$ hppa-linux-gnu-gcc test.c -o test +$ qemu-hppa-static ./test +``` + +One gets the host cpu information: + +``` +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 142 +model name : Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz +[...] +``` + +while we would want to see the guest cpu information, like the test program does when `#if 0` is turned into `#if 1`: + +``` +processor : 0 +cpu family : PA-RISC 1.1e +cpu : PA7300LC (PCX-L2) +capabilities : os32 +model : 9000/778/B160L - Merlin L2 160 QEMU (9000/778/B160L) +``` + +This is because `do_guest_openat` only checks for the path, and does not look at `dirfd`, so it doesn't recognize that `openat(dirfd, "cpuinfo", O_RDONLY)` is actually opening a file in `/proc`. + +We could probably, when `dirfd` is not `AT_FDCWD`, try to `fstat()` it, open `/proc` with `O_DIRECTORY` and `fstat()` that too, and compare their `st_dev` and `st_ino`? diff --git a/results/classifier/gemma3:12b/files/2029 b/results/classifier/gemma3:12b/files/2029 new file mode 100644 index 00000000..5192854e --- /dev/null +++ b/results/classifier/gemma3:12b/files/2029 @@ -0,0 +1,2 @@ + +[block jobs]Guest hang when dd file on snapshot overlay(iothread enable) diff --git a/results/classifier/gemma3:12b/files/2054889 b/results/classifier/gemma3:12b/files/2054889 new file mode 100644 index 00000000..549eaac0 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/206 b/results/classifier/gemma3:12b/files/206 new file mode 100644 index 00000000..42501cf5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/206 @@ -0,0 +1,2 @@ + +Dos on the fly CD image replacement is not Working with DOS diff --git a/results/classifier/gemma3:12b/files/2062 b/results/classifier/gemma3:12b/files/2062 new file mode 100644 index 00000000..50f2004f --- /dev/null +++ b/results/classifier/gemma3:12b/files/2062 @@ -0,0 +1,2 @@ + +qemu-img snapshot -l output formatting is broken (field to small / whitespace missing) diff --git a/results/classifier/gemma3:12b/files/2075 b/results/classifier/gemma3:12b/files/2075 new file mode 100644 index 00000000..8ba561f4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2075 @@ -0,0 +1,11 @@ + +QGA guest-get-fsinfo can not return windows dynamic volumes +Description of problem: +Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）, + + +get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume. +Steps to reproduce: +virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }' +Additional information: +Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/) diff --git a/results/classifier/gemma3:12b/files/2101 b/results/classifier/gemma3:12b/files/2101 new file mode 100644 index 00000000..65103955 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2101 @@ -0,0 +1,18 @@ + +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/results/classifier/gemma3:12b/files/2102 b/results/classifier/gemma3:12b/files/2102 new file mode 100644 index 00000000..417c8d0a --- /dev/null +++ b/results/classifier/gemma3:12b/files/2102 @@ -0,0 +1,41 @@ + +"qemu-img resize -f qcow2" produces broken disk images +Description of problem: +The documentation of `qemu-img` at +<https://www.qemu.org/docs/master/tools/qemu-img.html> +makes it sound like `qemu-img resize` supports various image formats +(raw, qcow2, etc.) in the same way. + +But it doesn't. While `qemu-img resize -f raw` works as expected, +`qemu-img resize -f qcow2` produces broken disk images. +Steps to reproduce: +``` +$ wget http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz +$ gunzip arm64.img +``` + +First resize, then convert: +``` +$ cp arm64.img arm64-rc.img +$ qemu-img resize -f raw arm64-rc.img 10G +$ qemu-img convert -f raw -O qcow2 arm64-rc.img arm64-rc.qcow2 +$ rm -f arm64-rc.img +``` + +First convert, then resize: +``` +$ qemu-img convert -f raw -O qcow2 arm64.img arm64-cr.qcow2 +$ qemu-img resize -f qcow2 arm64-cr.qcow2 10G +``` + +Attach to a VM in VirtualBox (as an additional SATA disk) and start that VM. + +arm64-rc.qcow2 => +`# fdisk /dev/sdb` => it has two partitions. + +arm64-cr.qcow2 => +`# fdisk /dev/sdb` => it has no partitions! +And the VM cannot be cleanly shut down. I had to manually kill the VirtualBoxVM +process. +Additional information: + diff --git a/results/classifier/gemma3:12b/files/2109 b/results/classifier/gemma3:12b/files/2109 new file mode 100644 index 00000000..9812456b --- /dev/null +++ b/results/classifier/gemma3:12b/files/2109 @@ -0,0 +1,2 @@ + +NetBSD VM fails to install due to missing py311-expat package diff --git a/results/classifier/gemma3:12b/files/211 b/results/classifier/gemma3:12b/files/211 new file mode 100644 index 00000000..90811285 --- /dev/null +++ b/results/classifier/gemma3:12b/files/211 @@ -0,0 +1,2 @@ + +qemu-aarch64-static segfault if /proc not mounted inside chroot diff --git a/results/classifier/gemma3:12b/files/2117 b/results/classifier/gemma3:12b/files/2117 new file mode 100644 index 00000000..0568f713 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2117 @@ -0,0 +1,28 @@ + +Unraid, Ubuntu, 9P/virtio and memory issues +Description of problem: +I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM. + +The logs shows: +-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \ +-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \ + +Inside Ubuntu, I mount the exposed shares like this: + +sudo mount -t 9p -o trans=virtio "backup" /media/share/backup + +I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. + +The issues that I am facing, is that rsync sometimes reports "cannot allocate memory": + +rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12) + +There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues. + +The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors? +Steps to reproduce: +1. Mount as shown +2. Run rsync on folder with lots of files +3. See error +Additional information: +N/A diff --git a/results/classifier/gemma3:12b/files/2171 b/results/classifier/gemma3:12b/files/2171 new file mode 100644 index 00000000..485f3fc2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2179 b/results/classifier/gemma3:12b/files/2179 new file mode 100644 index 00000000..78e0deea --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2190 b/results/classifier/gemma3:12b/files/2190 new file mode 100644 index 00000000..59a18551 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2205 b/results/classifier/gemma3:12b/files/2205 new file mode 100644 index 00000000..010d3e81 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2205 @@ -0,0 +1,51 @@ + +9p rootfs issues +Description of problem: +I've created qemu guest per https://wiki.qemu.org/Documentation/9p_root_fs guidelines. debootstrap fails on this guest. +Steps to reproduce: +``` +root@ubuntu-dev:~# debootstrap --arch amd64 --variant=minbase noble /var/tmp/new_root/ +I: Retrieving InRelease +I: Checking Release signature +E: Error executing gpgv to check Release signature +root@ubuntu-dev:~# +``` +Additional information: +I noticed, that gpg key extracted by debootstrap from the InRelease is corrupted: +``` +root@ubuntu-dev:~# head /var/tmp/new_root/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_noble_Release.gpg +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE9uyzdiR07anSG3Aihxkg0ZkbyTwFAmXkbkUACgkQhxkg0Zkb +-----BEGIN PGP SIGNATURE----- +-----BEGIN PGP SIGNATURE----- + +root@ubuntu-dev:~# +``` +I also noticed that on the 9p filesystem appending to files corrupts them: +``` +root@ubuntu-dev:~# echo 1 >/var/tmp/test +root@ubuntu-dev:~# cat /var/tmp/test +1 +root@ubuntu-dev:~# echo 2 >>/var/tmp/test +root@ubuntu-dev:~# cat /var/tmp/test +1 +1 +2 +root@ubuntu-dev:~# +``` +This is not happening on the tmpfs: +``` +root@ubuntu-dev:~# echo 1 >/tmp/test +root@ubuntu-dev:~# cat /tmp/test +1 +root@ubuntu-dev:~# echo 2 >>/tmp/test +root@ubuntu-dev:~# cat /tmp/test +1 +2 +root@ubuntu-dev:~# +``` diff --git a/results/classifier/gemma3:12b/files/2209 b/results/classifier/gemma3:12b/files/2209 new file mode 100644 index 00000000..8a4350a1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2209 @@ -0,0 +1,48 @@ + +no 'system' llibfdt (or too old), subprojects/dtc/ populated, ./configure --disable-download fails +Description of problem: +./configure ... --disable-download, with subprojects/ pre-populated, fails. +Steps to reproduce: +1. ensure libfdt/dtc files/libs/binaries are *not* found in system +2. have subprojects/dtc pre-populated +3. ./configure --target-list=riscv32-softmmu --prefix=/opt/riscv --enable-debug --without-default-features --without-default-devices --disable-download + +configure fails with: +``` +../meson.build:3171:13: ERROR: C shared or static library 'fdt' not found + +A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` + +If I outcomment the following lines in meson.build: +``` + #if get_option('wrap_mode') == 'nodownload' + # fdt_opt = 'system' + #endif +``` +Then the above command line works (with --disable-download) +Additional information: +The case is where one wants to ensure that configure does not try to access +network while doing its job. And in a system where dtc/libfdt is not available, +(or is too old, line in Centos/RHEL 7) one has dowloaded the files already in +subprojects/dtc/. + +The meson.build clearly sets (as of 2024-03-05) expectation that dtc/libfdt/ +has to come from 'system' if 'wrap_mode' is set to 'nodownload'. + +Without this check it it works nicely -- and if subprojects/dtc/ was not populated, +the error message is + +``` +Library fdt found: NO + +../meson.build:3187:18: ERROR: Automatic wrap-based subproject downloading is disabled + +A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` + +So -- to me -- that looks like it could be a suitable solution to this problem. diff --git a/results/classifier/gemma3:12b/files/2265 b/results/classifier/gemma3:12b/files/2265 new file mode 100644 index 00000000..9ee527f1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2265 @@ -0,0 +1,49 @@ + +qemu-system-x86_64 crash creating snapshot +Description of problem: +I'm facing a crash in qemu-system-x86_64.\ +I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\ +The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\ + +here is the stack: + +(gdb) p bs->children\ +$1 = {lh_first = 0x0}\ +(gdb)\ +(gdb) p child\ +$2 = (BdrvChild *) 0x0\ +(gdb)\ + if (bs->implicit) {\ + /* For implicit nodes, just copy everything from the single child */\ + child = QLIST_FIRST(&bs->children);\ +----->> assert(QLIST_NEXT(child, next) == NULL);\ + pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\ + + +#0 bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\ +#1 0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\ +#2 0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\ +#3 0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\ +#4 0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\ +#5 0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129 +#6 0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\ +#7 aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\ +#8 0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\ +#9 0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\ +#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\ +#11 0x00007fc800000000 in ?? ()\ +#12 0x000003a05cb8b408 in ?? ()\ +#13 0x0000000000000000 in ?? ()\ + +The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\ +Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\ + +I fixed the problem by just doing:\ +child = QLIST_FIRST(&bs->children);\ +if (bs->implicit && (child != NULL)) {\ + assert(QLIST_NEXT(child, next) == NULL);\ + ....\ +}\ +I don't have the qemu knowledge to evaluate it and consequences.\ +Is there anyone who have any idea ?\ +Thank you very much.\ diff --git a/results/classifier/gemma3:12b/files/2368 b/results/classifier/gemma3:12b/files/2368 new file mode 100644 index 00000000..7b614dcf --- /dev/null +++ b/results/classifier/gemma3:12b/files/2368 @@ -0,0 +1,2 @@ + +Get get_maintainer.pl working with cover letter files diff --git a/results/classifier/gemma3:12b/files/2369 b/results/classifier/gemma3:12b/files/2369 new file mode 100644 index 00000000..39abda6a --- /dev/null +++ b/results/classifier/gemma3:12b/files/2369 @@ -0,0 +1,2 @@ + +qemu-img measure is incorrect when using discard-no-unref diff --git a/results/classifier/gemma3:12b/files/2400 b/results/classifier/gemma3:12b/files/2400 new file mode 100644 index 00000000..997f3dd5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2400 @@ -0,0 +1,44 @@ + +Qemu fails to boot snapshot image if its header is qcow2 but its payload and backing image extension are luks +Description of problem: +Qemu fails to recognize snapshot image E:\\test_snapshot.qcow2 saying Volume is not in LUKS format + +You need three commands to reproduce: + +`qemu-img create -f luks --object secret,id=sec0,data=123 -o key-secret=sec0 E:\test.luks 1G` + +`qemu-img create --object secret,id=sec0,data=123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 -b E:\test.luks -F luks E:\test_snapshot.qcow2` + +`qemu-system-x86_64 -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0 -object secret,id=sec0,data=123` + +This error is printed: + +`qemu-system-x86_64: -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0: Volume is not in LUKS format` + +But fourth command shows that payload of `E:\test_snapshot.qcow2` has LUKS format: + +`qemu-img info E:\test_snapshot.qcow2` + +\[output\] + +```bash +virtual size: 1 GiB (1073741824 bytes) +disk size: 2.25 MiB +encrypted: yes +cluster_size: 65536 +backing file: E:\test.luks +backing file format: luks +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + encrypt: + ivgen alg: plain64 + detached header: false + hash alg: sha256 + cipher alg: aes-256 + uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + format: luks + cipher mode: xts ... +``` diff --git a/results/classifier/gemma3:12b/files/2405 b/results/classifier/gemma3:12b/files/2405 new file mode 100644 index 00000000..30fa9ec0 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2417 b/results/classifier/gemma3:12b/files/2417 new file mode 100644 index 00000000..f99fc13f --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2424 b/results/classifier/gemma3:12b/files/2424 new file mode 100644 index 00000000..46d04ef5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2424 @@ -0,0 +1,319 @@ + +Fatal error: futex robust_list not initialized by pthreads (Unknown syscall 386) +Description of problem: +Seems like steamcmd modified their binary with a function unimplemented by QEMU just recently. This was working perfectly until then. I did some strace debugging and came up with this error: `set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented)`. I even tried doing `qemu-arm` over `box86` just to see if it'll work but still got that same error. However, using `box86` alone worked. + +I have my reasons of wanting to use `qemu-i386` over `box86` mainly due to it being compilable into an ARM64 binary unlike `box86` which is only an ARM binary. Performance doesn't really matter as it's only being used to download server files. Running QEMU was the only option working for people on M-series Macs to run steamcmd in a container reliably over Docker Desktop as those CPUs don't have 32-bit support. Even if I force them to use only `box86`, Mac's Docker Desktop runs QEMU over the image to emulate 32-bit support which causes the same error. +Steps to reproduce: +1. Install Docker +2. Run `docker run -it --pull=always sonroyaalmerol/steamcmd-arm64:root` +3. Inside the container shell, run `LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/steam/steamcmd/linux32 qemu-i386-static /home/steam/steamcmd/linux32/steamcmd +@sSteamCmdForcePlatformType linux +@sSteamCmdForcePlatformBitness 64 +force_install_dir "/palworld" +login anonymous +app_update 2394010 validate +quit` +Additional information: +I'm running all these inside a Docker container. I maintain a Docker image that is meant to be a base image for steamcmd-based dedicated servers (https://github.com/sonroyaalmerol/steamcmd-arm64). + +I tried both the `qemu-user-static` package from Debian repos (which I believe is v7.2) and building straight from the source (stable-9.0 tag) with no luck. + +strace from the command: +``` +25 brk(NULL) = 0x00a89000 +25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40839000 +25 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0 +25 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffe38) = 0 +25 mmap2(NULL,11734,PROT_READ,MAP_PRIVATE,3,0) = 0x4083b000 +25 close(3) = 0 +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x408000a0,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdd8) = 0 +25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4083e000 +25 mmap2(0x4083f000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4083f000 +25 mmap2(0x40840000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40840000 +25 mmap2(0x40841000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40841000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800080,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0 +25 mmap2(NULL,16400,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40843000 +25 mmap2(0x40844000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x40844000 +25 mmap2(0x40845000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40845000 +25 mmap2(0x40846000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40846000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800060,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd98) = 0 +25 mmap2(NULL,1065052,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40848000 +25 mmap2(0x40855000,786432,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xd) = 0x40855000 +25 mmap2(0x40915000,221184,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xcd) = 0x40915000 +25 mmap2(0x4094b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x103) = 0x4094b000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800040,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd78) = 0 +25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4094d000 +25 mmap2(0x4094e000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4094e000 +25 mmap2(0x4094f000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x4094f000 +25 mmap2(0x40950000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40950000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800020,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd58) = 0 +25 mmap2(NULL,2259228,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40952000 +25 mmap2(0x40974000,1544192,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x22) = 0x40974000 +25 mmap2(0x40aed000,524288,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x19b) = 0x40aed000 +25 mmap2(0x40b6d000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x21b) = 0x40b6d000 +25 mmap2(0x40b70000,39196,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x40b70000 +25 close(3) = 0 +25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7a000 +25 mmap2(NULL,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7c000 +25 set_thread_area(0x408008b0) = 0 +25 set_tid_address(0x40b7be28) = 25 +25 set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented) +25 Unknown syscall 386 +25 mprotect(0x40b6d000,8192,PROT_READ) = 0 +25 mprotect(0x40950000,4096,PROT_READ) = 0 +25 mprotect(0x4094b000,4096,PROT_READ) = 0 +25 mprotect(0x40846000,4096,PROT_READ) = 0 +25 mprotect(0x40841000,4096,PROT_READ) = 0 +25 mprotect(0x00a18000,143360,PROT_READ) = 0 +25 mprotect(0x40833000,8192,PROT_READ) = 0 +25 ugetrlimit(3,1082132628,1085730804,1,2097152,1082133208) = 0 +25 munmap(0x4083b000,11734) = 0 +25 getrandom(0x40b72b50,4,1) = 4 +25 brk(NULL) = 0x00a89000 +25 brk(0x00aaa000) = 0x00aaa000 +25 brk(0x00aab000) = 0x00aab000 +25 brk(0x00acc000) = 0x00acc000 +25 futex(0x00a867f0,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 futex(0x00a867f8,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 clock_gettime64(CLOCK_BOOTTIME,0x40800b6c) = 0 ({tv_sec=4668200,tv_nsec=47711961}) +25 gettid() = 25 +25 clock_gettime64(CLOCK_BOOTTIME,0x40800b5c) = 0 ({tv_sec=4668200,tv_nsec=48585844}) +25 getpid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 rt_sigprocmask(SIG_BLOCK,0x407fe9f0,NULL,8) = 0 +25 rt_sigaction(SIGPIPE,0x407fe804,0x407fe890) = 0 +25 ugetrlimit(7,1082125036,1085730804,10725408,13,1082133352) = 0 +25 prlimit64(0,RLIMIT_NOFILE,{rlim_cur=1048576,rlim_max=1048576},NULL) = 0 +25 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fe5bc) = 0 +25 mmap2(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x40b80000 +25 mmap2(NULL,2596864,PROT_READ,MAP_PRIVATE,3,0x6f) = 0x40d80000 +25 close(3) = 0 +25 readlink("/proc/self/exe",0x00a8c450,4095) = 37 +25 readlink("/proc/self/exe",0x00a45060,4095) = 37 +25 chdir("/home/steam/steamcmd") = 0 +25 gettid() = 25 +25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=87889751}) +25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=89062235}) +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fea1c) = 0 ({tv_sec=1720063413,tv_nsec=948892664}) +25 openat(AT_FDCWD,"/home/steam/steamcmd/steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/Steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory) +25 readlink("/root",0x407fb530,1023) = -1 errno=22 (Invalid argument) +25 readlink("/root/.steam",0x407fb530,1023) = -1 errno=2 (No such file or directory) +25 stat64("/root/.steam/steam",0x407fb8f0) = -1 errno=2 (No such file or directory) +25 mkdir("/root/Steam/logs",0777) = -1 errno=17 (File exists) +25 stat64("/root/Steam/logs/bootstrap_log.txt",0x407fd8f0) = 0 +25 lstat64("/root/Steam/logs",0x407fd850) = 0 +25 openat(AT_FDCWD,"/root/Steam/logs/bootstrap_log.txt",O_RDWR|O_LARGEFILE) = 3 +25 flock(3,5,10725408,2,10725408,1082120376) = 0 +25 fcntl64(3,F_SETFD,1) = 0 +25 _llseek(3,0,0,0x407fd8a0,SEEK_END) = 0 +25 write(3,0x9022f3,4) = 4 +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=960892708}) +25 openat(AT_FDCWD,"/etc/localtime",O_RDONLY|O_CLOEXEC) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd65c) = 0 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd52c) = 0 +25 read(4,0xaa28b0,4096) = 114 +25 _llseek(4,4294967295,4294967236,0x407fd630,SEEK_CUR) = 0 +25 read(4,0xaa28b0,4096) = 60 +25 close(4) = 0 +25 write(3,0xa90d60,68) = 68 +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=976892768}) +25 write(3,0xa922e0,276) = 276 +25 getcwd(0xaa28b0,4096) = 21 +25 stat64("/home/steam/steamcmd/package/beta",0x407fb8e0) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/package/steam_cmd_linux.manifest",O_RDONLY|O_LARGEFILE) = 4 +25 flock(4,5,10725408,0,10725408,1082116024) = 0 +25 fcntl64(4,F_SETFD,1) = 0 +25 fstat64(4,0x407fc890) = 0 +25 read(4,0xab1e20,1838) = 1838 +25 close(4) = 0 +25 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40ffa000 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 munmap(0x40ffa000,266240) = 0 +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/crashhandler.so",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 +25 read(4,0x407fc180,512) = 512 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fbeb8) = 0 +25 mmap2(NULL,661476,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,4,0) = 0x40ffa000 +25 mmap2(0x41002000,442368,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x8) = 0x41002000 +25 mmap2(0x4106e000,147456,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x74) = 0x4106e000 +25 mmap2(0x41092000,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x97) = 0x41092000 +25 mmap2(0x41096000,22500,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x41096000 +25 close(4) = 0 +25 mprotect(0x41092000,12288,PROT_READ) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc2ec) = 0 ({tv_sec=1720063414,tv_nsec=1788981}) +25 clock_gettime64(CLOCK_BOOTTIME,0x407fc31c) = 0 ({tv_sec=4668200,tv_nsec=139217662}) +25 gettid() = 25 +25 futex(0x41099f4c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 futex(0x41099f54,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 clock_gettime64(CLOCK_BOOTTIME,0x407fc2ec) = 0 ({tv_sec=4668200,tv_nsec=147181452}) +25 getpid() = 25 +25 openat(AT_FDCWD,"/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq",O_RDONLY) = -1 errno=2 (No such file or directory) +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=15478752}) +25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21040173}) +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21460575}) +25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=26631394}) +25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fb8fc) = 0 +25 read(4,0xaa2ff0,1024) = 968 +25 read(4,0xaa2ff0,1024) = 0 +25 close(4) = 0 +25 gettid() = 25 +25 write(2,0x407fb120,57)Unable to determine CPU Frequency. Try defining CPU_MHZ. + = 57 +25 write(2,0x40b6fd47,1) + = 1 +25 statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fa8fc) = 0 +25 write(1,0xaa2ff0,57)Unable to determine CPU Frequency. Try defining CPU_MHZ. + = 57 +25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fc1cc) = 0 +25 read(4,0xaa3400,1024) = 968 +25 read(4,0xaa3400,1024) = 0 +25 close(4) = 0 +25 write(1,0xaa2ff0,52)Redirecting stderr to '/root/Steam/logs/stderr.txt' + = 52 +25 openat(AT_FDCWD,"/root/Steam/logs/stderr.txt",O_WRONLY|O_CREAT|O_LARGEFILE|O_TRUNC,0666) = 4 +25 dup3(4,2,0)Logging directory: '/root/Steam/logs' +``` diff --git a/results/classifier/gemma3:12b/files/2448 b/results/classifier/gemma3:12b/files/2448 new file mode 100644 index 00000000..6c4e67e7 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2493 b/results/classifier/gemma3:12b/files/2493 new file mode 100644 index 00000000..04a40d50 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2493 @@ -0,0 +1,2 @@ + +qemu-img delete snapshot by id diff --git a/results/classifier/gemma3:12b/files/250 b/results/classifier/gemma3:12b/files/250 new file mode 100644 index 00000000..567cff3e --- /dev/null +++ b/results/classifier/gemma3:12b/files/250 @@ -0,0 +1,2 @@ + +windows qemu-img fails to convert vhdx, assertion failure diff --git a/results/classifier/gemma3:12b/files/2504 b/results/classifier/gemma3:12b/files/2504 new file mode 100644 index 00000000..8b309742 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2504 @@ -0,0 +1,8 @@ + +linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine +Description of problem: +on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. +Steps to reproduce: +[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) +Additional information: + diff --git a/results/classifier/gemma3:12b/files/2506 b/results/classifier/gemma3:12b/files/2506 new file mode 100644 index 00000000..797592d0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2506 @@ -0,0 +1,59 @@ + +LC_RPATH stripped despite setting INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +Description of problem: +When I try to run qemu, I get the following output: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found +Steps to reproduce: +If the qemu-9.0.2 folder is present, remove it: +``` +$ rm -rf qemu-9.0.2 +``` +Create the source folder: +``` +$ tar xzf qemu-9.0.2.tar.xz +$ cd qemu-9.0.2 +``` + +Make sure the following environment variables are set: +``` +$ export CC=clang +$ export LDFLAGS="-rpath $HOME/local/lib" +$ export INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +``` + +Configure as follows: +``` +$ ./configure --prefix=$HOME/local --disable-sdl --enable-slirp --enable-fdt=internal --enable-spice +``` + +Build +``` +$ make -j 10 +``` + +Note there are a large number of linker warnings like this: +> ld: warning: duplicate -rpath '/Users/mj/local/lib' ignored + +Execute this: +``` +$ otool -l build/qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +See this output +> cmd LC_RPATH +> cmdsize 32 +> path /Users/mj/local/lib (offset 12) + +Change directory to $HOME/local/bin & execute: +``` +$ otool -l qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +The output is now empty - the LC_RPATH has been stripped by the install. This results in the failure to execute the resulting binary. Note, I tried using install_name_tool to add the RPATH, but it warned me this changed the signature of the file, and it would not run. + +Executing qemu-system-aarch64 produces the following: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found diff --git a/results/classifier/gemma3:12b/files/2510 b/results/classifier/gemma3:12b/files/2510 new file mode 100644 index 00000000..64ac6aab --- /dev/null +++ b/results/classifier/gemma3:12b/files/2510 @@ -0,0 +1,46 @@ + +Cross compiling tools / qemu-img results in "ninja: no work to do" +Description of problem: +I have the following Dockerfile setting up a cross-compile environment for QEMU. +I am trying to build qemu-img.exe only at the moment + + +``` +FROM fedora as builder +RUN --mount=type=cache,target=/var/cache \ + dnf -v install --assumeyes strace gcc make mingw64-gcc mingw64-binutils python-setuptools meson mingw64-glib2-static mingw64-glib2 diffutils + +FROM builder as qemu-builder +WORKDIR /src/qemu #assuming qemu source tree is already available at /src/qemu +RUN +RUN ./configure --cross-prefix=x86_64-w64-mingw32- --target-list='' --static +RUN make V=1 tools +``` +With either `make tools` or `make qemu-img.exe` I get + +``` +#10 0.265 changing dir to build for make "tools"... +#10 0.267 make[1]: Entering directory '/src/qemu/build' +#10 0.330 ninja: no work to do. +#10 0.331 { \ +#10 0.331 echo 'ninja-targets = \'; \ +#10 0.331 /usr/bin/ninja -t targets all | sed 's/:.*//; $!s/$/ \\/'; \ +#10 0.331 echo 'build-files = \'; \ +#10 0.331 /usr/bin/ninja -t query build.ninja | sed -n '1,/^ input:/d; /^ outputs:/q; s/$/ \\/p'; \ +#10 0.331 } > Makefile.ninja.tmp && mv Makefile.ninja.tmp Makefile.ninja +#10 0.363 /src/qemu/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /src/qemu/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest +#10 0.634 make[1]: Nothing to be done for 'tools'. +#10 0.634 make[1]: Leaving directory '/src/qemu/build' +#10 DONE 0.6s +``` + +Following the info in `make help`, I tried `make qemu-img.o` which resulted in + +``` +cc -c -o qemu-img.o qemu-img.c +qemu-img.c:25:10: fatal error: qemu/osdep.h: No such file or directory + 25 | #include "qemu/osdep.h" + | ^~~~~~~~~~~~~~ +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/files/2512 b/results/classifier/gemma3:12b/files/2512 new file mode 100644 index 00000000..bb2d65dd --- /dev/null +++ b/results/classifier/gemma3:12b/files/2512 @@ -0,0 +1,46 @@ + +macOS builds of target arm-softmmu broken +Description of problem: +Attempting to build for target `arm-softmmu` on macOS fails with errors: + +``` +[919/2786] Compiling C object libblock.a.p/block_file-posix.c.o +FAILED: libblock.a.p/block_file-posix.c.o +clang -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/nix/store/vb7baj6dq2mvynfh6zmwxz57w83h7w0q-zlib-1.3.1-dev/include -I/nix/store/k1yzx1ykpwmhqvyr0j5fxvs9px7k92m7-glib-2.80.4-dev/include/glib-2.0 -I/nix/store/fm2kb8jvvc9s9nhi2gpr3jp6xxjxcvkq-glib-2.80.4/lib/glib-2.0/include -I/nix/store/k1yzx1ykpwmhqvyr0j5fxvs9px7k92m7-glib-2.80.4-dev/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/josh/workspace/qemu -iquote /Users/josh/workspace/qemu/include -iquote /Users/josh/workspace/qemu/host/include/aarch64 -iquote /Users/josh/workspace/qemu/host/include/generic -iquote /Users/josh/workspace/qemu/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c +../block/file-posix.c:1501:19: error: variable has incomplete type 'struct statfs' + struct statfs buf; + ^ +../block/file-posix.c:1501:12: note: forward declaration of 'struct statfs' + struct statfs buf; + ^ +../block/file-posix.c:1503:10: error: call to undeclared function 'fstatfs'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] + if (!fstatfs(s->fd, &buf)) { + ^ +2 errors generated. +``` +Steps to reproduce: +1. nix-shell -p python3 ninja pkg-config glib +2. ./configure --target-list=arm-softmmu +3. make +Additional information: +The following patch fixes the issue (although I'm not sure whether this is the most appropriate fix): + +``` +diff --git a/block/file-posix.c b/block/file-posix.c +index ff928b5e85..6c78db3b0b 100644 +--- a/block/file-posix.c ++++ b/block/file-posix.c +@@ -44,10 +44,10 @@ + + #if defined(__APPLE__) && (__MACH__) + #include <sys/ioctl.h> +-#if defined(HAVE_HOST_BLOCK_DEVICE) +-#include <paths.h> + #include <sys/param.h> + #include <sys/mount.h> ++#if defined(HAVE_HOST_BLOCK_DEVICE) ++#include <paths.h> + #include <IOKit/IOKitLib.h> + #include <IOKit/IOBSD.h> + #include <IOKit/storage/IOMediaBSDClient.h> +``` diff --git a/results/classifier/gemma3:12b/files/2532 b/results/classifier/gemma3:12b/files/2532 new file mode 100644 index 00000000..c26bdc7f --- /dev/null +++ b/results/classifier/gemma3:12b/files/2532 @@ -0,0 +1,41 @@ + +empty vmdk disk created by qemu-img cann't import to vmware ESXi or Workstation +Description of problem: +qemu-img create empty vmdk file, and can't import to vmware workstation or ESXi. the ovftool + fail. the log: + +> ``` +> 2024-08-23T11:19:32.335+08:00 verbose OVFTool[4088548] [Originator@6876 sub=Default] Opening disk target empty-disk2.vmdk +> 2024-08-23T11:19:32.335+08:00 error OVFTool[4088548] [Originator@6876 sub=Default] Error on read, error: -1 +> 2024-08-23T11:19:32.336+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Exception thrown: N5boost16exception_detail10clone_implINS_17unknown_exceptionEEE(std::exception) +> 2024-08-23T11:19:32.337+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Backtrace: +> --> [backtrace begin] product: VMware Workstation, version: e.x.p, build: build-15722219, tag: OVFTool, cpu: x86_64, os: linux, buildType: release +> --> backtrace[00] libvmacore.so[0x003DD716] +> --> backtrace[01] libvmacore.so[0x001CF8DF]: Vmacore::System::Stacktrace::CaptureWork(unsigned int) +> --> backtrace[02] libvmacore.so[0x001B6EA9]: Vmacore::System::SystemFactory::CreateQuickBacktrace(Vmacore::Ref<Vmacore::System::Backtrace>&) +> --> backtrace[03] libvmacore.so[0x0016CF2E]: Vmacore::Throwable::Throwable(std::string&&) +> --> backtrace[04] ovftool.bin[0x001C1F38] +> --> backtrace[05] ovftool.bin[0x002008D5] +> --> backtrace[06] ovftool.bin[0x00129EF0] +> --> backtrace[07] libc.so.6[0x00044E50] +> --> backtrace[08] libc.so.6[0x00044EFC] +> --> backtrace[09] ovftool.bin[0x00132D21] +> --> [backtrace end] +> ``` + +the log file: +[test.log](/uploads/174db2ace468bd9f0ec3ab14de524217/test.log) +Steps to reproduce: +1. create empty vmdk file + +./qemu-img create -f vmdk -o adapter_type=lsilogic,subformat=streamOptimized empty.vmdk 1G + +2. add empty file info to ovf file +<File ovf:href="empty.vmdk" ovf:id="file2"/> + +3. import it to vmware workstation +Additional information: +If i write some data to empty vmdk file, it can import successfully. The reson: qemu only write metadata for empty vmdk file, but the ovftool need read more data and it cann't read more. +we can write one sector zero data after the metadata, ovftool work well. +I submitted the patch: +https://patchew.org/QEMU/20240822105237.777-1-luzhipeng@cestc.cn/ diff --git a/results/classifier/gemma3:12b/files/2541 b/results/classifier/gemma3:12b/files/2541 new file mode 100644 index 00000000..8c5c953f --- /dev/null +++ b/results/classifier/gemma3:12b/files/2541 @@ -0,0 +1,2 @@ + +virtio-9p qos-test failure: v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) FAIL diff --git a/results/classifier/gemma3:12b/files/257 b/results/classifier/gemma3:12b/files/257 new file mode 100644 index 00000000..51ee308e --- /dev/null +++ b/results/classifier/gemma3:12b/files/257 @@ -0,0 +1,2 @@ + +[Archlinux][git]With git revision e58c7a3b, packaging with meson install is broken. diff --git a/results/classifier/gemma3:12b/files/2584 b/results/classifier/gemma3:12b/files/2584 new file mode 100644 index 00000000..f650c1c2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2584 @@ -0,0 +1,17 @@ + +nbd URI wrong export name (regression in qemu 9.1) +Description of problem: +qemu with an nbd URI seems to pass the wrong export name to the server, if the exportname is `.`. This seems +to be a regression in qemu 9.1, because it didn't happen in 9.0. +Steps to reproduce: +``` +$ nbdkit -fv -U - null --run 'qemu-img info "nbd+unix:///.?socket=$unixsocket"' +... +nbdkit: null[1]: debug: null: open readonly=0 exportname="" tls=0 +``` + +In qemu 9.0 this was correct: + +``` +nbdkit: null[1]: debug: null: open readonly=0 exportname="." tls=0 +``` diff --git a/results/classifier/gemma3:12b/files/2628 b/results/classifier/gemma3:12b/files/2628 new file mode 100644 index 00000000..9e481fa6 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2628 @@ -0,0 +1,21 @@ + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines +Description of problem: +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version + +dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped +Steps to reproduce: +1. debootstrap --arch=arm64 stable /scratch/debian-stable +2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version +Additional information: +Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU + +chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/gemma3:12b/files/2629 b/results/classifier/gemma3:12b/files/2629 new file mode 100644 index 00000000..1467f66c --- /dev/null +++ b/results/classifier/gemma3:12b/files/2629 @@ -0,0 +1,2 @@ + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines diff --git a/results/classifier/gemma3:12b/files/263 b/results/classifier/gemma3:12b/files/263 new file mode 100644 index 00000000..ffb2f41e --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2638 b/results/classifier/gemma3:12b/files/2638 new file mode 100644 index 00000000..5a94e7f2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2638 @@ -0,0 +1,18 @@ + +Incorrect SPDX license expression +Description of problem: +In the source code, the syntax of license expressions after the keyword SPDX-License-Identifier is not always correct. + +"GPL-2.0" should be "GPL-2.0-only" + +"GPL-2.0 WITH Linux-syscall-note" should be "GPL-2.0-only WITH Linux-syscall-note" + +"GPL-2.0+" should be "GPL-2.0-or-later" + +"GPL-2.0+ WITH Linux-syscall-note" should be "GPL-2.0-or-later WITH Linux-syscall-note" + +"GPL-v2-only" should be "GPL-2.0-only" + +"LGPL-2.1+" should be "LGPL-2.1-or-later" + +"MIT CC0-1.0" should be "MIT" diff --git a/results/classifier/gemma3:12b/files/2649 b/results/classifier/gemma3:12b/files/2649 new file mode 100644 index 00000000..305f534c --- /dev/null +++ b/results/classifier/gemma3:12b/files/2649 @@ -0,0 +1,41 @@ + +Data corruption with qcow2 images +Steps to reproduce: +``` +# Create an example file with old version of qemu-img and fill it with random data. +$ qemu-img-8.2.2 create -f qcow2 file.qcow2 600000000000 +$ qemu-nbd-8.2.2 -c /dev/nbd0 file.qcow2 +$ dd if=/dev/random of=/dev/nbd0 bs=1000000 count=600000 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Get the correct checksum of both qcow2 file and its contents +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-8.2.2 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +5dac11e88f891740da3b655588b2e62037962d1ba6377efce30124d6224dd0d1 */dev/nbd0 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Use the qcow2 file with new version. +# We're using qemu-nbd here, but the same happens when qcow2 is attached to a guest +# running in the new version qemu-system-86_64-9.1.1 and can be seen through guest's +# /dev/vda. +# Note that the checksum is different than before, and also non-deterministic +# (running sha256sum twice produces different results even though the file is +# read-only and hasn't changed). +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-9.1.1 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +1793a38b9b964d3fc643629284722373e9d5dedea68e35900ace777b57688926 */dev/nbd0 +$ sha256sum -b /dev/nbd0 +98f900f9cd174493d0bfcf06e2bc86f5ee99dfa04c90d6832fa941e384b62d49 */dev/nbd0 +$ qemu-nbd-9.1.1 -d /dev/nbd0 +/dev/nbd0 disconnected +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +``` +Additional information: +No errors in either host or guest logs. When using a qcow2 with an actual filesystem, you may see reports of corruption from the filesystem driver. diff --git a/results/classifier/gemma3:12b/files/2689 b/results/classifier/gemma3:12b/files/2689 new file mode 100644 index 00000000..9d84d5f7 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2689 @@ -0,0 +1,2 @@ + +arm64be tuxrun test is sometimes failing with I/O errors diff --git a/results/classifier/gemma3:12b/files/2719 b/results/classifier/gemma3:12b/files/2719 new file mode 100644 index 00000000..af19eea1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2719 @@ -0,0 +1,2 @@ + +9.2.0 tarball contains unrelated files diff --git a/results/classifier/gemma3:12b/files/2726 b/results/classifier/gemma3:12b/files/2726 new file mode 100644 index 00000000..a0b7188b --- /dev/null +++ b/results/classifier/gemma3:12b/files/2726 @@ -0,0 +1,2 @@ + +please make qemu-img capable of using with pipes diff --git a/results/classifier/gemma3:12b/files/2743 b/results/classifier/gemma3:12b/files/2743 new file mode 100644 index 00000000..6dbf845f --- /dev/null +++ b/results/classifier/gemma3:12b/files/2743 @@ -0,0 +1,4 @@ + +The command Qemu-img did not work, cannot convert raw file to vhd file +Description of problem: + diff --git a/results/classifier/gemma3:12b/files/2754 b/results/classifier/gemma3:12b/files/2754 new file mode 100644 index 00000000..bbbc04fb --- /dev/null +++ b/results/classifier/gemma3:12b/files/2754 @@ -0,0 +1,27 @@ + +Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine +Description of problem: +Cannot complete the installation:'Enter the end of the file when reading data:I/O Error' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper + callback(asyncjob, *args, **kwargs) + ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 726, in start_install + domain = self._create_guest( + guest, meter, initial_xml, final_xml, + doboot, transient) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error' +Steps to reproduce: +1.Click to create loongarch64 virtual machine using virt-manager +2.Configure all arguments of virtual machine +3.Then click start installation,then the error occurs. +Additional information: + diff --git a/results/classifier/gemma3:12b/files/2766 b/results/classifier/gemma3:12b/files/2766 new file mode 100644 index 00000000..581a60dd --- /dev/null +++ b/results/classifier/gemma3:12b/files/2766 @@ -0,0 +1,24 @@ + +Qemu 9.2: stubs: build issue with --enable-user --disable-system --enable-tools +Description of problem: +Since commit "[stubs: avoid duplicate symbols in libqemuutil.a](https://gitlab.com/qemu-project/qemu/-/commit/388b849fb6c33882b481123568995a749a54f648)", Qemu doesn't build with: + + ./configure --enable-user --disable-system --enable-tools + + /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function 'device_finalize': \ + /home/autobuild/autobuild/instance-2/output-1/build/host-qemu-9.2.0/build/../hw/core/qdev.c:689:(.text+0x75c): undefined reference to 'qapi_event_send_device_deleted' + collect2: error: ld returned 1 exit status + +See Buildroot automated build results: +http://autobuild.buildroot.org/?reason=host-qemu-9.2.0 + +Indeed, with have_system = false and have_tools = true, Qemu needs the stubs for QAPI events added by stub_ss.add(files('qdev.c')) to provide qapi_event_send_device_deleted. + +Maybe the change in stubs/meson.build should have been: \ + +if not have_system and have_tools \ +stub_ss.add(files('qdev.c')) \ +endif + +Best regards, +Romain diff --git a/results/classifier/gemma3:12b/files/2772 b/results/classifier/gemma3:12b/files/2772 new file mode 100644 index 00000000..9689139b --- /dev/null +++ b/results/classifier/gemma3:12b/files/2772 @@ -0,0 +1,75 @@ + +qemu-img map command omits `offset` key in output for encrypted qcow2 files +Description of problem: +We use the `qemu-img map` command to retrieve metadata information from a qcow2 image. It functions as expected for non-encrypted qcow2 images. However, when the same command is executed on an encrypted qcow2 image, the output omits the `offset` key, which is critical for subsequent processing in our workflow. +Steps to reproduce: +1. Run qemu-img map on the encrypted incremental qcow2: +Command: + +``` + qemu-img map --object secret,id=sec0,data=trilio --output json -U --image-opts driver=qcow2,file.filename=incremental.qcow2,encrypt.format=luks,encrypt.key-secret=sec0 +``` +**Observed Output:** The command executes but does not include the offset key in the JSON output. +For example: +``` +[{ "start": 32191217664, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32191283200, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32193314816, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32193380352, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32195411968, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32195477504, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32197509120, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32197574656, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32199606272, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32199671808, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32201703424, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32201768960, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32203800576, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32203866112, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32205897728, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32205963264, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32207994880, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32208060416, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32210092032, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32210157568, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32212189184, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}] +``` + +2. Decrypt the same encrypted incremental qcow2 image and re-run the qemu-img map command: +**Decryption command:** +``` +qemu-img convert -t writeback --object secret,id=sec0,data=trilio -O qcow2 --image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=incremental.qcow2 decrypt.qcow2 +``` +3. Run qemu-img map on the decrypted image: +**Command:** +``` +qemu-img map --output json -U decrypt.qcow2 +``` +Here, we don't need to pass the encryption key as we have already decrypted the qcow2. + +**Observed Output:** The JSON output includes the offset key as expected. Example: +``` +[{ "start": 0, "length": 106954752, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 106954752, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 327680}, +{ "start": 109051904, "length": 786432000, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 895483904, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 2490368}, +{ "start": 897581056, "length": 1866924032, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 2764505088, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 4653056}, +{ "start": 2766143488, "length": 402587648, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 3168731136, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 6291456}, +{ "start": 3170893824, "length": 140443648, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 3311337472, "length": 54394880, "depth": 0, "present": true, "zero": false, "data": true, "offset": 8519680}, +{ "start": 3365732352, "length": 2056388608, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5422120960, "length": 1114112, "depth": 0, "present": true, "zero": false, "data": true, "offset": 62980096}, +{ "start": 5423235072, "length": 4128768, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5427363840, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 64094208}, +{ "start": 5429526528, "length": 469696512, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5899223040, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 66256896}, +{ "start": 5901385728, "length": 90112000, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5991497728, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 68485120}, +{ "start": 5993136128, "length": 2086600704, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 8079736832, "length": 2686976, "depth": 0, "present": true, "zero": false, "data": true, "offset": 70189056}, +{ "start": 8082423808, "length": 24129830912, "depth": 0, "present": false, "zero": true, "data": false}] +``` + +The missing `offset` key in the output of the `qemu-img map` command for encrypted qcow2 images disrupts downstream processes that rely on this metadata. diff --git a/results/classifier/gemma3:12b/files/2785 b/results/classifier/gemma3:12b/files/2785 new file mode 100644 index 00000000..3f0c3c8c --- /dev/null +++ b/results/classifier/gemma3:12b/files/2785 @@ -0,0 +1,17 @@ + +Cannot build qemu after the latest addition of NBD docs +Description of problem: +``` +[5584/5962] Generating docs/QEMU manual with a custom command +FAILED: docs/docs.stamp +"C:\msys64\usr\bin/env.EXE" "CONFDIR=etc/" "C:/msys64/home/user/qemu/build/pyvenv/bin/sphinx-build.exe" "-q" "-W" "-Dkerneldoc_werror=1" "-j" "auto" "-Dversion=9.2.50" "-Drelease=" "-Ddepfile=docs/docs.d" "-Ddepfile_stamp=docs/docs.stamp" "-b" "html" "-d" "C:/msys64/home/user/qemu/build/docs/manual.p" "C:/msys64/home/user/qemu/docs" "C:/msys64/home/user/qemu/build/docs/manual" +C:/msys64/home/user/qemu/docs/system/qemu-block-drivers.rst.inc:506: WARNING: duplicate label nbd, other instance in C:/msys64/home/user/qemu/docs/system/images.rst +[5593/5962] Compiling C object tests/qtest/ide-test.exe.p/ide-test.c.obj +ninja: build stopped: subcommand failed. +``` +Steps to reproduce: +1.meson compile +2. +3. +Additional information: +excluding NBD from the build targets allows successful compilation diff --git a/results/classifier/gemma3:12b/files/2786 b/results/classifier/gemma3:12b/files/2786 new file mode 100644 index 00000000..dc71f744 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2786 @@ -0,0 +1,12 @@ + +deleting files fails on vvfat (was: "error handling renames") +Description of problem: +When working with files, renaming or saving from IDE, QEMU halts with the error message: + +"Error handling renames (-2)" +Steps to reproduce: +1. +2. +3. +Additional information: +a previous del failed, the directories are not synced so the rename on the drive fails when the file with the target file name still exists on the real directory. So the real issue is a failed del. diff --git a/results/classifier/gemma3:12b/files/2789 b/results/classifier/gemma3:12b/files/2789 new file mode 100644 index 00000000..9dfbd4d6 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2789 @@ -0,0 +1,2 @@ + +Emulate a folder instead of creating the iso diff --git a/results/classifier/gemma3:12b/files/2811 b/results/classifier/gemma3:12b/files/2811 new file mode 100644 index 00000000..aeb23012 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2816 b/results/classifier/gemma3:12b/files/2816 new file mode 100644 index 00000000..c1a19321 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2816 @@ -0,0 +1,15 @@ + +qemu-9.2.1 windows can not load files if kernel is linux-6.13.x +Description of problem: +qemu-9.2 and 9.2.1 emulating windows-10 both gave this +bug "externe exception 80000004." emulating windows-10 +when a program tries to load a file. +qemu emulating windows-10 runs without this bug when using +kernel linux-6.12.14 and older. +Steps to reproduce: +1.start a prog, in my case sprint-layout-6.0, try to open/load a file. +2. +3. +Additional information: +Im not shure if the bug is with qemu or kernel. +You can decide better what causes this bug. diff --git a/results/classifier/gemma3:12b/files/2825 b/results/classifier/gemma3:12b/files/2825 new file mode 100644 index 00000000..6136f472 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2825 @@ -0,0 +1,38 @@ + +execveat with file descriptor and empty filename returns ENOENT when cross architectures +Description of problem: +On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors. + +I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error). +Steps to reproduce: +1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. +2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64` +3. Run different versions of test +4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64` +5. Sample outputs + +``` +rrex@debian:~/Downloads$ ./test +****Running to prepare execve +fd=3 +File size: 772296 bytes + +execveat with AT_EMPTY_PATH: +**Running in execve + +execveat with fd path: /proc/self/fd/3 +**Running in execve + +rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 +****Running to prepare execve +fd=3 +File size: 706104 bytes + +execveat with AT_EMPTY_PATH: +!!execveat a fd failed with errno: No such file or directory + +execveat with fd path: /proc/self/fd/3 +**Running in execve +``` +Additional information: +# diff --git a/results/classifier/gemma3:12b/files/283 b/results/classifier/gemma3:12b/files/283 new file mode 100644 index 00000000..3f7ed69c --- /dev/null +++ b/results/classifier/gemma3:12b/files/283 @@ -0,0 +1,2 @@ + +TCG memory leak with FreeDOS 'edit' diff --git a/results/classifier/gemma3:12b/files/2837 b/results/classifier/gemma3:12b/files/2837 new file mode 100644 index 00000000..54cf3399 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2837 @@ -0,0 +1,2 @@ + +qcow2 corruption MinGW64 diff --git a/results/classifier/gemma3:12b/files/2838 b/results/classifier/gemma3:12b/files/2838 new file mode 100644 index 00000000..5f5ed41c --- /dev/null +++ b/results/classifier/gemma3:12b/files/2838 @@ -0,0 +1,9 @@ + +searchindex.js in HTML doc is not reproducible +Description of problem: +Builds should be reproducible, at least when `SOURCE_DATE_EPOCH` set to some value (see: <https://reproducible-builds.org/docs/source-date-epoch/>), but the QEMU HTML doc contains a file which isn't reproducible. +Steps to reproduce: +1. `guix build --no-grafts qemu && guix build --no-grafts --check --keep-failed qemu` +2. `diffoscope /gnu/store/3kym1ykv9r8n0hgbihqllch9ph136zx1-qemu-8.2.2-doc{,-check}` +Additional information: +[diffoscope-log.txt](/uploads/ab19f184082f343635df4fa7ef26b12e/diffoscope-log.txt) diff --git a/results/classifier/gemma3:12b/files/2851 b/results/classifier/gemma3:12b/files/2851 new file mode 100644 index 00000000..dd949855 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2851 @@ -0,0 +1,52 @@ + +Assert failure in ../util/error.c:68: void error_setv() +Description of problem: +If bdrv_snapshot_goto() returns an error, it is not handled immediately, +allowing *errp to be reassigned when qcow_open() fails, which triggers +assert(*errp == NULL) in util/error.c: void error_setv(). +Steps to reproduce: +1. [test.qed](/uploads/17005dfba241f5a355e3592e12e356f6/test.qed) +2. ./qemu-img snapshot -q -a test test.qed +Additional information: +<details> +<pre> +qemu-img-fuzz: ../util/error.c:68: void error_setv(Error **, const char *, int, const char *, ErrorClass, const char *, struct __va_list_tag *, const char *): Assertion `*errp == NULL' failed. +==20841== ERROR: libFuzzer: deadly signal + #0 0x56384b84a46a in __sanitizer_print_stack_trace /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x56384b79bb79 in fuzzer::PrintStackTrace() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x56384b77d5a6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x56384b77d667 in fuzzer::Fuzzer::CrashCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x56384b77d667 in fuzzer::Fuzzer::StaticCrashSignalCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7effd07c09df (/lib64/libpthread.so.0+0x139df) + #6 0x7effcf659450 in raise (/lib64/libc.so.6+0x3d450) + #7 0x7effcf642547 in abort (/lib64/libc.so.6+0x26547) + #8 0x7effcf642430 (/lib64/libc.so.6+0x26430) + #9 0x7effcf651ce1 in __assert_fail (/lib64/libc.so.6+0x35ce1) + #10 0x56384bf211dc in error_setv /home/gerben/qemu-img_fuzz/build/../util/error.c:68:5 + #11 0x56384bf213fc in error_setg_internal /home/gerben/qemu-img_fuzz/build/../util/error.c:105:5 + #12 0x56384bb2b71f in qcow_open /home/gerben/qemu-img_fuzz/build/../block/qcow.c:306:5 + #13 0x56384bb17654 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20 + #14 0x56384bdd52c1 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:3476:15 + #15 0x56384bdbcede in qemu_img_main /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:5624:20 + #16 0x56384bdb6e7d in command_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:309:20 + #17 0x56384bdb6e7d in generator_command /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1285:17 + #18 0x56384bdaf718 in LLVMFuzzerTestOneInput /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1303:5 + #19 0x56384b77e1c8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:559:17 + #20 0x56384b781af0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:471:18 + #21 0x56384b784796 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:771:13 + #22 0x56384b784c7e in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:800:28 + #23 0x56384b76bb57 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:847:10 + #24 0x56384b758fe2 in main /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #25 0x7effcf643efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #26 0x56384b759089 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x2b,0x25,0xff,0xff,0xff,0xff,0x3a,0x9a,0xc9,0xff,0xa, ++%\xff\xff\xff\xff:\x9a\xc9\xff\x0a +artifact_prefix='./'; Test unit written to ./crash-e9c4f1b8a97ffa93544e87a5a819ac524aa82029 +Base64: KyX/////OprJ/wo= +</pre> +</details> diff --git a/results/classifier/gemma3:12b/files/2853 b/results/classifier/gemma3:12b/files/2853 new file mode 100644 index 00000000..b3ef55b2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2853 @@ -0,0 +1,55 @@ + +double-free in vmdk_add_extent() +Description of problem: +A double-free issue in the VMDK driver occurs when handling snapshots. +The memory allocated for extent structures is freed twice: first in +vmdk_close (block/vmdk.c) and then in vmdk_add_extent (block/vmdk.c). +Steps to reproduce: +1. [test.raw](/uploads/deeb9dc3cab1916adadd211173cd175a/test.raw) +2. ./qemu-img snapshot -q -a test test.raw +Additional information: +<details> +<pre> +./qemu-img snapshot -q -a test test.raw +==18180==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==18180==ERROR: AddressSanitizer: attempting double-free on 0x612000011bc0 in thread T0: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba866a79 in vmdk_add_extent /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:570:18 + #3 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #4 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #5 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #6 0x5605ba803ca4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20 + #7 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #8 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #9 0x5605ba4619f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +0x612000011bc0 is located 0 bytes inside of 272-byte region [0x612000011bc0,0x612000011cd0) +freed by thread T0 here: + #0 0x5605ba504aef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 + #1 0x5605ba857e6d in vmdk_close /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:2889:5 + #2 0x5605ba803bb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13 + #3 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #4 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +previously allocated by thread T0 here: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #3 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #4 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #5 0x5605ba56e3a2 in bdrv_open_driver /home/gerben/qemu-img_fuzz/build/../block.c:1660:15 + #6 0x5605ba57ea50 in bdrv_open_common /home/gerben/qemu-img_fuzz/build/../block.c:1985:11 + #7 0x5605ba57ea50 in bdrv_open_inherit /home/gerben/qemu-img_fuzz/build/../block.c:4153:11 + #8 0x5605ba585cb8 in bdrv_open /home/gerben/qemu-img_fuzz/build/../block.c:4248:12 + #9 0x5605ba637d4c in blk_new_open /home/gerben/qemu-img_fuzz/build/../block/block-backend.c:457:10 + #10 0x5605baa9193b in img_open_file /home/gerben/qemu-img_fuzz/build/../qemu-img.c:405:11 + #11 0x5605baa9143e in img_open /home/gerben/qemu-img_fuzz/build/../qemu-img.c:450:15 + #12 0x5605baa8cc71 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3468:11 + #13 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +SUMMARY: AddressSanitizer: double-free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 in realloc +==18180==ABORTING +</pre> +</details> diff --git a/results/classifier/gemma3:12b/files/2867 b/results/classifier/gemma3:12b/files/2867 new file mode 100644 index 00000000..ae06cb5b --- /dev/null +++ b/results/classifier/gemma3:12b/files/2867 @@ -0,0 +1,14 @@ + +qemu:block / io-qcow2-161 fails non-deterministically +Description of problem: +The test suite failed non-deterministically with failure: +``` +729/838 qemu:block / io-qcow2-161 ERROR 2.08s exit status 1 +``` +Steps to reproduce: +1. guix time-machine --commit=d706c1b -- build qemu +2. or git clone, build and run `make check -j32 V=1` +Additional information: +[qemu-9.1.3-io-qcow2-041-failure-build-log.txt](/uploads/077f61d9dd1a26bcd351c0995009131c/qemu-9.1.3-io-qcow2-041-failure-build-log.txt) + +[testlog.txt](/uploads/0b0244a337f2175bdba9e258c778481d/testlog.txt) diff --git a/results/classifier/gemma3:12b/files/2900 b/results/classifier/gemma3:12b/files/2900 new file mode 100644 index 00000000..e90d59c3 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2900 @@ -0,0 +1,12 @@ + +Data races in test-bdrv-drain test +Description of problem: +Data races in the access of `Job` fields in the `test-bdrv-drain` test were identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-bdrv-drain +MALLOC_PERTURB_=186 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-bdrv-drain --tap -k +``` diff --git a/results/classifier/gemma3:12b/files/2909 b/results/classifier/gemma3:12b/files/2909 new file mode 100644 index 00000000..c16186df --- /dev/null +++ b/results/classifier/gemma3:12b/files/2909 @@ -0,0 +1,19 @@ + +Corrupt qcow2 images with broken bitmap unfixable +Description of problem: +During a backup of a VM (via bitmaps), the disk of the VM/Snapshot went out of space. +The VM was stopped, leaving the image in a bad state. + +But now when trying to repair it, it was stuck: +``` +# qemu-img check -r all /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9 +qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': Bitmap '' doesn't satisfy the constraints +``` + +But if you want to remove the bitmap: +``` +# qemu-img bitmap --remove /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9 '' +qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': qcow2: Image is corrupt; cannot be opened read/write +``` + +It seems like qemu-img check needs some option to clear invalid bitmaps. So the image can be repaired including dropping the invalid bitmap. diff --git a/results/classifier/gemma3:12b/files/2912 b/results/classifier/gemma3:12b/files/2912 new file mode 100644 index 00000000..ce06f921 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/2958 b/results/classifier/gemma3:12b/files/2958 new file mode 100644 index 00000000..b693a108 --- /dev/null +++ b/results/classifier/gemma3:12b/files/2958 @@ -0,0 +1,19 @@ + +Vvfat crashes in WinXP-64 installation. +Description of problem: + +Steps to reproduce: +1. Download ISO (see above) +2. Set up qemu +3. Run command above + +Termux output: +qemu-system-x86_64: Slirp: Failed to send packet, ret: -1 [repeated] + +../block/vvfat.c:105: void *array_get(array_t *, unsigned int): assertion "index < array->next" failed +Aborted +~ $ +Additional information: +This was extremely annoying because the total abort occurs far into the installation, while setting up the network. The devices (presumably including the vvfat) had been installed OK. The XP installation can be restarted without the CD but starts at the beginning, needing location, passwords, licence key etc. all over again! I have XP64 installed now, without vvfat which is a marvellously convenient way of transferring files. + +BTW "vfat" usually means extended FAT, handling files over 4GB but vvfat does not. Can you fix that? diff --git a/results/classifier/gemma3:12b/files/297 b/results/classifier/gemma3:12b/files/297 new file mode 100644 index 00000000..5db334c1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/297 @@ -0,0 +1,2 @@ + +SD card size constraint conceptually wrong diff --git a/results/classifier/gemma3:12b/files/304636 b/results/classifier/gemma3:12b/files/304636 new file mode 100644 index 00000000..2c667487 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/307 b/results/classifier/gemma3:12b/files/307 new file mode 100644 index 00000000..f579fdc4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/307 @@ -0,0 +1,2 @@ + +qemu may freeze during drive-mirroring on fragmented FS diff --git a/results/classifier/gemma3:12b/files/310 b/results/classifier/gemma3:12b/files/310 new file mode 100644 index 00000000..eda290ba --- /dev/null +++ b/results/classifier/gemma3:12b/files/310 @@ -0,0 +1,2 @@ + +unable to migrate non shared storage when TLS is used diff --git a/results/classifier/gemma3:12b/files/322602 b/results/classifier/gemma3:12b/files/322602 new file mode 100644 index 00000000..bc21babb --- /dev/null +++ b/results/classifier/gemma3:12b/files/322602 @@ -0,0 +1,16 @@ + +Snapshot usage makes qcow2 image unusable due to large tables + +To reproduce with 0.9.1 and svn: +- Create a 20G (or some size much greater than system RAM) qcow2 image +- Inside VM, install some OS, formatting whole drive +- Create snapshot with savevm +- Inside VM, reformat and reinstall OS +- Create snapshot with savevm +[...] + +Eventually, qemu crashes, then neither qemu-img nor qemu can open the image because memory is exhausted. The reason is that the whole refcount_table is loaded into memory, and this refcount_table has now become much bigger than the size of memory. + +The refcount_table really needs to be loaded and used in fixed size chunks to avoid this problem. + +Alternatively, there needs to be a way to "rollback" a snapshot without loading the whole disk image normally, so that a snapshot which has made the image unusable in this way can be reversed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/349 b/results/classifier/gemma3:12b/files/349 new file mode 100644 index 00000000..c4fd6378 --- /dev/null +++ b/results/classifier/gemma3:12b/files/349 @@ -0,0 +1,2 @@ + +USB folder sharing causing segment fault diff --git a/results/classifier/gemma3:12b/files/359 b/results/classifier/gemma3:12b/files/359 new file mode 100644 index 00000000..78e08539 --- /dev/null +++ b/results/classifier/gemma3:12b/files/359 @@ -0,0 +1,2 @@ + +In the "tests/qtests/meson.build" line 92 need dbus-vmstate1.h and dbus-vmstate1.c files, but in "tests/qtests/" not include this files. diff --git a/results/classifier/gemma3:12b/files/365 b/results/classifier/gemma3:12b/files/365 new file mode 100644 index 00000000..8fd3422d --- /dev/null +++ b/results/classifier/gemma3:12b/files/365 @@ -0,0 +1,2 @@ + +virtiofsd: Directory for PID file hardcoded diff --git a/results/classifier/gemma3:12b/files/398 b/results/classifier/gemma3:12b/files/398 new file mode 100644 index 00000000..c6d7e198 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/399 b/results/classifier/gemma3:12b/files/399 new file mode 100644 index 00000000..6556b74e --- /dev/null +++ b/results/classifier/gemma3:12b/files/399 @@ -0,0 +1,2 @@ + +drive-backup job hangs in a 'paused' state after unsuccessful first attempt diff --git a/results/classifier/gemma3:12b/files/409 b/results/classifier/gemma3:12b/files/409 new file mode 100644 index 00000000..96eb4e3c --- /dev/null +++ b/results/classifier/gemma3:12b/files/409 @@ -0,0 +1,2 @@ + +tar can only read 4096 bytes from some files on 9p diff --git a/results/classifier/gemma3:12b/files/418 b/results/classifier/gemma3:12b/files/418 new file mode 100644 index 00000000..1267866d --- /dev/null +++ b/results/classifier/gemma3:12b/files/418 @@ -0,0 +1,2 @@ + +qemu-img commit on Windows 10 fails diff --git a/results/classifier/gemma3:12b/files/432 b/results/classifier/gemma3:12b/files/432 new file mode 100644 index 00000000..8ba60a76 --- /dev/null +++ b/results/classifier/gemma3:12b/files/432 @@ -0,0 +1,2 @@ + +QAPI: Avoid generating empty source files diff --git a/results/classifier/gemma3:12b/files/441 b/results/classifier/gemma3:12b/files/441 new file mode 100644 index 00000000..d8486856 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/473 b/results/classifier/gemma3:12b/files/473 new file mode 100644 index 00000000..5a592e61 --- /dev/null +++ b/results/classifier/gemma3:12b/files/473 @@ -0,0 +1,2 @@ + +QEMU 6.0.0 - NSIS installer script issues diff --git a/results/classifier/gemma3:12b/files/483 b/results/classifier/gemma3:12b/files/483 new file mode 100644 index 00000000..75b53057 --- /dev/null +++ b/results/classifier/gemma3:12b/files/483 @@ -0,0 +1,26 @@ + +qemu doesn't process -object secret when read from a config file +Description of problem: +Qemu doesn't process -object secret lines when read from a config file. This results in the new spice password-secret option failing with error: No secret with id '\<theid\>' +Steps to reproduce: +1. Create a password file +``` +printf "password" > passfile.pw +``` +2. Start qemu with command line options and also write to a config file +``` +qemu-system-x86_64 \ + -object secret,id=spicepwd,format=raw,file=passfile.pw \ + -spice port=5901,password-secret=spicepwd \ + -writeconfig qemu.cfg +``` +3. Optional: Connect using spice client and password: "password" +4. Exit qemu and cat qemu.cfg and verify it looks okay with equivalent options to what was specified on the command line +5. Now attempt to start qemu and read the options using the config file +``` +qemu-system-x86_64 -readconfig qemu.cfg +``` +6. This fails with an error: +``` +qemu-system-x86_64: No secret with id 'spicepwd' +``` diff --git a/results/classifier/gemma3:12b/files/490 b/results/classifier/gemma3:12b/files/490 new file mode 100644 index 00000000..775f10ff --- /dev/null +++ b/results/classifier/gemma3:12b/files/490 @@ -0,0 +1,830 @@ + +Compilation FAILED: libblock.fa.p/block_vpc.c.o +Description of problem: +Compilation failed +Steps to reproduce: +``` +git checkout v5.2.0 +./configure --target-list=riscv64-softmmu +make +``` +Additional information: +``` +changing dir to build for make ""... +make[1]: Entering directory '/home/peterlin/Labs/riscv64-linux/qemu/build' +/usr/bin/ninja build.ninja && touch build.ninja.stamp +ninja: no work to do. +/usr/bin/meson introspect --targets --tests --benchmarks | /usr/bin/python3 -B scripts/mtest2make.py > Makefile.mtest + AS multiboot.o + AS linuxboot.o + CC linuxboot_dma.o + AS pvh.o + AS kvmvapic.o + BUILD linuxboot.img + BUILD kvmvapic.img + CC pvh_main.o + BUILD multiboot.img + BUILD linuxboot_dma.img +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: kvmvapic.img] Error 1 +make[2]: *** Waiting for unfinished jobs.... +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: linuxboot.img] Error 1 +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) +make[2]: *** [Makefile:57: multiboot.img] Error 1 +make[2]: *** [Makefile:57: linuxboot_dma.img] Error 1 +make[1]: *** [Makefile:206: pc-bios/optionrom/all] Error 2 +make[1]: *** Waiting for unfinished jobs.... +[1/2124] Compiling C object libcapstone.a.p/capstone_MCInstrDesc.c.o +[2/2124] Compiling C object libcapstone.a.p/capstone_MCRegisterInfo.c.o +[3/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Module.c.o +[4/2124] Compiling C object libcapstone.a.p/capstone_SStream.c.o +[5/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86InstPrinterCommon.c.o +[6/2124] Compiling C object libcapstone.a.p/capstone_utils.c.o +[7/2124] Compiling C object libcapstone.a.p/capstone_MCInst.c.o +[8/2124] Compiling C object libcapstone.a.p/capstone_cs.c.o +[9/2124] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[10/2124] Generating hmp-commands.h with a custom command (wrapped by meson to capture output) +[11/2124] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output) +[12/2124] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output) +[13/2124] Generating qemu-options.def with a custom command (wrapped by meson to capture output) +[14/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user-glib.c.o +[15/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Disassembler.c.o +[16/2124] Generating trace-hw_audio.h with a custom command (wrapped by meson to capture output) +[17/2124] Generating trace-hw_9pfs.h with a custom command (wrapped by meson to capture output) +[18/2124] Generating trace-hw_audio.c with a custom command (wrapped by meson to capture output) +[19/2124] Generating trace-hw_block_dataplane.h with a custom command (wrapped by meson to capture output) +[20/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86ATTInstPrinter.c.o +[21/2124] Generating trace-hw_block.c with a custom command (wrapped by meson to capture output) +[22/2124] Generating trace-hw_block.h with a custom command (wrapped by meson to capture output) +[23/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86IntelInstPrinter.c.o +[24/2124] Generating trace-hw_arm.h with a custom command (wrapped by meson to capture output) +[25/2124] Generating trace-hw_alpha.c with a custom command (wrapped by meson to capture output) +[26/2124] Generating trace-hw_arm.c with a custom command (wrapped by meson to capture output) +[27/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +[28/2124] Linking static target contrib/libvhost-user/libvhost-user.a +[29/2124] Generating trace-hw_char.c with a custom command (wrapped by meson to capture output) +[30/2124] Generating trace-hw_9pfs.c with a custom command (wrapped by meson to capture output) +[31/2124] Generating trace-hw_block_dataplane.c with a custom command (wrapped by meson to capture output) +[32/2124] Generating trace-hw_char.h with a custom command (wrapped by meson to capture output) +[33/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Mapping.c.o +[34/2124] Generating trace-hw_alpha.h with a custom command (wrapped by meson to capture output) +[35/2124] Generating trace-hw_acpi.c with a custom command (wrapped by meson to capture output) +[36/2124] Generating trace-hw_acpi.h with a custom command (wrapped by meson to capture output) +[37/2124] Generating trace-accel_kvm.h with a custom command (wrapped by meson to capture output) +[38/2124] Generating trace-root.c with a custom command (wrapped by meson to capture output) +[39/2124] Generating trace-accel_tcg.h with a custom command (wrapped by meson to capture output) +[40/2124] Generating trace-accel_kvm.c with a custom command (wrapped by meson to capture output) +[41/2124] Generating trace-crypto.h with a custom command (wrapped by meson to capture output) +[42/2124] Generating trace-accel_tcg.c with a custom command (wrapped by meson to capture output) +[43/2124] Generating trace-crypto.c with a custom command (wrapped by meson to capture output) +[44/2124] Generating trace-authz.c with a custom command (wrapped by meson to capture output) +[45/2124] Generating trace-authz.h with a custom command (wrapped by meson to capture output) +[46/2124] Generating trace-monitor.h with a custom command (wrapped by meson to capture output) +[47/2124] Generating trace-monitor.c with a custom command (wrapped by meson to capture output) +[48/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86DisassemblerDecoder.c.o +[49/2124] Linking static target libcapstone.a +[50/2124] Generating trace-root.h with a custom command (wrapped by meson to capture output) +[51/2124] Generating trace-block.h with a custom command (wrapped by meson to capture output) +[52/2124] Generating trace-hw_watchdog.h with a custom command (wrapped by meson to capture output) +[53/2124] Generating trace-hw_virtio.c with a custom command (wrapped by meson to capture output) +[54/2124] Generating trace-hw_watchdog.c with a custom command (wrapped by meson to capture output) +[55/2124] Generating trace-block.c with a custom command (wrapped by meson to capture output) +[56/2124] Generating trace-io.c with a custom command (wrapped by meson to capture output) +[57/2124] Generating trace-nbd.h with a custom command (wrapped by meson to capture output) +[58/2124] Generating trace-nbd.c with a custom command (wrapped by meson to capture output) +[59/2124] Generating trace-io.h with a custom command (wrapped by meson to capture output) +[60/2124] Generating trace-scsi.h with a custom command (wrapped by meson to capture output) +[61/2124] Generating trace-scsi.c with a custom command (wrapped by meson to capture output) +[62/2124] Generating trace-audio.h with a custom command (wrapped by meson to capture output) +[63/2124] Generating trace-backends.h with a custom command (wrapped by meson to capture output) +[64/2124] Generating trace-backends.c with a custom command (wrapped by meson to capture output) +[65/2124] Generating trace-audio.c with a custom command (wrapped by meson to capture output) +[66/2124] Generating trace-backends_tpm.h with a custom command (wrapped by meson to capture output) +[67/2124] Generating trace-backends_tpm.c with a custom command (wrapped by meson to capture output) +[68/2124] Generating shared QAPI source files with a custom command +[69/2124] Generating trace-chardev.h with a custom command (wrapped by meson to capture output) +[70/2124] Generating trace-chardev.c with a custom command (wrapped by meson to capture output) +[71/2124] Generating trace-hw_display.h with a custom command (wrapped by meson to capture output) +[72/2124] Generating trace-hw_display.c with a custom command (wrapped by meson to capture output) +[73/2124] Generating trace-hw_dma.h with a custom command (wrapped by meson to capture output) +[74/2124] Generating trace-hw_dma.c with a custom command (wrapped by meson to capture output) +[75/2124] Generating trace-hw_hppa.h with a custom command (wrapped by meson to capture output) +[76/2124] Generating trace-hw_hppa.c with a custom command (wrapped by meson to capture output) +[77/2124] Generating trace-hw_hyperv.h with a custom command (wrapped by meson to capture output) +[78/2124] Generating trace-hw_hyperv.c with a custom command (wrapped by meson to capture output) +[79/2124] Generating trace-hw_i2c.h with a custom command (wrapped by meson to capture output) +[80/2124] Generating trace-hw_i386_xen.c with a custom command (wrapped by meson to capture output) +[81/2124] Generating trace-hw_i386.h with a custom command (wrapped by meson to capture output) +[82/2124] Generating trace-hw_i386.c with a custom command (wrapped by meson to capture output) +[83/2124] Generating trace-hw_i2c.c with a custom command (wrapped by meson to capture output) +[84/2124] Generating trace-hw_i386_xen.h with a custom command (wrapped by meson to capture output) +[85/2124] Generating trace-hw_ide.c with a custom command (wrapped by meson to capture output) +[86/2124] Generating trace-hw_ide.h with a custom command (wrapped by meson to capture output) +[87/2124] Generating trace-hw_input.h with a custom command (wrapped by meson to capture output) +[88/2124] Generating trace-hw_input.c with a custom command (wrapped by meson to capture output) +[89/2124] Generating trace-hw_isa.h with a custom command (wrapped by meson to capture output) +[90/2124] Generating trace-hw_intc.h with a custom command (wrapped by meson to capture output) +[91/2124] Generating trace-hw_intc.c with a custom command (wrapped by meson to capture output) +[92/2124] Generating trace-hw_mem.h with a custom command (wrapped by meson to capture output) +[93/2124] Generating trace-hw_mem.c with a custom command (wrapped by meson to capture output) +[94/2124] Generating trace-hw_isa.c with a custom command (wrapped by meson to capture output) +[95/2124] Generating trace-hw_misc.h with a custom command (wrapped by meson to capture output) +[96/2124] Generating trace-hw_mips.h with a custom command (wrapped by meson to capture output) +[97/2124] Generating trace-hw_mips.c with a custom command (wrapped by meson to capture output) +[98/2124] Generating trace-hw_misc.c with a custom command (wrapped by meson to capture output) +[99/2124] Generating trace-hw_misc_macio.c with a custom command (wrapped by meson to capture output) +[100/2124] Generating trace-hw_misc_macio.h with a custom command (wrapped by meson to capture output) +[101/2124] Generating trace-hw_net.h with a custom command (wrapped by meson to capture output) +[102/2124] Generating trace-hw_nvram.h with a custom command (wrapped by meson to capture output) +[103/2124] Generating trace-hw_net.c with a custom command (wrapped by meson to capture output) +[104/2124] Generating trace-hw_pci.h with a custom command (wrapped by meson to capture output) +[105/2124] Generating trace-hw_nvram.c with a custom command (wrapped by meson to capture output) +[106/2124] Generating trace-hw_pci_host.h with a custom command (wrapped by meson to capture output) +[107/2124] Generating trace-hw_pci.c with a custom command (wrapped by meson to capture output) +[108/2124] Generating trace-hw_pci_host.c with a custom command (wrapped by meson to capture output) +[109/2124] Generating trace-hw_ppc.h with a custom command (wrapped by meson to capture output) +[110/2124] Generating trace-hw_ppc.c with a custom command (wrapped by meson to capture output) +[111/2124] Generating trace-hw_rdma.c with a custom command (wrapped by meson to capture output) +[112/2124] Generating trace-hw_rdma_vmw.c with a custom command (wrapped by meson to capture output) +[113/2124] Generating trace-hw_rdma_vmw.h with a custom command (wrapped by meson to capture output) +[114/2124] Generating trace-hw_rdma.h with a custom command (wrapped by meson to capture output) +[115/2124] Generating trace-hw_rtc.h with a custom command (wrapped by meson to capture output) +[116/2124] Generating trace-hw_rtc.c with a custom command (wrapped by meson to capture output) +[117/2124] Generating trace-hw_s390x.c with a custom command (wrapped by meson to capture output) +[118/2124] Generating trace-hw_s390x.h with a custom command (wrapped by meson to capture output) +[119/2124] Generating trace-hw_scsi.c with a custom command (wrapped by meson to capture output) +[120/2124] Generating trace-hw_scsi.h with a custom command (wrapped by meson to capture output) +[121/2124] Generating trace-hw_sd.h with a custom command (wrapped by meson to capture output) +[122/2124] Generating trace-hw_sd.c with a custom command (wrapped by meson to capture output) +[123/2124] Generating trace-hw_sparc.h with a custom command (wrapped by meson to capture output) +[124/2124] Generating trace-hw_sparc64.c with a custom command (wrapped by meson to capture output) +[125/2124] Generating trace-hw_sparc.c with a custom command (wrapped by meson to capture output) +[126/2124] Generating trace-hw_sparc64.h with a custom command (wrapped by meson to capture output) +[127/2124] Generating trace-hw_ssi.h with a custom command (wrapped by meson to capture output) +[128/2124] Generating trace-hw_ssi.c with a custom command (wrapped by meson to capture output) +[129/2124] Generating trace-hw_timer.h with a custom command (wrapped by meson to capture output) +[130/2124] Generating trace-hw_timer.c with a custom command (wrapped by meson to capture output) +[131/2124] Generating trace-hw_tpm.h with a custom command (wrapped by meson to capture output) +[132/2124] Generating trace-hw_usb.h with a custom command (wrapped by meson to capture output) +[133/2124] Generating trace-hw_tpm.c with a custom command (wrapped by meson to capture output) +[134/2124] Generating trace-hw_usb.c with a custom command (wrapped by meson to capture output) +[135/2124] Generating trace-hw_vfio.c with a custom command (wrapped by meson to capture output) +[136/2124] Generating trace-hw_vfio.h with a custom command (wrapped by meson to capture output) +[137/2124] Generating trace-hw_xen.h with a custom command (wrapped by meson to capture output) +[138/2124] Generating trace-hw_virtio.h with a custom command (wrapped by meson to capture output) +[139/2124] Generating trace-hw_xen.c with a custom command (wrapped by meson to capture output) +[140/2124] Generating trace-hw_gpio.h with a custom command (wrapped by meson to capture output) +[141/2124] Generating trace-hw_gpio.c with a custom command (wrapped by meson to capture output) +[142/2124] Generating trace-migration.h with a custom command (wrapped by meson to capture output) +[143/2124] Generating trace-net.c with a custom command (wrapped by meson to capture output) +[144/2124] Generating trace-migration.c with a custom command (wrapped by meson to capture output) +[145/2124] Generating trace-softmmu.h with a custom command (wrapped by meson to capture output) +[146/2124] Generating trace-net.h with a custom command (wrapped by meson to capture output) +[147/2124] Generating trace-softmmu.c with a custom command (wrapped by meson to capture output) +[148/2124] Generating trace-ui.h with a custom command (wrapped by meson to capture output) +[149/2124] Generating trace-ui.c with a custom command (wrapped by meson to capture output) +[150/2124] Generating trace-hw_core.c with a custom command (wrapped by meson to capture output) +[151/2124] Generating trace-hw_core.h with a custom command (wrapped by meson to capture output) +[152/2124] Generating trace-qapi.h with a custom command (wrapped by meson to capture output) +[153/2124] Generating trace-qom.h with a custom command (wrapped by meson to capture output) +[154/2124] Generating trace-qapi.c with a custom command (wrapped by meson to capture output) +[155/2124] Generating trace-qom.c with a custom command (wrapped by meson to capture output) +[156/2124] Generating trace-target_arm.h with a custom command (wrapped by meson to capture output) +[157/2124] Generating trace-target_arm.c with a custom command (wrapped by meson to capture output) +[158/2124] Generating trace-target_hppa.h with a custom command (wrapped by meson to capture output) +[159/2124] Generating trace-target_hppa.c with a custom command (wrapped by meson to capture output) +[160/2124] Generating trace-target_i386.h with a custom command (wrapped by meson to capture output) +[161/2124] Generating trace-target_i386.c with a custom command (wrapped by meson to capture output) +[162/2124] Generating trace-target_mips.h with a custom command (wrapped by meson to capture output) +[163/2124] Generating trace-target_ppc.h with a custom command (wrapped by meson to capture output) +[164/2124] Generating trace-target_mips.c with a custom command (wrapped by meson to capture output) +[165/2124] Generating trace-target_ppc.c with a custom command (wrapped by meson to capture output) +[166/2124] Generating trace-target_riscv.h with a custom command (wrapped by meson to capture output) +[167/2124] Generating trace-target_riscv.c with a custom command (wrapped by meson to capture output) +[168/2124] Generating trace-target_s390x.h with a custom command (wrapped by meson to capture output) +[169/2124] Generating trace-target_s390x.c with a custom command (wrapped by meson to capture output) +[170/2124] Generating trace-target_sparc.h with a custom command (wrapped by meson to capture output) +[171/2124] Generating trace-util.h with a custom command (wrapped by meson to capture output) +[172/2124] Generating trace-target_sparc.c with a custom command (wrapped by meson to capture output) +[173/2124] Generating trace-util.c with a custom command (wrapped by meson to capture output) +[174/2124] Generating generated-helpers.c with a custom command (wrapped by meson to capture output) +[175/2124] Generating generated-tcg-tracers.h with a custom command (wrapped by meson to capture output) +[176/2124] Generating generated-helpers.h with a custom command (wrapped by meson to capture output) +[177/2124] Generating trace-events-all with a custom command (wrapped by meson to capture output) +[178/2124] Generating generated-helpers-wrappers.h with a custom command (wrapped by meson to capture output) +[179/2124] Generating input-keymap-linux-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[180/2124] Generating input-keymap-qcode-to-atset1.c.inc with a custom command (wrapped by meson to capture output) +[181/2124] Generating input-keymap-qcode-to-atset2.c.inc with a custom command (wrapped by meson to capture output) +[182/2124] Generating input-keymap-atset1-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[183/2124] Generating input-keymap-qcode-to-linux.c.inc with a custom command (wrapped by meson to capture output) +[184/2124] Generating input-keymap-qcode-to-qnum.c.inc with a custom command (wrapped by meson to capture output) +[185/2124] Generating input-keymap-qcode-to-atset3.c.inc with a custom command (wrapped by meson to capture output) +[186/2124] Generating input-keymap-qcode-to-sun.c.inc with a custom command (wrapped by meson to capture output) +[187/2124] Generating input-keymap-qnum-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[188/2124] Generating input-keymap-win32-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[189/2124] Generating input-keymap-usb-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[190/2124] Generating module_block.h with a custom command +[191/2124] Generating block-gen.c with a custom command +[192/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_lt_quiet.c.o +[193/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_isSignalingNaN.c.o +[194/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i64.c.o +[195/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui32.c.o +[196/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui64.c.o +[197/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i32.c.o +[198/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn16.c.inc'. +[199/2124] Generating input-keymap-xorgevdev-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[200/2124] Generating input-keymap-xorgxwin-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[201/2124] Generating texture-blit-frag.h with a custom command (wrapped by meson to capture output) +[202/2124] Generating texture-blit-vert.h with a custom command (wrapped by meson to capture output) +[203/2124] Generating input-keymap-xorgxquartz-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[204/2124] Generating input-keymap-xorgkbd-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[205/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn32.c.inc'. +[206/2124] Generating input-keymap-x11-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[207/2124] Generating QGA QAPI files with a custom command +[208/2124] Generating bepo with a custom command +[209/2124] Generating input-keymap-osx-to-qcode.c.inc with a custom command (wrapped by meson to capture output) +[210/2124] Generating ar with a custom command +[211/2124] Generating cz with a custom command +[212/2124] Generating texture-blit-flip-vert.h with a custom command (wrapped by meson to capture output) +[213/2124] Generating de with a custom command +[214/2124] Generating da with a custom command +[215/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/download.c.o +[216/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/addrspace.c.o +[217/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/qemu_elf.c.o +[218/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/main.c.o +[219/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/pdb.c.o +[220/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qdev.c.o +[221/2124] Compiling C object libqemuutil.a.p/stubs_ram-block.c.o +[222/2124] Generating riscv64-softmmu-gdbstub-xml.c with a custom command (wrapped by meson to capture output) +[223/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-acpi.c.o +[224/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-acpi.c.o +[225/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/ivshmem-client.c.o +[226/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-acpi.c.o +[227/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-acpi.c.o +[228/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/main.c.o +[229/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-authz.c.o +[230/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-types.c.o +[231/2124] Generating QAPI files for qemu-storage-daemon with a custom command +[232/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-audio.c.o +[233/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mips.c.o +[234/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-visit.c.o +[235/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-audio.c.o +[236/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-authz.c.o +[237/2124] Compiling C object libblock.fa.p/block_qed-check.c.o +[238/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-audio.c.o +[239/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-authz.c.o +[240/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-misc.c.o +[241/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-input-pci.c.o +[242/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-audio.c.o +[243/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block.c.o +[244/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-vsock-common.c.o +[245/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-block.c.o +[246/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-authz.c.o +[247/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-host-pci.c.o +[248/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block.c.o +[249/2124] Compiling C object libblock.fa.p/block_qed-cluster.c.o +[250/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-authz.c.o +[251/2124] Compiling C object libblock.fa.p/block_qed-l2-cache.c.o +[252/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block.c.o +[253/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-export.c.o +[254/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-misc.c.o +[255/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block.c.o +[256/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-export.c.o +[257/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-rng-pci.c.o +[258/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-char.c.o +[259/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-char.c.o +[260/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-core.c.o +[261/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-export.c.o +[262/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-export.c.o +[263/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-common.c.o +[264/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-common.c.o +[265/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-common.c.o +[266/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-common.c.o +[267/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-char.c.o +[268/2124] Compiling C object libqemuutil.a.p/util_getauxval.c.o +[269/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-char.c.o +[270/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-control.c.o +[271/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-core.c.o +[272/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-control.c.o +[273/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-control.c.o +[274/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-core.c.o +[275/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-control.c.o +[276/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-vsock-pci.c.o +[277/2124] Compiling C object libqemuutil.a.p/util_uuid.c.o +[278/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-blk-pci.c.o +[279/2124] Compiling C object libqemuutil.a.p/util_rcu.c.o +[280/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-crypto.c.o +[281/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-crypto.c.o +[282/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-crypto.c.o +[283/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-dump.c.o +[284/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-error.c.o +[285/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-dump.c.o +[286/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-dump.c.o +[287/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-error.c.o +[288/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-dump.c.o +[289/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-error.c.o +[290/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-error.c.o +[291/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-introspect.c.o +[292/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-introspect.c.o +[293/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-introspect.c.o +[294/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-crypto.c.o +[295/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-job.c.o +[296/2124] Compiling C object libqemuutil.a.p/stubs_cpu-get-clock.c.o +[297/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-job.c.o +[298/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-job.c.o +[299/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-job.c.o +[300/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-machine.c.o +[301/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-misc.c.o +[302/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-migration.c.o +[303/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-introspect.c.o +[304/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-migration.c.o +[305/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-machine.c.o +[306/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-balloon-pci.c.o +[307/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-crypto.c.o +[308/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-machine.c.o +[309/2124] Compiling C object libqemuutil.a.p/util_crc32c.c.o +[310/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-monitor.c.o +[311/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-9p-pci.c.o +[312/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-migration.c.o +[313/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-migration.c.o +[314/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pragma.c.o +[315/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-scsi-pci.c.o +[316/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-net.c.o +[317/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pragma.c.o +[318/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-net.c.o +[319/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-net.c.o +[320/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pragma.c.o +[321/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pragma.c.o +[322/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-misc.c.o +[323/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qdev.c.o +[324/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qdev.c.o +[325/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qom.c.o +[326/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pci.c.o +[327/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qdev.c.o +[328/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-net.c.o +[329/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qom.c.o +[330/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pci.c.o +[331/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pci.c.o +[332/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-machine.c.o +[333/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rdma.c.o +[334/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rocker.c.o +[335/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rdma.c.o +[336/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rdma.c.o +[337/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qom.c.o +[338/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pci.c.o +[339/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qom.c.o +[340/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rdma.c.o +[341/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-replay.c.o +[342/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-replay.c.o +[343/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-replay.c.o +[344/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-replay.c.o +[345/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rocker.c.o +[346/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rocker.c.o +[347/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-run-state.c.o +[348/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rocker.c.o +[349/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-run-state.c.o +[350/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-sockets.c.o +[351/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-sockets.c.o +[352/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-sockets.c.o +[353/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-run-state.c.o +[354/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-tpm.c.o +[355/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-tpm.c.o +[356/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-run-state.c.o +[357/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-trace.c.o +[358/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-trace.c.o +[359/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-tpm.c.o +[360/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-sockets.c.o +[361/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-trace.c.o +[362/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-tpm.c.o +[363/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-transaction.c.o +[364/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-trace.c.o +[365/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-transaction.c.o +[366/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-ui.c.o +[367/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-transaction.c.o +[368/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-ui.c.o +[369/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-root.c.o +[370/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_kvm.c.o +[371/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-transaction.c.o +[372/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-ui.c.o +[373/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_tcg.c.o +[374/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-nbd.c.o +[375/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-audio.c.o +[376/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-io.c.o +[377/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-scsi.c.o +[378/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends.c.o +[379/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-chardev.c.o +[380/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends_tpm.c.o +[381/2124] Compiling C object libblock.fa.p/block_dmg-bz2.c.o +[382/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_9pfs.c.o +[383/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_acpi.c.o +[384/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_alpha.c.o +[385/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_audio.c.o +[386/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block_dataplane.c.o +[387/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_arm.c.o +[388/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_char.c.o +[389/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block.c.o +[390/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hyperv.c.o +[391/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_dma.c.o +[392/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_display.c.o +[393/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i2c.c.o +[394/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-ui.c.o +[395/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hppa.c.o +[396/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ide.c.o +[397/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386_xen.c.o +[398/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386.c.o +[399/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_input.c.o +[400/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mem.c.o +[401/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_isa.c.o +[402/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_nvram.c.o +[403/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_intc.c.o +[404/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc_macio.c.o +[405/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc.c.o +[406/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci_host.c.o +[407/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci.c.o +[408/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ppc.c.o +[409/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma.c.o +[410/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma_vmw.c.o +[411/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_net.c.o +[412/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_s390x.c.o +[413/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rtc.c.o +[414/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc.c.o +[415/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-core.c.o +[416/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sd.c.o +[417/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_timer.c.o +[418/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc64.c.o +[419/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_scsi.c.o +[420/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_tpm.c.o +[421/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ssi.c.o +[422/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_virtio.c.o +[423/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_xen.c.o +[424/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_vfio.c.o +[425/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_usb.c.o +[426/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_watchdog.c.o +[427/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_gpio.c.o +[428/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-ui.c.o +[429/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qapi.c.o +[430/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-net.c.o +[431/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-softmmu.c.o +[432/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_core.c.o +[433/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-migration.c.o +[434/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qom.c.o +[435/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_arm.c.o +[436/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_hppa.c.o +[437/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_mips.c.o +[438/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_i386.c.o +[439/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_riscv.c.o +[440/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_ppc.c.o +[441/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-util.c.o +[442/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_s390x.c.o +[443/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_sparc.c.o +[444/2124] Compiling C object libqemuutil.a.p/qapi_qapi-dealloc-visitor.c.o +[445/2124] Compiling C object libqemuutil.a.p/qapi_qapi-util.c.o +[446/2124] Compiling C object libqemuutil.a.p/qapi_qapi-clone-visitor.c.o +[447/2124] Compiling C object libqemuutil.a.p/qapi_qmp-event.c.o +[448/2124] Compiling C object libqemuutil.a.p/qapi_opts-visitor.c.o +[449/2124] Compiling C object libqemuutil.a.p/qapi_qmp-dispatch.c.o +[450/2124] Compiling C object libqemuutil.a.p/qobject_qnull.c.o +[451/2124] Compiling C object libqemuutil.a.p/qapi_qobject-output-visitor.c.o +[452/2124] Compiling C object libqemuutil.a.p/qapi_qmp-registry.c.o +[453/2124] Compiling C object libqemuutil.a.p/qapi_string-input-visitor.c.o +[454/2124] Compiling C object libqemuutil.a.p/qobject_qstring.c.o +[455/2124] Compiling C object libqemuutil.a.p/qobject_qnum.c.o +[456/2124] Compiling C object libqemuutil.a.p/qapi_string-output-visitor.c.o +[457/2124] Compiling C object libqemuutil.a.p/qobject_qobject.c.o +[458/2124] Compiling C object libqemuutil.a.p/qobject_qbool.c.o +[459/2124] Compiling C object libqemuutil.a.p/qapi_qapi-visit-core.c.o +[460/2124] Compiling C object libqemuutil.a.p/qobject_qlist.c.o +[461/2124] Compiling C object libqemuutil.a.p/qapi_qobject-input-visitor.c.o +[462/2124] Compiling C object libqemuutil.a.p/qobject_qlit.c.o +[463/2124] Compiling C object libqemuutil.a.p/qobject_json-lexer.c.o +[464/2124] Compiling C object libqemuutil.a.p/qobject_qdict.c.o +[465/2124] Compiling C object libqemuutil.a.p/qobject_qjson.c.o +[466/2124] Compiling C object libqemuutil.a.p/util_unicode.c.o +[467/2124] Compiling C object libqemuutil.a.p/qobject_json-streamer.c.o +[468/2124] Compiling C object libqemuutil.a.p/util_qemu-timer-common.c.o +[469/2124] Compiling C object libqemuutil.a.p/util_fdmon-poll.c.o +[470/2124] Compiling C object libqemuutil.a.p/qobject_json-parser.c.o +[471/2124] Compiling C object libqemuutil.a.p/util_compatfd.c.o +[472/2124] Compiling C object libqemuutil.a.p/util_event_notifier-posix.c.o +[473/2124] Compiling C object libqemuutil.a.p/util_fdmon-epoll.c.o +[474/2124] Compiling C object libqemuutil.a.p/util_qemu-openpty.c.o +[475/2124] Compiling C object libqemuutil.a.p/qobject_block-qdict.c.o +[476/2124] Compiling C object libqemuutil.a.p/util_mmap-alloc.c.o +[477/2124] Compiling C object libqemuutil.a.p/util_fdmon-io_uring.c.o +[478/2124] Compiling C object libqemuutil.a.p/util_osdep.c.o +[479/2124] Compiling C object libqemuutil.a.p/util_module.c.o +[480/2124] Compiling C object libqemuutil.a.p/util_cutils.c.o +[481/2124] Compiling C object libqemuutil.a.p/util_host-utils.c.o +[482/2124] Compiling C object libqemuutil.a.p/util_memfd.c.o +[483/2124] Compiling C object libqemuutil.a.p/util_envlist.c.o +[484/2124] Compiling C object libqemuutil.a.p/util_path.c.o +[485/2124] Compiling C object libqemuutil.a.p/util_aio-posix.c.o +[486/2124] Compiling C object libqemuutil.a.p/util_fifo8.c.o +[487/2124] Compiling C object libqemuutil.a.p/util_bitops.c.o +[488/2124] Compiling C object libqemuutil.a.p/util_cacheinfo.c.o +[489/2124] Compiling C object libqemuutil.a.p/util_qemu-thread-posix.c.o +[490/2124] Compiling C object libqemuutil.a.p/util_id.c.o +[491/2124] Compiling C object libqemuutil.a.p/util_qemu-print.c.o +[492/2124] Compiling C object libqemuutil.a.p/util_oslib-posix.c.o +[493/2124] Compiling C object libqemuutil.a.p/util_error.c.o +[494/2124] Compiling C object libqemuutil.a.p/util_notify.c.o +[495/2124] Compiling C object libqemuutil.a.p/util_qemu-progress.c.o +[496/2124] Compiling C object libqemuutil.a.p/util_bitmap.c.o +[497/2124] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +[498/2124] Compiling C object libqemuutil.a.p/util_keyval.c.o +[499/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-pci.c.o +[500/2124] Compiling C object libqemuutil.a.p/util_qemu-config.c.o +[501/2124] Compiling C object libqemuutil.a.p/util_pagesize.c.o +[502/2124] Compiling C object libqemuutil.a.p/util_log.c.o +[503/2124] Compiling C object libqemuutil.a.p/util_range.c.o +[504/2124] Compiling C object libqemuutil.a.p/util_drm.c.o +[505/2124] Compiling C object libqemuutil.a.p/util_stats64.c.o +[506/2124] Compiling C object libqemuutil.a.p/util_qdist.c.o +[507/2124] Compiling C object libqemuutil.a.p/util_systemd.c.o +[508/2124] Compiling C object libqemuutil.a.p/util_aiocb.c.o +[509/2124] Compiling C object libblock.fa.p/block_dmg.c.o +[510/2124] Compiling C object libqemuutil.a.p/util_guest-random.c.o +[511/2124] Compiling C object libqemuutil.a.p/util_base64.c.o +[512/2124] Compiling C object libqemuutil.a.p/util_qht.c.o +[513/2124] Compiling C object libqemuutil.a.p/util_aio-wait.c.o +[514/2124] Compiling C object libqemuutil.a.p/util_async.c.o +[515/2124] Compiling C object libqemuutil.a.p/util_qemu-option.c.o +[516/2124] Compiling C object libqemuutil.a.p/util_dbus.c.o +[517/2124] Compiling C object libqemuutil.a.p/util_qsp.c.o +[518/2124] Compiling C object libqemuutil.a.p/util_hexdump.c.o +[519/2124] Compiling C object libblock.fa.p/block_curl.c.o +[520/2124] Compiling C object libqemuutil.a.p/util_coroutine-ucontext.c.o +[521/2124] Compiling C object libqemuutil.a.p/util_buffer.c.o +[522/2124] Compiling C object libqemuutil.a.p/util_iova-tree.c.o +[523/2124] Compiling C object libqemuutil.a.p/util_main-loop.c.o +[524/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-io.c.o +[525/2124] Compiling C object libqemuutil.a.p/util_lockcnt.c.o +[526/2124] Compiling C object libqemuutil.a.p/util_nvdimm-utils.c.o +[527/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine.c.o +[528/2124] Compiling C object libqemuutil.a.p/util_iov.c.o +[529/2124] Compiling C object libqemuutil.a.p/util_hbitmap.c.o +[530/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-sleep.c.o +[531/2124] Compiling C object libqemuutil.a.p/util_bufferiszero.c.o +[532/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-lock.c.o +[533/2124] Compiling C object libqemuutil.a.p/util_block-helpers.c.o +[534/2124] Compiling C object libqemuutil.a.p/util_qemu-co-shared-resource.c.o +[535/2124] Compiling C object libqemuutil.a.p/util_vhost-user-server.c.o +[536/2124] Compiling C object libqemuutil.a.p/util_qemu-sockets.c.o +[537/2124] Compiling C object libqemuutil.a.p/util_timed-average.c.o +[538/2124] Compiling C object libqemuutil.a.p/crypto_random-gnutls.c.o +[539/2124] Compiling C object libqemuutil.a.p/crypto_init.c.o +[540/2124] Compiling C object libqemuutil.a.p/util_filemonitor-inotify.c.o +[541/2124] Compiling C object libqemuutil.a.p/util_readline.c.o +[542/2124] Compiling C object libqemuutil.a.p/util_thread-pool.c.o +[543/2124] Compiling C object libqemuutil.a.p/stubs_arch_type.c.o +[544/2124] Compiling C object libqemuutil.a.p/util_qemu-timer.c.o +[545/2124] Compiling C object libqemuutil.a.p/crypto_aes.c.o +[546/2124] Compiling C object libqemuutil.a.p/trace_qmp.c.o +[547/2124] Compiling C object libqemuutil.a.p/util_throttle.c.o +[548/2124] Compiling C object libqemuutil.a.p/util_uri.c.o +[549/2124] Compiling C object libqemuutil.a.p/stubs_blockdev-close-all-bdrv-states.c.o +[550/2124] Compiling C object libqemuutil.a.p/stubs_bdrv-next-monitor-owned.c.o +[551/2124] Compiling C object libqemuutil.a.p/stubs_blk-exp-close-all.c.o +[552/2124] Compiling C object libqemuutil.a.p/stubs_change-state-handler.c.o +[553/2124] Compiling C object libqemuutil.a.p/stubs_blk-commit-all.c.o +[554/2124] Compiling C object libqemuutil.a.p/stubs_cpus-get-virtual-clock.c.o +[555/2124] Compiling C object libqemuutil.a.p/stubs_cmos.c.o +[556/2124] Compiling C object libqemuutil.a.p/stubs_qemu-timer-notify-cb.c.o +[557/2124] Compiling C object libqemuutil.a.p/stubs_dump.c.o +[558/2124] Compiling C object libqemuutil.a.p/trace_control.c.o +[559/2124] Compiling C object libqemuutil.a.p/util_vfio-helpers.c.o +[560/2124] Compiling C object libqemuutil.a.p/stubs_error-printf.c.o +[561/2124] Compiling C object libqemuutil.a.p/stubs_gdbstub.c.o +[562/2124] Compiling C object libqemuutil.a.p/stubs_icount.c.o +[563/2124] Compiling C object libqemuutil.a.p/stubs_io_uring.c.o +[564/2124] Compiling C object libqemuutil.a.p/stubs_iothread.c.o +[565/2124] Compiling C object libqemuutil.a.p/stubs_get-vm-name.c.o +[566/2124] Compiling C object libqemuutil.a.p/stubs_fw_cfg.c.o +[567/2124] Compiling C object libqemuutil.a.p/stubs_is-daemonized.c.o +[568/2124] Compiling C object libqemuutil.a.p/stubs_iothread-lock.c.o +[569/2124] Compiling C object libqemuutil.a.p/stubs_fdset.c.o +[570/2124] Compiling C object libqemuutil.a.p/stubs_machine-init-done.c.o +[571/2124] Compiling C object libqemuutil.a.p/stubs_migr-blocker.c.o +[572/2124] Compiling C object libqemuutil.a.p/stubs_linux-aio.c.o +[573/2124] Compiling C object libqemuutil.a.p/stubs_isa-bus.c.o +[574/2124] Compiling C object libqemuutil.a.p/stubs_runstate-check.c.o +[575/2124] Compiling C object libqemuutil.a.p/stubs_qtest.c.o +[576/2124] Compiling C object libqemuutil.a.p/stubs_monitor.c.o +[577/2124] Compiling C object libqemuutil.a.p/stubs_ramfb.c.o +[578/2124] Compiling C object libqemuutil.a.p/stubs_pci-bus.c.o +[579/2124] Compiling C object libqemuutil.a.p/stubs_qmp_memory_device.c.o +[580/2124] Compiling C object libqemuutil.a.p/stubs_monitor-core.c.o +[581/2124] Compiling C object libqemuutil.a.p/stubs_sysbus.c.o +[582/2124] Compiling C object libqemuutil.a.p/stubs_pci-host-piix.c.o +[583/2124] Compiling C object libqemuutil.a.p/stubs_replay.c.o +[584/2124] Compiling C object libqemuutil.a.p/stubs_target-monitor-defs.c.o +[585/2124] Compiling C object libqemuutil.a.p/stubs_set-fd-handler.c.o +[586/2124] Compiling C object libqemuutil.a.p/stubs_target-get-monitor-def.c.o +[587/2124] Compiling C object libqemuutil.a.p/stubs_tpm.c.o +[588/2124] Compiling C object libqemuutil.a.p/stubs_trace-control.c.o +[589/2124] Compiling C object libqemuutil.a.p/stubs_uuid.c.o +[590/2124] Compiling C object libqemuutil.a.p/stubs_vmstate.c.o +[591/2124] Compiling C object libqemuutil.a.p/stubs_vm-stop.c.o +[592/2124] Compiling C object libqemuutil.a.p/stubs_win32-kbd-hook.c.o +[593/2124] Compiling C object libcommon.fa.p/hw_net_rocker_rocker_of_dpa.c.o +[594/2124] Compiling C object libqemuutil.a.p/stubs_vmgenid.c.o +[595/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu.c.o +[596/2124] Compiling C object libqemuutil.a.p/stubs_cpu-synchronize-state.c.o +[597/2124] Compiling C object libqemuutil.a.p/stubs_replay-tools.c.o +[598/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_fpu_helper.c.o +[599/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_csr.c.o +[600/2124] Compiling C object libqemuutil.a.p/stubs_semihost.c.o +[601/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qos_external.c.o +[602/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-marshal.c.o +[603/2124] Compiling C object libqemuutil.a.p/stubs_xen-hw-stub.c.o +[604/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-iov-marshal.c.o +[605/2124] Compiling C object fsdev/virtfs-proxy-helper.p/virtfs-proxy-helper.c.o +[606/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-spapr.c.o +[607/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos.c.o +[608/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc.c.o +[609/2124] Linking static target libqemuutil.a +[610/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/rtas.c.o +[611/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/fw_cfg.c.o +[612/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-spapr.c.o +[613/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qgraph.c.o +[614/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci.c.o +[615/2124] Linking target fsdev/virtfs-proxy-helper +[616/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-spapr.c.o +[617/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-pc.c.o +[618/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-pc.c.o +[619/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/usb.c.o +[620/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-pc.c.o +[621/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/e1000e.c.o +[622/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu_helper.c.o +[623/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c.c.o +[624/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-omap.c.o +[625/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-imx.c.o +[626/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/tpci200.c.o +[627/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/.._libqtest.c.o +[628/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-balloon.c.o +[629/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-9p.c.o +[630/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-blk.c.o +[631/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/sdhci.c.o +[632/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-mmio.c.o +[633/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-rng.c.o +[634/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/aarch64-xlnx-zcu102-machine.c.o +[635/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-imx25-pdk-machine.c.o +[636/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-net.c.o +[637/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-scsi.c.o +[638/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-n800-machine.c.o +[639/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio.c.o +[640/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-serial.c.o +[641/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci-modern.c.o +[642/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-smdkc210-machine.c.o +[643/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-raspi2-machine.c.o +[644/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-sabrelite-machine.c.o +[645/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-xilinx-zynq-a9-machine.c.o +[646/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci.c.o +[647/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ppc64_pseries-machine.c.o +[648/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-virt-machine.c.o +[649/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/x86_64_pc-machine.c.o +[650/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ahci.c.o +[651/2124] Compiling C object libqom.fa.p/qom_container.c.o +[652/2124] Compiling C object libauthz.fa.p/authz_base.c.o +[653/2124] Linking static target tests/qtest/libqos/libqos.fa +[654/2124] Compiling C object libqom.fa.p/qom_qom-qobject.c.o +[655/2124] Compiling C object libqom.fa.p/hw_nvram_fw_cfg-interface.c.o +[656/2124] Generating block.syms with a custom command (wrapped by meson to capture output) +[657/2124] Compiling C object libauthz.fa.p/authz_simple.c.o +[658/2124] Compiling C object libqom.fa.p/qom_object_interfaces.c.o +[659/2124] Compiling C object libauthz.fa.p/authz_list.c.o +[660/2124] Generating qemu.syms with a custom command (wrapped by meson to capture output) +[661/2124] Compiling C object libauthz.fa.p/authz_listfile.c.o +[662/2124] Compiling C object libauthz.fa.p/authz_pamacct.c.o +[663/2124] Linking static target libauthz.fa +[664/2124] Compiling C object libcrypto.fa.p/crypto_afsplit.c.o +[665/2124] Compiling C object libcrypto.fa.p/crypto_block-qcow.c.o +[666/2124] Compiling C object libcrypto.fa.p/crypto_hash.c.o +[667/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain64.c.o +[668/2124] Compiling C object libcrypto.fa.p/crypto_block.c.o +[669/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-essiv.c.o +[670/2124] Compiling C object libcrypto.fa.p/crypto_hmac.c.o +[671/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain.c.o +[672/2124] Compiling C object libcrypto.fa.p/crypto_desrfb.c.o +[673/2124] Compiling C object libcrypto.fa.p/crypto_ivgen.c.o +[674/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf.c.o +[675/2124] Compiling C object libcrypto.fa.p/crypto_secret.c.o +[676/2124] Compiling C object libcrypto.fa.p/crypto_tlscreds.c.o +[677/2124] Compiling C object libcrypto.fa.p/crypto_secret_common.c.o +[678/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsanon.c.o +[679/2124] Compiling C object libcrypto.fa.p/crypto_hash-nettle.c.o +[680/2124] Compiling C object libcrypto.fa.p/crypto_tlscredspsk.c.o +[681/2124] Compiling C object libcrypto.fa.p/crypto_block-luks.c.o +[682/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf-nettle.c.o +[683/2124] Compiling C object libcrypto.fa.p/crypto_secret_keyring.c.o +[684/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsx509.c.o +[685/2124] Compiling C object libcrypto.fa.p/crypto_hmac-nettle.c.o +[686/2124] Compiling C object libio.fa.p/io_channel-command.c.o +[687/2124] Compiling C object libcrypto.fa.p/crypto_tlssession.c.o +[688/2124] Compiling C object libcrypto.fa.p/crypto_cipher.c.o +[689/2124] Compiling C object libcrypto.fa.p/crypto_tls-cipher-suites.c.o +[690/2124] Compiling C object libio.fa.p/io_channel-buffer.c.o +[691/2124] Compiling C object libmigration.fa.p/migration_page_cache.c.o +[692/2124] Compiling C object libio.fa.p/io_channel-util.c.o +[693/2124] Linking static target libcrypto.fa +[694/2124] Compiling C object libio.fa.p/io_channel-file.c.o +[695/2124] Compiling C object libio.fa.p/io_channel-watch.c.o +[696/2124] Compiling C object libqom.fa.p/qom_object.c.o +[697/2124] Compiling C object libio.fa.p/io_channel-tls.c.o +[698/2124] Linking static target libqom.fa +[699/2124] Compiling C object libio.fa.p/io_dns-resolver.c.o +[700/2124] Compiling C object libmigration.fa.p/migration_xbzrle.c.o +[701/2124] Compiling C object libio.fa.p/io_channel.c.o +[702/2124] Compiling C object libio.fa.p/io_task.c.o +[703/2124] Compiling C object libio.fa.p/io_channel-socket.c.o +[704/2124] Compiling C object libmigration.fa.p/migration_qemu-file-channel.c.o +[705/2124] Compiling C object libmigration.fa.p/migration_qjson.c.o +[706/2124] Compiling C object libio.fa.p/io_net-listener.c.o +[707/2124] Compiling C object libio.fa.p/io_channel-websock.c.o +[708/2124] Linking static target libio.fa +[709/2124] Compiling C object libblock.fa.p/replication.c.o +[710/2124] Compiling C object libmigration.fa.p/migration_vmstate.c.o +[711/2124] Compiling C object libmigration.fa.p/migration_vmstate-types.c.o +[712/2124] Compiling C object libblock.fa.p/meson-generated_.._block_block-gen.c.o +[713/2124] Compiling C object libmigration.fa.p/migration_qemu-file.c.o +[714/2124] Compiling C object libblock.fa.p/blockjob.c.o +[715/2124] Linking static target libmigration.fa +[716/2124] Compiling C object libblock.fa.p/nbd_common.c.o +[717/2124] Compiling C object libblock.fa.p/scsi_utils.c.o +[718/2124] Compiling C object libblock.fa.p/scsi_pr-manager.c.o +[719/2124] Compiling C object libblock.fa.p/block_aio_task.c.o +[720/2124] Compiling C object libblock.fa.p/block_nfs.c.o +[721/2124] Compiling C object libblock.fa.p/job.c.o +[722/2124] Compiling C object libblock.fa.p/block_amend.c.o +[723/2124] Compiling C object libblock.fa.p/scsi_pr-manager-helper.c.o +[724/2124] Compiling C object libblock.fa.p/block_accounting.c.o +[725/2124] Compiling C object libblock.fa.p/block_blklogwrites.c.o +[726/2124] Compiling C object libblock.fa.p/block_backup-top.c.o +[727/2124] Compiling C object libblock.fa.p/block_blkverify.c.o +[728/2124] Compiling C object libblock.fa.p/qemu-io-cmds.c.o +[729/2124] Compiling C object libblock.fa.p/block_backup.c.o +[730/2124] Compiling C object libblock.fa.p/block_commit.c.o +[731/2124] Compiling C object libblock.fa.p/nbd_client.c.o +[732/2124] Compiling C object libblock.fa.p/block_blkdebug.c.o +[733/2124] Compiling C object libblock.fa.p/block_create.c.o +[734/2124] Compiling C object libblock.fa.p/block_copy-on-read.c.o +[735/2124] Compiling C object libblock.fa.p/block_dirty-bitmap.c.o +[736/2124] Compiling C object libblock.fa.p/block_block-copy.c.o +[737/2124] Compiling C object libblock.fa.p/block_null.c.o +[738/2124] Compiling C object libblock.fa.p/block_filter-compress.c.o +[739/2124] Compiling C object libblock.fa.p/block_crypto.c.o +[740/2124] Compiling C object libblock.fa.p/block_qapi.c.o +[741/2124] Compiling C object libblock.fa.p/block_block-backend.c.o +[742/2124] Compiling C object libblock.fa.p/block_raw-format.c.o +[743/2124] Compiling C object libblock.fa.p/block_mirror.c.o +[744/2124] Compiling C object libblock.fa.p/block_snapshot.c.o +[745/2124] Compiling C object libblock.fa.p/block_qcow2-cache.c.o +[746/2124] Compiling C object libblock.fa.p/block_quorum.c.o +[747/2124] Compiling C object libblock.fa.p/block_nbd.c.o +[748/2124] Compiling C object libblock.fa.p/block_qcow2-bitmap.c.o +[749/2124] Compiling C object libblock.fa.p/block_throttle-groups.c.o +[750/2124] Compiling C object libblock.fa.p/block_qcow2-threads.c.o +[751/2124] Compiling C object libblock.fa.p/block_qcow2-snapshot.c.o +[752/2124] Compiling C object libblock.fa.p/block_cloop.c.o +[753/2124] Compiling C object libblock.fa.p/block_bochs.c.o +[754/2124] Compiling C object libblock.fa.p/block_vpc.c.o +FAILED: libblock.fa.p/block_vpc.c.o +cc -Ilibblock.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem /home/peterlin/Labs/riscv64-linux/qemu/linux-headers -isystem linux-headers -iquote /home/peterlin/Labs/riscv64-linux/qemu/tcg/i386 -iquote . -iquote /home/peterlin/Labs/riscv64-linux/qemu -iquote /home/peterlin/Labs/riscv64-linux/qemu/accel/tcg -iquote /home/peterlin/Labs/riscv64-linux/qemu/include -iquote /home/peterlin/Labs/riscv64-linux/qemu/disas/libvixl -pthread -fPIE -DHAVE_LIBSSH_0_8 -MD -MQ libblock.fa.p/block_vpc.c.o -MF libblock.fa.p/block_vpc.c.o.d -o libblock.fa.p/block_vpc.c.o -c ../block/vpc.c +../block/vpc.c: In function ‘vpc_open’: +../block/vpc.c:358:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 358 | s->block_size = be32_to_cpu(dyndisk_header->block_size); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +../block/vpc.c:366:58: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 366 | s->max_table_entries = be32_to_cpu(dyndisk_header->max_table_entries); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +../block/vpc.c:398:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds] + 398 | s->bat_offset = be64_to_cpu(dyndisk_header->table_offset); + | ^~ +../block/vpc.c:223:13: note: while referencing ‘buf’ + 223 | uint8_t buf[HEADER_SIZE]; + | ^~~ +cc1: all warnings being treated as errors +[755/2124] Compiling C object libblock.fa.p/block.c.o +[756/2124] Compiling C object libblock.fa.p/block_vhdx.c.o +[757/2124] Compiling C object libblock.fa.p/block_throttle.c.o +[758/2124] Compiling C object libblock.fa.p/block_vhdx-endian.c.o +[759/2124] Compiling C object libblock.fa.p/block_io.c.o +[760/2124] Compiling C object libblock.fa.p/block_qcow2-refcount.c.o +[761/2124] Compiling C object libblock.fa.p/block_qed-table.c.o +[762/2124] Compiling C object libblock.fa.p/block_qcow2-cluster.c.o +[763/2124] Compiling C object libblock.fa.p/block_vmdk.c.o +[764/2124] Compiling C object libblock.fa.p/block_qcow2.c.o +[765/2124] Compiling C object libblock.fa.p/block_vvfat.c.o +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:171: run-ninja] Error 1 +make[1]: Leaving directory '/home/peterlin/Labs/riscv64-linux/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 +``` diff --git a/results/classifier/gemma3:12b/files/498523 b/results/classifier/gemma3:12b/files/498523 new file mode 100644 index 00000000..3890f9c8 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/523 b/results/classifier/gemma3:12b/files/523 new file mode 100644 index 00000000..5cd55b96 --- /dev/null +++ b/results/classifier/gemma3:12b/files/523 @@ -0,0 +1,127 @@ + +Some iotests failing with --enable-block-drv-whitelist-in-tools +Description of problem: +Building latest RC with Fedora, some of the iotests now report fail. We could track it down to the --enable-block-drv-whitelist-in-tools option. +Steps to reproduce: +1. ```configure --enable-block-drv-whitelist-in-tools``` +2. ```make``` +3. ```make check``` +Additional information: +``` +... + TEST iotest-qcow2: 049 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/049.out ++++ 049.out.bad +@@ -199,6 +199,8 @@ + qemu-img create -f qcow2 --object secret,id=sec0,data=123456 -o encryption=on,encrypt.key-secret=sec0 TEST_DIR/t.qcow2 64M + Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 encryption=on encrypt.key-secret=sec0 cluster_size=65536 extended_l2=off compression_type=zlib size=67108864 lazy_refcounts=off refcount_bits=16 ++qemu-img: TEST_DIR/t.qcow2: Use of AES-CBC encrypted qcow2 images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted qcow2, or raw with the LUKS format instead. + == Check lazy_refcounts option (only with v3) == +... + TEST iotest-qcow2: 134 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/134.out ++++ 134.out.bad +@@ -1,30 +1,24 @@ + QA output created by 134 + Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on ++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == reading whole image == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == rewriting cluster part == +-wrote 512/512 bytes at offset 512 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 512/512 bytes at offset 0 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 512/512 bytes at offset 512 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == rewriting whole image == +-wrote 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern failure with wrong password == +-Pattern verification failed at offset 0, 134217728 bytes +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + *** done +... + TEST iotest-qcow2: 158 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/158.out ++++ 158.out.bad +@@ -1,26 +1,25 @@ + QA output created by 158 + == create base == + Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728 encryption=on ++qemu-img: TEST_DIR/t.IMGFMT.base: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == writing whole image == +-wrote 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory + == verify pattern == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory + == create overlay == + Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT encryption=on ++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == writing part of a cluster == +-wrote 1024/1024 bytes at offset 0 +-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 1024/1024 bytes at offset 0 +-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 64512/64512 bytes at offset 1024 +-63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + *** done +... +Failures: 049 134 158 +Failed 3 of 122 iotests +``` diff --git a/results/classifier/gemma3:12b/files/527 b/results/classifier/gemma3:12b/files/527 new file mode 100644 index 00000000..cd0469d2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/527 @@ -0,0 +1,2 @@ + +Plain text files in docs/ should be converted to rst diff --git a/results/classifier/gemma3:12b/files/545089 b/results/classifier/gemma3:12b/files/545089 new file mode 100644 index 00000000..3bbc2ae0 --- /dev/null +++ b/results/classifier/gemma3:12b/files/545089 @@ -0,0 +1,18 @@ + +qemu-img should be able to create scsi based vmdk images + +qemu-img can create vmdk disk images. These are always created as "ide" disks; that is, the paramter ddb.adapterType is set to "ide" in the .vmdk file. + +I needed to create a scsi style vmdk image, in which ddb.adapterType is set to "lsilogic". + +The attached patch (against qemu-0.12.3) allows me to convert a raw image into a scsi vmdk image: + + qemu-img convert -O vmdk -o scsi rootfs.raw rootfs.vmdk + +The "scsi" option works also for the "create" command. + +I hope very much that this change can be rolled into qemu. + +best, + +Seb James \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/562 b/results/classifier/gemma3:12b/files/562 new file mode 100644 index 00000000..020f425a --- /dev/null +++ b/results/classifier/gemma3:12b/files/562 @@ -0,0 +1,2 @@ + +`ShaderTranslator.h` and `ShaderTranslator.cpp` files are missing and are not in ANGLE_ROOT/src/libShaderTranslator diff --git a/results/classifier/gemma3:12b/files/567376 b/results/classifier/gemma3:12b/files/567376 new file mode 100644 index 00000000..c759dbc2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/567380 b/results/classifier/gemma3:12b/files/567380 new file mode 100644 index 00000000..94129509 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/568053 b/results/classifier/gemma3:12b/files/568053 new file mode 100644 index 00000000..4ab021c3 --- /dev/null +++ b/results/classifier/gemma3:12b/files/568053 @@ -0,0 +1,4 @@ + +requires MSYS coreutils ext sub-package to build on Windows + +When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/583 b/results/classifier/gemma3:12b/files/583 new file mode 100644 index 00000000..df77f3b4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/583 @@ -0,0 +1,2 @@ + +Last cylinder of CHS disk image is not declared as accessible in image diff --git a/results/classifier/gemma3:12b/files/584146 b/results/classifier/gemma3:12b/files/584146 new file mode 100644 index 00000000..b75719cd --- /dev/null +++ b/results/classifier/gemma3:12b/files/584146 @@ -0,0 +1,8 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/589 b/results/classifier/gemma3:12b/files/589 new file mode 100644 index 00000000..79c496f8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/589 @@ -0,0 +1,2 @@ + +Error installing QGA file under virtual machine of windows system diff --git a/results/classifier/gemma3:12b/files/592 b/results/classifier/gemma3:12b/files/592 new file mode 100644 index 00000000..8cd3fb54 --- /dev/null +++ b/results/classifier/gemma3:12b/files/592 @@ -0,0 +1,109 @@ + +CloudLinux / CageFS - guest-fsfreeze hangs system +Description of problem: +Since CloudLinux provides CageFS (virtualized file system), each time guest-fsfreeze for Proxmox backup, the system is hangs up and become unavailable. It's caused by cagefs-skeleton mount points: + +``` +sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) +proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=1002,hidepid=2) +devtmpfs on /dev type devtmpfs (rw,nosuid,size=3993656k,nr_inodes=998414,mode=755) +securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) +tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) +devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) +tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) +tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) +cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) +pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) +configfs on /sys/kernel/config type configfs (rw,relatime) +/dev/sda2 on / type ext4 (rw,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +mqueue on /dev/mqueue type mqueue (rw,relatime) +hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) +debugfs on /sys/kernel/debug type debugfs (rw,relatime) +fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) +/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered) +/usr/tmpDSK on /tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +/usr/tmpDSK on /var/tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) +cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) +cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,relatime,cpuacct,cpu) +cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) +cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) +/dev/sda2 on /usr/share/cagefs-skeleton type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +devpts on /usr/share/cagefs-skeleton/dev/pts type devpts (rw,nosuid,relatime,gid=5,mode=620,ptmxmode=000) +/dev/sda2 on /usr/share/cagefs-skeleton/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/include type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/apache/domlogs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/perl type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Cpanel type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/base type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cgi-priv type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cpaddons type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/hooks type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/htdocs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/img-sys type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/install type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lang type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/libexec type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/scripts type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/shared type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/sys_cpanel/boxtrapper-message type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/var type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr/docroot/cgi/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.nodejs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.python type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/man type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/terminfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/vim type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/zoneinfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/cpanel/ea4 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/mysql type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/proxyexec/cagefs.sock type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/spamassassin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +tmpfs on /usr/share/cagefs-skeleton/run/dbus type tmpfs (rw,nosuid,mode=755) +tmpfs on /usr/share/cagefs-skeleton/run/nscd type tmpfs (rw,nosuid,mode=755) +/dev/sda2 on /usr/share/cagefs-skeleton/var/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/spool/at type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/cgi-bin type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/html type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/suphp/sbin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lve/lveinfo.ver.cagefs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +proc on /usr/share/cagefs-skeleton/proc type proc (rw,nosuid,relatime,gid=1002,hidepid=2) +systemd-1 on /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc type autofs (rw,nosuid,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=800880k,mode=700) +``` + +Is there anyway qemu-guest-agent can handle this? I saw a lot of users faced this problem since CloudLinux becomes more popular after RHEL halted future CentOS releases. + +CloudLinux has an option to umount/mount cagefs-skeleton, maybe it's something can be implemented - https://docs.cloudlinux.com/command-line_tools/ + +The same issue happens when JailShell is enabled on cPanel servers (OVH reported about) - https://docs.ovh.com/ca/en/vps/cpanel_auto_backup/ + +Thank you for your time. +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. diff --git a/results/classifier/gemma3:12b/files/603878 b/results/classifier/gemma3:12b/files/603878 new file mode 100644 index 00000000..c8ebb83d --- /dev/null +++ b/results/classifier/gemma3:12b/files/603878 @@ -0,0 +1,10 @@ + +[Feature request] qemu-img option about recompressing + +Suppose I have a fresh compressed qcow2 image. After some time the data were recorded without compression. I decide to make "QEMU-IMG convert" for that image to reduce its size. + +I want a new option, which selects between the two algorithms overdriven images: +1. extract all / compress again when converting images (in the current implementation) +2. compress only uncompressed blocks and just copy the compressed blocks without re-compression. + +This option is only needed when converting compressed image to compressed and the compression algorithm is the same. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/608 b/results/classifier/gemma3:12b/files/608 new file mode 100644 index 00000000..2049eece --- /dev/null +++ b/results/classifier/gemma3:12b/files/608 @@ -0,0 +1,2 @@ + +incremental_live_backup: Error prompt info when do incremental backup with an invalid "bitmap-mode" diff --git a/results/classifier/gemma3:12b/files/632 b/results/classifier/gemma3:12b/files/632 new file mode 100644 index 00000000..e7f1d7fc --- /dev/null +++ b/results/classifier/gemma3:12b/files/632 @@ -0,0 +1,2 @@ + +We should document "make install DESTDIR=wherever" diff --git a/results/classifier/gemma3:12b/files/66 b/results/classifier/gemma3:12b/files/66 new file mode 100644 index 00000000..0ea2fec9 --- /dev/null +++ b/results/classifier/gemma3:12b/files/66 @@ -0,0 +1,2 @@ + +-hda FAT:. limited to 504MBytes diff --git a/results/classifier/gemma3:12b/files/660366 b/results/classifier/gemma3:12b/files/660366 new file mode 100644 index 00000000..50303507 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/674740 b/results/classifier/gemma3:12b/files/674740 new file mode 100644 index 00000000..1a0de206 --- /dev/null +++ b/results/classifier/gemma3:12b/files/674740 @@ -0,0 +1,16 @@ + +qemu segfaults when security_model=none using virtio-9p-pci driver + +qemu version: 0.13 +commit-id: 6ed912999d6ef636a5be5ccb266d7d3c0f0310b4 + +example invocation: +$ qemu -virtfs local,path=/tmp,security_model=none,mount_tag=mmm r.img +one of the following must be specified as thesecurity option: + security_model=passthrough + security_model=mapped +Segmentation fault + +Patch is attached. Also attached is a patch that addes the space between 'the' and 'security' in 'thesecurity'. + +Does not affect trunk. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/681613 b/results/classifier/gemma3:12b/files/681613 new file mode 100644 index 00000000..6a8cad75 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/682326 b/results/classifier/gemma3:12b/files/682326 new file mode 100644 index 00000000..dd9b4dec --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/688 b/results/classifier/gemma3:12b/files/688 new file mode 100644 index 00000000..6e74f650 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/712 b/results/classifier/gemma3:12b/files/712 new file mode 100644 index 00000000..b95a9899 --- /dev/null +++ b/results/classifier/gemma3:12b/files/712 @@ -0,0 +1,15 @@ + +Build fails if build directory name includes a comma +Description of problem: +Builds fail if the build directory name contains a comma. +Steps to reproduce: +1. `mkdir build,demo && cd build,demo` +2. `../configure && make` + +The linker fails because it uses a wrong build path (comma and trailing part of directory name is missing): + +``` +ld: can't read -exported_symbols_list file: /Users/stefan/src/gitlab/qemu-project/qemu/build +clang: error: linker command failed with exit code 1 (use -v to see invocation) +ninja: build stopped: subcommand failed. +``` diff --git a/results/classifier/gemma3:12b/files/712337 b/results/classifier/gemma3:12b/files/712337 new file mode 100644 index 00000000..bee7638b --- /dev/null +++ b/results/classifier/gemma3:12b/files/712337 @@ -0,0 +1,43 @@ + +connecthon basic test5 failed with qemu 0.14 on Virtfs path in guest + +connecthon basic test named test5 is failing with bigfile write failed bad address on .L passthru and .L mapped Virtfs path in guest. with fedora12 + +Bug is with latest qemu-0.14.0-rc0 + +connecthon tarball /root/project_CI/client/tests/connecthon/cthon04.tgz +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| [stderr] ./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| Test failed: Command <./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55> failed, rc=1, Command returned non-zero exit status +02/03 08:55:09 INFO |kvm_subpro:0880| * Command: +02/03 08:55:09 INFO |kvm_subpro:0880| ./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55 +02/03 08:55:09 INFO |kvm_subpro:0880| Exit status: 1 +02/03 08:55:09 INFO |kvm_subpro:0880| Duration: 0 +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| stdout: +02/03 08:55:09 INFO |kvm_subpro:0880| ... Pass 1 ... +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| Starting BASIC tests: test directory /root/mount3/test2011-02-0311:55 (arg: -t) +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test1: File and directory creation test +02/03 08:55:09 INFO |kvm_subpro:0880| created 155 files 62 directories 5 levels deep in 0.6 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test1 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test2: File and directory removal test +02/03 08:55:09 INFO |kvm_subpro:0880| removed 155 files 62 directories 5 levels deep in 0.4 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test2 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test3: lookups across mount point +02/03 08:55:09 INFO |kvm_subpro:0880| 500 getcwd and stat calls in 0.0 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test3 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test4: setattr, getattr, and lookup +02/03 08:55:09 INFO |kvm_subpro:0880| 1000 chmods and stats on 10 files in 0.24 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test4 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test5: read and write +02/03 08:55:09 INFO |kvm_subpro:0880| basic tests failed +02/03 08:55:09 INFO |kvm_subpro:0880| stderr: +02/03 08:55:09 INFO |kvm_subpro:0880| ./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 INFO | Test finished after 1 iterations. +02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 ERROR| child process failed +02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 INFO | FAIL connecthon.itera-pass-dotl-100-test-bt connecthon.itera-pass-dotl-100-test-bt timestamp=1296752109 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/721825 b/results/classifier/gemma3:12b/files/721825 new file mode 100644 index 00000000..d30b66c3 --- /dev/null +++ b/results/classifier/gemma3:12b/files/721825 @@ -0,0 +1,77 @@ + +VDI block driver bugs + +Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14: + +"Bug 1. The most serious bug is caused by race condition in updating a new +bmap entry in memory and on disk. Considering the following operation +sequence. + O1: VM issues a write to sector X + O2: VDI allocates a new bmap entry and updates in-memory s->bmap + O3: VDI writes data to disk + O4: The disk I/O for writing sector X fails + O5: VDI reports error to VM and returns. + +Note that the bmap entry is updated in memory, but not persisted on disk. +Now consider another write that immediately follows: + P1: VM issues a write to sector X+1, which locates in the same block as +the previously used sector X. + P2: s->bmap already has one entry for the block, and hence VDI writes +data directly without persisting the new s->bmap entry on disk. + P3: The write disk I/O succeeds + P4: VDI report success to VM, but the bitmap entry is still not +persisted on disk. + +Now suppose the VM powers off gracefully (i.e., the QEMU process quits) +and reboots. The second write to sector X+1, which is reported as finished +successfully, is simply lost, because the corresponding in-memory s->bmap +entry is never persisted on disk. This is exactly what FVD's testing tool +discovers. After the block device is closed and then re-opened, disk +content verification fails. + +This is just one example of the problem. Race condition plus host crash +also causes problems. Consider another example below. + Q1: VM issues a write to sector X + Q2: VDI allocates a new bmap entry and updates in-memory s->bmap + Q3: VDI writes sector X to disk and waits for the callback + Q4: VM issues a write to another sector X+1, which is in the same block +as sector X. + Q5: VDI sees the bitmap entry in s->bmap is already allocated, and +writes sector X+1 to disk. + Q6: Write to sector X+1 finishes, and VDI's callback is invoked. + Q7: VDI acknowledges to the VM the completion of writing sector X+1 + Q8: After observing the completion of writing sector X+1, VM issues a +flush to ensure that sector X+1 is persisted on disk. + Q9: VDI finishes the flush and acknowledge the completion of the +operation. + Q10: ... (some other arbitrary operations, but the disk I/O for writing +sector X is still not finished....) + Q11: The host crashes + +Now the new bitmap entry is not persisted on disk, while both writing to +sector X+1 and the flush has been acknowledged as finished. Sector X+1 is +lost, which is a corruption. This problem exists even if it uses O_DSYNC. +The root cause of the problem is that, if a request updates in-memory +s->bmap, another request that sees this update assumes that the update is +already persisted on disk, which is not. + +Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are +several cases of the code below on failure handling path without setting +error return code, which mistakenly reports failure as success. This +mistake is caught by FVD when doing image content validation. + if (acb->hd_aiocb == NULL) { + /* missing ret = -EIO; */ + goto done; + } + +Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, +vdi_aio_cancel does not perform a complete clean up and there are several +related bugs. First, memory buffer is not freed, acb->orig_buf and +acb->block_buffer. Second, acb->bh is not cancelled. Third, +vdi_aio_setup() does not initialize acb->bh to NULL so that when a request +acb is cancelled and then later reused for another request, its acb->bh != +NULL and the new request fails in vdi_schedule_bh(). This is caught by +FVD's testing tool, when it observes that no I/O failure is injected but +VDI reports a failed I/O request, which indicates a bug in the driver." + +http://permalink.gmane.org/gmane.comp.emulators.qemu/94340 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/726619 b/results/classifier/gemma3:12b/files/726619 new file mode 100644 index 00000000..8ff39576 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/727 b/results/classifier/gemma3:12b/files/727 new file mode 100644 index 00000000..d4846b10 --- /dev/null +++ b/results/classifier/gemma3:12b/files/727 @@ -0,0 +1,157 @@ + +VHDX is corrupted on expansion +Description of problem: +Fresh VHDX corrupts with data loss upon copying data into it. +Steps to reproduce: +1. Create new dynamic vhdx file of about 93Gib (unexpanded, starting size is small ~205Mib, freshly created and NTFS formatted in windows.) +2. Connect drive using qemu-nbd to /dev/nbd0 +3. Ensure partition using gdisk +4. format partition with ntfs/ExFAT volume +5. mount volume +6. copy/rsync data of about 85Gib of data into the mounted volume +7. unmount volume +8. disconnect /dev/nbd0 +9. reconnect /dev/nbd0 +10. attempt mount, sometimes mount may fail if corrupted +11. If mount succeeds, verify data/all-files using some method like sha256sum. Some data is likely to fail + +Given the amount of data I am rsync-ing into the volume, there is very high chance of corruption. + +The corruption is not apparent until **disconnection and reconnection** of virtual-disk. Simply unmounting and remounting without disconnecting is unlikely to cause one to suspect corruption. + +If the expanded corrupted volume is again disconnected, reconnected, reformatted and data is again re-copied onto it, then the volume is less likely to experience a corruption, perhaps because new block allocation is not required. + +Errors vary and include: +- sometimes mount fails +- sometimes ls -l output is garbled +- sometimes one cannot cd into a directory +- several consecutive errors in shasum256 start midway through the file-list processing. Error is shown as if rsync failed and files do not exist. + ``` + sha256sum: ./201207/IMG_2406.JPG: No such file or directory + ./201207/IMG_2406.JPG: FAILED open or read + ``` +- Doing chdsk on windows may just create FOUND.000/FILE0000.CHK files. +Additional information: +See comment https://gitlab.com/qemu-project/qemu/-/issues/136#note_731044761 from where this all began. Some summary included here. + +``` +[root@sirius a16]# uname -a +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux + +[root@sirius ~]# qemu-system-x86_64 --version +QEMU emulator version 6.1.0 (qemu-6.1.0-10.fc35) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +[root@sirius ~]# cat /etc/mtab | grep -E "a16|a17" | grep ntfs3 +/dev/sda16 /mnt/a16 ExFAT rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0 +/dev/sda17 /mnt/a17 ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0 + +[root@sirius ~]# uname -a # self-built rpmbuild kernel from fedora rawhide kernel-src rpm +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux +``` + +Test/Activity being done: About 85Gib of data is copied onto a size 93Gib VHDX on host-FS ntfs3 with guest-FS ntfs3. +``` +Prefer windows method: Inside windows-10, using powershell command New-VHD, one may a 93Gib VHDX + New-VHD -Path I:\gkpics01.vhdx -SizeBytes 99723771904 -Dynamic + Then attach disk and format volume inside to ntfs. +or Alternatively, Linux method (less preferred) + qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 + qemu-img create -f vhdx -o subformat=dynamic /mnt/a16/gkpics01.vhdx 99723771904 +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +create appropriate partitions on /dev/nbd0 if not already partitioned +gdisk /dev/nbd0 +: +format volume with filesystem ntfs, or ext4 etc if not already formatted +mkfs -t ntfs -Q -L fs_gkpics01 /dev/nbd0p2 +: +mount partition +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do copy/rsync etc +( fl="photos001" ; src="/mnt/c13" ; dst="/mnt/t1" ; cd "$src" ;rsync -avH "$fl" "$dst" ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" ) +: +sync ; sleep 1 ; umount /mnt/t1 +: +sync ; sleep 1 ; blockdev --flushbufs /dev/nbd0 ; sleep 2 ; qemu-nbd -d /dev/nbd0 ; sleep 1 ; sync +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do ls-l/verify/sha256sum-c etc +( fl="photos001" ; rtpt="/mnt/t1" ; cd "${rtpt}/${fl}" ; sdate=`date` ; echo "$sdate" ; sha256sum -c "$rtpt/$fl/find.CHECKSUM" --quiet ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "checksum $src/$fl" ) +``` + +In the below list detailing under what circumstance corruption occurs + +- Format: kernel-version/ disk-attaching-sw/ hostFS/ VDISK/ guestFS with any parameters in parenthesis. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ext4 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=direct)/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=libvirt-7.6.0-3)/ntfs3/VHDX/ntfs3 +- Corruption does happen on host-FS **ExFAT too** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.0.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX/ntfs3g-fuseblk +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX(created by qemu-img)/ntfs3g-fuseblk + ``` Failed to mount '/dev/nbd0p2': Input/output error NTFS is either inconsistent, or there is a hardware fault,``` +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ext4 +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ntfs3g-fuseblk +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=threads)/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=io_uring)/ntfs3 +- VHDX fixed disk grows in size. Filed as different bug: https://gitlab.com/qemu-project/qemu/-/issues/806 + - Corruption **does happen** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(fixed)/ntfs3 + A fixed vhdx disk should not grow in size. It is as if the blocks are added to a vhdx-journal instead of overwriting preallocated blocks. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ext4/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-6.2.0-rc1**/ExFAT/VHDX/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VMDK**(v4,monolithicSparse)/ntfs3 +- Corruption does not happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/VMDK(compat6,monolithicSparse)/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VDI**/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VPC**(dynamic)/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-5.2.0-8**/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-4.2.1-1**/ExFAT/VHDX/ntfs3 +- Corruption does happen with vhdx-file is on 2Tb NTFS 1Tb partition of **external USB HDD** 2Tb, with kernel-5.15.2-200/qemu-6.2.0-rc1/ntfs3/VHDX/ntfs3 +- Corruption does happen when using src is on ntfs3 partition on external USB drive, which is **generated synthetic data (sgdata)** sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX/ntfs3 +- Corruption does happen when starting with qemu-img created vhdx image with sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX(created by qemu-img)/ext4 superblock mount fail +- Corruption does happen older fc34-kernel on Fedora-35, sgdata/kernel-5.13.19-200/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , different, fewer files 3 small files affected +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , fewer files, different, but same as above 3 small files affected, +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ext4 +- Corruption does happen with self-built 5.10 LTS kernel on Fedora-35, sgdata/kernel-5.10.90-200/qemu-6.2.0-1/ExFAT/VHDX/ext4 (sgdata accessed using ntfs-fuseblk) +- As the host kernel invoking qemu-nbd, these kernels showed less errors than if they were run inside a VM as a guest. If run as a guest VM, These kernels, 5.15.4 and above, may also have kernel bugs https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 resulting in additional compounded errors in the failure test results, even in raw-img and qcow2(fixed). + - Corruption does happen with sgdata/kernel-5.15.4-201/qemu-6.2.0-rc1/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.4-201/**qemu-6.2.0-rc2**/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with synthetic-data sgdata/kernel-5.15.4-201/qemu-6.2.0-rc2/ExFAT/VMDK(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.5-200/qemu-6.2.0-rc2/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/vmdk/ntfs3 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin/ExFAT/vmdk-nbd-vddkplugin/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.6-200 to kernel-5.15.13-200 /qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 +- On Windows-10, these tests may possibly be different bug. Also causes system-wide DiskIO stuck in addition to corruption https://github.com/cloudbase/wnbd/issues/63 + - Corruption does happen with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/VHDX/NTFS + - Corruption **does happen** with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/**qcow2**/NTFS +- Possibly different bug, on Windows-10, corruption of virtual-disk from inside VM, no nbd . Maybe https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/VHDX/ntfs3 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/**qcow2**/ext4 +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**qcow2(dyn)**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/qcow2(dyn)/ntfs3 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**VHDX**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/**Rocky-8.5-Workstation-20211114.iso**/**kernel-4.18.0-348.el8.0.2.x86_64**/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata + +ExFAT filesystem was considered because it does not have concept of sparse files eliminating that factor from troubleshooting. Furthermore, it may be incorrect to suspect NTFS3, ExFAT or NTFS3g-fuseblk only because they are new/recently mainstreamed filesystems, as there aren't any intense/complex filesystem operations. The filesystem is experiencing only though-put and files are simply copied into it without further operations. Furthermore, ext4 also experiences corruption if on VHDX. + +It just seems to me the VHDX support implementation has bugs, corrupts and hence is not reliable. + +The qemu test-suite needs test-cases added for testing for vhdx-stress and vhdx-throughput . + +More troubleshooting test results are summarized in https://gitlab.com/qemu-project/qemu/-/issues/727#note_745711084 + +Chief suspect files +- ~~kernel: nbd: [drivers/block/nbd.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/nbd.c)~~ can be made to happen via VM +- ~~kernel: ntfs3~~ no ntfs3 partition required +- ~~kernel 5.x series~~ bug exists in 4.18.0.348 +- ~~qemu: block~~ doesn't happen to other virtual-disk formats (raw,qcow2) +- qemu/VM : seems to happen only when using qemu-nbd or inside qemu-VM +- qemu: [block/vhdx.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.c) , [block/vhdx_log.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-log.c) , [block/vhdx-endian.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-endian.c) , [block/vhdx.h](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.h), diff --git a/results/classifier/gemma3:12b/files/728 b/results/classifier/gemma3:12b/files/728 new file mode 100644 index 00000000..df8a39ce --- /dev/null +++ b/results/classifier/gemma3:12b/files/728 @@ -0,0 +1,17 @@ + +Catch up to latest VHDX v2(=0x01) rev-7.0 specification +Additional information: +Below issues need to be addressed before or during the tackling of this issue. +- ~#727 VHDX is corrupted on expansion.~ +- #136 windows qemu-img create vpc/vhdx error due to sparse files +- #1605 On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts +- +This VHDX support applies to qemu build on any architecture, not just the windows-build. + +It is very likely, that the native hypervisor on windows WHPX will be the main hypervisor displacing haxm/vbox etc. VHDX, if it works, seems to be the virtual-disk format that is ideal +- for Linux/windows dual-boot machines, +- for clusters with Linux/windows servers sharing images from a network-storage +- for WSL2/Hyper-V + +Following a similar line of thought, NTFS/ExFat may be ideal for sharing data/images between Linux and Windows. So the storing, modification and drive attachment of VHDX files on these filesystems need to be just as well-tested as native Linux filesystems. As their driver are internal-kernel-drivers and not fuse/dokan-drivers, on both operating-systems, they are also performant. diff --git a/results/classifier/gemma3:12b/files/739 b/results/classifier/gemma3:12b/files/739 new file mode 100644 index 00000000..8ed611db --- /dev/null +++ b/results/classifier/gemma3:12b/files/739 @@ -0,0 +1,18 @@ + +qemu option -snapshot not work for blockdev disk +Description of problem: +If disk image configured with a -blockdev option, option -snapshot not work: all changes write to disk image instead of temporary files. +Steps to reproduce: +1. Run qemu guest with -blockdev disk image file and -snapshot options +2. Create file test.txt on guest disk +3. Power off guest +4. Run qemu guest again +5. File test.txt present on guest disk +Additional information: +When i replace -blockdev options to legacy -drive option +``` +-snapshot +-drive if=none,id=ssd1-format,media=disk,cache=none,aio=native,discard=unmap,detect-zeroes=unmap,format=qcow2,file=images/windows21h2.qcow2 +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=ssd1-format,id=scsi0-0-0-0,write-cache=on,bootindex=1 +``` +-snapshot option work fine diff --git a/results/classifier/gemma3:12b/files/753 b/results/classifier/gemma3:12b/files/753 new file mode 100644 index 00000000..2019720b --- /dev/null +++ b/results/classifier/gemma3:12b/files/753 @@ -0,0 +1,2 @@ + +qemu unable to convert file above 2 TB diff --git a/results/classifier/gemma3:12b/files/779151 b/results/classifier/gemma3:12b/files/779151 new file mode 100644 index 00000000..aff3771b --- /dev/null +++ b/results/classifier/gemma3:12b/files/779151 @@ -0,0 +1,17 @@ + +qemu-nbd crash during using with chroot + +I use qemu-nbd to mount my image. And after some times, qemu-nbd crashes and so the chroot freeze. + +ps aux | grep qemu : +root 2223 0.0 0.0 9776 548 ? Ss 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2224 0.0 0.0 10800 544 ? D 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2227 0.0 0.0 0 0 ? Z 18:03 0:00 [qemu-nbd] <defunct> +root 2357 0.0 0.0 5212 768 pts/0 D+ 18:07 0:00 grep qemu + +mount : +/dev/nbd0p1 on /chroots/test/amd64 type ext3 (rw,errors=remount-ro,commit=0) +/dev on /chroots/test/amd64/dev type devtmpfs (rw,mode=0755) +/dev/pts on /chroots/test/amd64/dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) +/proc on /chroots/test/amd64/proc type proc (rw) +/sys on /chroots/test/amd64/sys type sysfs (rw,noexec,nosuid,nodev) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/784977 b/results/classifier/gemma3:12b/files/784977 new file mode 100644 index 00000000..5829348e --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/786440 b/results/classifier/gemma3:12b/files/786440 new file mode 100644 index 00000000..6030034e --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/805 b/results/classifier/gemma3:12b/files/805 new file mode 100644 index 00000000..1d974e16 --- /dev/null +++ b/results/classifier/gemma3:12b/files/805 @@ -0,0 +1,15 @@ + +qemu-hexagon: [binary]: Error mapping file: Invalid argument +Description of problem: +Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error: +`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument` +Steps to reproduce: +``` +./qemu-hexagon <hexagon-binary> +qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument +``` +Additional information: +A similar problem has been reported on the mailing list: +https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html + +Unfortunately without a solution. diff --git a/results/classifier/gemma3:12b/files/806 b/results/classifier/gemma3:12b/files/806 new file mode 100644 index 00000000..fa99f345 --- /dev/null +++ b/results/classifier/gemma3:12b/files/806 @@ -0,0 +1,64 @@ + +Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts +Description of problem: +Fixed VHDX inflates beyond its fixed size when data is copied onto it +Possibly also corrupted + +Filing this bug as separate from #727, that issue is for corruption during expansion of a dynamic disk. +The effect seen here is different. There may or may not be a chance of common cause. New blocks should not have to be allocated to the VHDX spec Block-Allocation-Table (BAT), there may be a simpler and different fix for this issue. + +Perhaps blocks are written to a VHDX journal without being committed to allocated blocks. +Perhaps the host's ExFAT filesystem, does not allow reclaiming the blocks that are to be replaced by punching holes and so must be over-written instead of punching holes. +Steps to reproduce: +1. Prepare virtual-disk1 + Create fixed vhdx + ``` + [root@sirius gana]# qemu-img create -f vhdx /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904 + Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed``` +2. Prepare virtual-disk2 + Put 85 GiB synthetic generated data sgdata as mentioned in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 +3. Start qemu (command invocation given above) +4. Partition /dev/sda, put ext4-fs on /dev/sda1 +5. Mount -t ext4 /dev/sda1 /mnt/a +6. Mount /dev/sdb2 /mnt/b (mounts using fuse-blk tuxera ntfs driver) +7. Do rsync: + ``` + (sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date) + ``` +8. In a host terminal, do ls -l on the vhdx file, and observe that it grows in size (see logs below) +Additional information: +* virtual-disk-1 (<90 GiB) is on ExFAT partition (150 GiB) on SSD +* virtual-disk-2 (~85 Gib) is on NTFS3 partition (1 TiB) on HDD + + +``` +[root@sirius gana]# qemu-img create -f vhdx /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904 +Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 99765714944 Jan 8 13:35 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx + +do gdisk and partition in guestvm +-rwxr-xr-x. 1 root root 100705239040 Jan 8 13:36 /mnt/a16/gkpics01.vhdx + +do mkfs -t ext4 in guestvm +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 101342773248 Jan 8 13:36 /mnt/a16/gkpics01.vhdx + +start rsyncing data in guestvm +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 102097747968 Jan 8 13:38 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 102215188480 Jan 8 13:38 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 149375942656 Jan 8 13:50 /mnt/a16/gkpics01.vhdx +[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx +-rwxr-xr-x. 1 root root 156170715136 Jan 8 13:58 /mnt/a16/gkpics01.vhdx +``` +in my case partition fills up and not completed. diff --git a/results/classifier/gemma3:12b/files/808737 b/results/classifier/gemma3:12b/files/808737 new file mode 100644 index 00000000..57388b80 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/81 b/results/classifier/gemma3:12b/files/81 new file mode 100644 index 00000000..8a0bae6c --- /dev/null +++ b/results/classifier/gemma3:12b/files/81 @@ -0,0 +1,2 @@ + +[Feature request] qemu-img option about recompressing diff --git a/results/classifier/gemma3:12b/files/813 b/results/classifier/gemma3:12b/files/813 new file mode 100644 index 00000000..cdab1e19 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/814 b/results/classifier/gemma3:12b/files/814 new file mode 100644 index 00000000..063b7063 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/816860 b/results/classifier/gemma3:12b/files/816860 new file mode 100644 index 00000000..ef8bb504 --- /dev/null +++ b/results/classifier/gemma3:12b/files/816860 @@ -0,0 +1,8 @@ + +Guest machine freezes when NFS mount goes offline + +I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device. + +Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +Guest: Windows 7 professional SP 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/829 b/results/classifier/gemma3:12b/files/829 new file mode 100644 index 00000000..d80c5e9c --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/832 b/results/classifier/gemma3:12b/files/832 new file mode 100644 index 00000000..2410f53d --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/841 b/results/classifier/gemma3:12b/files/841 new file mode 100644 index 00000000..ca02a8c5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/841 @@ -0,0 +1,79 @@ + +SIGSEGV in memcpy in v9fs_co_readdir_many +Description of problem: +When running btrfs tests in vm (using `virtme`-like setup with 9pfs) occasionally qemu crashes with (`coredumpctl info` output): +``` +... +Message: Process 1764494 (qemu-system-x86) of user 502 dumped core. +Stack trace of thread 1764817: + #0 0x00005555559ebeed v9fs_co_readdir_many (/usr/bin/qemu-system-x86_64 + 0x497eed) + #1 0x00005555559ec2e9 v9fs_readdir (/usr/bin/qemu-system-x86_64 + 0x4982e9) + #2 0x0000555555eb7983 coroutine_trampoline (/usr/bin/qemu-system-x86_64 + 0x963983) + #3 0x00007ffff73e0be0 n/a (n/a + 0x0) +``` +Additional information: +coredumpctl debug: +``` +Failed to read a valid object file image from memory. +Core was generated by `qemu-system-x86_64 -enable-kvm -m 40270M -smp cores=20 -nodefaults -nographic -'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00005555559ebeed in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>, + __len=<optimized out>) at /usr/include/bits/string_fortified.h:29 +29 return __builtin___memcpy_chk (__dest, __src, __len, +[Current thread is 1 (LWP 1764817)] +(gdb) list ../hw/9pfs/codir.c:147 +142 *entries = e = g_malloc0(sizeof(V9fsDirEnt)); +143 } else { +144 e = e->next = g_malloc0(sizeof(V9fsDirEnt)); +145 } +146 e->dent = g_malloc0(sizeof(struct dirent)); +147 memcpy(e->dent, dent, sizeof(struct dirent)); +148 +149 /* perform a full stat() for directory entry if requested by caller */ +150 if (dostat) { +151 err = s->ops->name_to_path( +(gdb) bt +#0 0x00005555559ebeed in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>, + __len=<optimized out>) at /usr/include/bits/string_fortified.h:29 +#1 do_readdir_many (dostat=<optimized out>, maxsize=<optimized out>, offset=<optimized out>, entries=<optimized out>, fidp=<optimized out>, + pdu=0x555557353500) at ../hw/9pfs/codir.c:147 +#2 v9fs_co_readdir_many (pdu=pdu@entry=0x555557353500, fidp=fidp@entry=0x555556cdd280, entries=entries@entry=0x7ff5bf7f7f58, offset=<optimized out>, + maxsize=<optimized out>, dostat=<optimized out>) at ../hw/9pfs/codir.c:226 +#3 0x00005555559ec2e9 in v9fs_do_readdir (max_count=<optimized out>, offset=<optimized out>, fidp=0x555556cdd280, pdu=0x555557353500) at ../hw/9pfs/9p.c:2430 +#4 v9fs_readdir (opaque=0x555557353500) at ../hw/9pfs/9p.c:2543 +#5 0x0000555555eb7983 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ../util/coroutine-ucontext.c:173 +#6 0x00007ffff73e0be0 in ?? () +#7 0x00007fffffffd480 in ?? () +#8 0x0000000000000000 in ?? () +(gdb) x/11i 0x00005555559ebeed - 27 + 0x5555559ebed2 <v9fs_co_readdir_many+530>: call 0x555555928480 <g_malloc0@plt> + 0x5555559ebed7 <v9fs_co_readdir_many+535>: mov %rbp,%rsi + 0x5555559ebeda <v9fs_co_readdir_many+538>: mov %rax,(%r12) + 0x5555559ebede <v9fs_co_readdir_many+542>: mov 0x0(%rbp),%rdx + 0x5555559ebee2 <v9fs_co_readdir_many+546>: lea 0x8(%rax),%rdi + 0x5555559ebee6 <v9fs_co_readdir_many+550>: and $0xfffffffffffffff8,%rdi + 0x5555559ebeea <v9fs_co_readdir_many+554>: mov %rdx,(%rax) +=> 0x5555559ebeed <v9fs_co_readdir_many+557>: mov 0x110(%rbp),%rdx + 0x5555559ebef4 <v9fs_co_readdir_many+564>: mov %rdx,0x110(%rax) + 0x5555559ebefb <v9fs_co_readdir_many+571>: sub %rdi,%rax + 0x5555559ebefe <v9fs_co_readdir_many+574>: sub %rax,%rsi +(gdb) i r rdx rax rip +rdx 0x29287d 2697341 +rax 0x7ff4bc12ccf0 140689104096496 +rip 0x5555559ebeed 0x5555559ebeed <v9fs_co_readdir_many+557> +(gdb) x/11x 0x7ff4bc12ccf0 +0x7ff4bc12ccf0: 0x0029287d 0x00000000 0x00000000 0x00000000 +0x7ff4bc12cd00: 0x00000000 0x00000000 0x00000000 0x00000000 +0x7ff4bc12cd10: 0x00000000 0x00000000 0x00000000 +(gdb) frame 1 +#1 do_readdir_many (dostat=<optimized out>, maxsize=<optimized out>, offset=<optimized out>, entries=<optimized out>, fidp=<optimized out>, + pdu=0x555557353500) at ../hw/9pfs/codir.c:147 +147 memcpy(e->dent, dent, sizeof(struct dirent)); +(gdb) p e +$3 = (struct V9fsDirEnt *) 0x7ff4bc12caa0 +(gdb) p e->dent +$4 = (struct dirent *) 0x7ff4bc12ccf0 +(gdb) p dent +$5 = (struct dirent *) 0x7ff4ec04cef0 + +``` diff --git a/results/classifier/gemma3:12b/files/843 b/results/classifier/gemma3:12b/files/843 new file mode 100644 index 00000000..b5af6ad5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/843 @@ -0,0 +1,4 @@ + +qemu-binfmt-conf causes duplicate magic mips headers when installing all patterns +Description of problem: +The magic/mask patterns are the same for mips[el] and nipsn32[el] diff --git a/results/classifier/gemma3:12b/files/848 b/results/classifier/gemma3:12b/files/848 new file mode 100644 index 00000000..802ac27a --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/851 b/results/classifier/gemma3:12b/files/851 new file mode 100644 index 00000000..8bd2d9d5 --- /dev/null +++ b/results/classifier/gemma3:12b/files/851 @@ -0,0 +1,234 @@ + +qemu-img create results in tsan warnings +Description of problem: +Running qemu-img w/ tsan enabled results in a bunch of data races reported: + +``` +Formatting 'delta.img', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=0 backing_file=base.img backing_fmt=raw lazy_refcounts=off refcount_bits=16 +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Atomic write of size 8 at 0x7b4800000228 by main thread: + #0 __tsan_atomic64_exchange <null> (qemu-img+0xb6a55) + #1 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:151:5 (qemu-img+0x239931) + #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Previous read of size 8 at 0x7b4800000228 by thread T5 (mutexes: write M42): + #0 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:82:9 (qemu-img+0x239c4c) + #1 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c4c) + #2 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c) + #3 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Location is heap block of size 336 at 0x7b4800000180 allocated by main thread: + #0 calloc <null> (qemu-img+0x68ff9) + #1 g_malloc0 <null> (libglib-2.0.so.0+0x59e70) + #2 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47) + #3 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb6a55) in __tsan_atomic64_exchange +================== +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Write of size 4 at 0x7b1c000005f0 by thread T5 (mutexes: write M42): + #0 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 (qemu-img+0x24fde3) + #1 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Previous read of size 4 at 0x7b1c000005f0 by main thread (mutexes: write M19): + #0 thread_pool_completion_bh /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:170:19 (qemu-img+0x24f7ae) + #1 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #2 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #3 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #4 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #5 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #6 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #7 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Location is heap block of size 104 at 0x7b1c000005b0 allocated by thread T4: + #0 malloc <null> (qemu-img+0x68e0d) + #1 g_malloc <null> (libglib-2.0.so.0+0x59e18) + #2 thread_pool_submit_aio /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:249:11 (qemu-img+0x24edc8) + #3 thread_pool_submit_co /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:287:5 (qemu-img+0x24f0fe) + #4 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2046:12 (qemu-img+0x1b5334) + #5 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b5334) + #6 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2562:14 (qemu-img+0x1b5334) + #7 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #8 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #9 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #10 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #11 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #12 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #13 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #14 <null> <null> (libc.so.6+0x51a2f) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Mutex M19 (0x7b48000001e0) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_rec_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:120:11 (qemu-img+0x224625) + #2 aio_context_new /usr/local/google/home/pefoley/qemu/build/../util/async.c:555:5 (qemu-img+0x23a226) + #3 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47) + #4 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Thread T4 (tid=0, running) created by main thread at: + #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead) + #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead) + #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 in worker_thread +================== +================== +WARNING: ThreadSanitizer: data race (pid=217825) + Atomic write of size 4 at 0x7b0c000000e8 by thread T5 (mutexes: write M42): + #0 __tsan_atomic32_fetch_or <null> (qemu-img+0xb9ec1) + #1 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:80:17 (qemu-img+0x239c23) + #2 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c23) + #3 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c) + #4 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960) + + Previous read of size 4 at 0x7b0c000000e8 by main thread: + #0 aio_compute_bh_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:209:18 (qemu-img+0x239e7f) + #1 aio_compute_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:232:15 (qemu-img+0x239e7f) + #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:624:26 (qemu-img+0x21f9c2) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Location is heap block of size 48 at 0x7b0c000000c0 allocated by thread T4: + #0 malloc <null> (qemu-img+0x68e0d) + #1 g_malloc <null> (libglib-2.0.so.0+0x59e18) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:305:27 (qemu-img+0x24f235) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f235) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Mutex M42 (0x7b3800000010) created at: + #0 pthread_mutex_init <null> (qemu-img+0x6bc0f) + #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69) + #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d) + #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d) + #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4) + #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7) + #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7) + #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7) + #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678) + #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5) + #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5) + #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d) + #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63) + #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975) + #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008) + #15 <null> <null> (libc.so.6+0x51a2f) + + Thread T5 'worker' (tid=217829, running) created by main thread at: + #0 pthread_create <null> (qemu-img+0x6a49d) + #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800) + #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3) + #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3) + #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96) + #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96) + #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822) + #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1) + #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + + Thread T4 (tid=0, running) created by main thread at: + #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead) + #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead) + #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be) + #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884) + #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b) + #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad) + #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3) + +SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb9ec1) in __tsan_atomic32_fetch_or +================== +ThreadSanitizer: reported 3 warnings +``` +Steps to reproduce: +1. ./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++ +2. make -j12 +3. touch base.img +4. build/qemu-img create -b base.img -f qcow2 -F raw delta.img + +./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++ +touch base.img +build/qemu-img create -b base.img -f qcow2 -F raw delta.img diff --git a/results/classifier/gemma3:12b/files/853 b/results/classifier/gemma3:12b/files/853 new file mode 100644 index 00000000..d61a5a50 --- /dev/null +++ b/results/classifier/gemma3:12b/files/853 @@ -0,0 +1,11 @@ + +Quaint English in qemu-options.hx +Description of problem: +qemu-options.hx contains grammar that a native English-speaking person would never use. I had to read a sentence in that file very slowly and more than once to understand it. +Steps to reproduce: +1. Install QEMU +2. Run a command to display documentation that includes qemu-options.hx for instance "man qemu-system-x86_64" +3. Observe "This option defines where is connected the drive ..." +4. Scratch head, figure out that "This option defines where the drive is connected ..." is the meaning. +Additional information: +It is very difficult to report QEMU documentation bugs. diff --git a/results/classifier/gemma3:12b/files/888150 b/results/classifier/gemma3:12b/files/888150 new file mode 100644 index 00000000..7571c2e3 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/892 b/results/classifier/gemma3:12b/files/892 new file mode 100644 index 00000000..38fde2d4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/892 @@ -0,0 +1,6 @@ + +Ensure qemu-storage-daemon builds, works and is included in win10 setup +Additional information: +- Job run on 20220315 "msys2-64bit build target" seems to have created binary: https://gitlab.com/qemu-project/qemu/-/jobs/2201739711 + - ```2456 [1324/1586] Linking target storage-daemon/qemu-storage-daemon.exe``` + - I hope it will be included in final distributed setup files diff --git a/results/classifier/gemma3:12b/files/893956 b/results/classifier/gemma3:12b/files/893956 new file mode 100644 index 00000000..dcfacd77 --- /dev/null +++ b/results/classifier/gemma3:12b/files/893956 @@ -0,0 +1,16 @@ + +qemu-img bug with dynamic vhd + +Hye, i found a problem with qemu-img when trying to get info of a dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd. The dynamic vhd is 21gb size. + +With 1.0-rc3 version : +running command: qemu-img info 60_GB.VHD +qemu-img: Could not open '60_GB.VHD' : File too large + +0.14.1 version give me wrong information : +image: 60_GB.VHD +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 21G + +Thanks for reply. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/906 b/results/classifier/gemma3:12b/files/906 new file mode 100644 index 00000000..4ea14f81 --- /dev/null +++ b/results/classifier/gemma3:12b/files/906 @@ -0,0 +1,2 @@ + +Cannot IPL this ISO image diff --git a/results/classifier/gemma3:12b/files/907 b/results/classifier/gemma3:12b/files/907 new file mode 100644 index 00000000..04b872e3 --- /dev/null +++ b/results/classifier/gemma3:12b/files/907 @@ -0,0 +1,8 @@ + +qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file +Steps to reproduce: +1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true + +The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file: +Additional information: +This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0 diff --git a/results/classifier/gemma3:12b/files/907063 b/results/classifier/gemma3:12b/files/907063 new file mode 100644 index 00000000..2d005bd2 --- /dev/null +++ b/results/classifier/gemma3:12b/files/907063 @@ -0,0 +1,11 @@ + +Error reading VMDK4 with footer instead of header + +VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. + +I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. + +bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :( + +I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/909 b/results/classifier/gemma3:12b/files/909 new file mode 100644 index 00000000..7cb4ede9 --- /dev/null +++ b/results/classifier/gemma3:12b/files/909 @@ -0,0 +1,12 @@ + +qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries +Description of problem: +**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** + +Trying to chroot into a mips n32 installation fails with +``` +/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data +``` +however, bash, libc.so.6, and qemu all exist and have the proper abi + +The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/results/classifier/gemma3:12b/files/913 b/results/classifier/gemma3:12b/files/913 new file mode 100644 index 00000000..7d08003b --- /dev/null +++ b/results/classifier/gemma3:12b/files/913 @@ -0,0 +1,2 @@ + +QEMU Sharing Host files with Guest diff --git a/results/classifier/gemma3:12b/files/917824 b/results/classifier/gemma3:12b/files/917824 new file mode 100644 index 00000000..0da0ed63 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/927 b/results/classifier/gemma3:12b/files/927 new file mode 100644 index 00000000..4d771dff --- /dev/null +++ b/results/classifier/gemma3:12b/files/927 @@ -0,0 +1,33 @@ + +linux-user: openat on /proc/self/exe can return a closed file descriptor +Description of problem: +`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. + +When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. + +`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. +Steps to reproduce: +This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). + +```c +#include <fcntl.h> +#include <stdio.h> + +int main(int argc, char **argv) { + int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); + if (selfexe < 0) { + perror("open self"); + return 1; + } + + int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); + if (devnull < 0) { + perror("open devnull"); + return 1; + } + + printf("%d %d\n", selfexe, devnull); +} +``` +Additional information: +Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. diff --git a/results/classifier/gemma3:12b/files/937 b/results/classifier/gemma3:12b/files/937 new file mode 100644 index 00000000..ad92a336 --- /dev/null +++ b/results/classifier/gemma3:12b/files/937 @@ -0,0 +1,69 @@ + +I/O errors occur when qcow2 files created via gluster fuse mount are accessed via libgfapi (gluster://) +Description of problem: +Environment: a Gluster volume 'v0' (Gluster versions tested were 9.2-1 and 10.1) is built on 3 nodes on top of 3 ZFS pools. It is mounted to check fuse mount functionality. Mount point is `/mnt/gl`. +When an empty qcow2 is created via fuse mount (qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G) and then this qcow2 is attached to qemu guest -- error appears: +``` +qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Could not read L1 table: Input/output error +``` +When the same file is attached to qemu guest via fuse mount there is no error. When the same file is created via GFAPI (gluster://) there is no error too. +Steps to reproduce: +1. Create file via fuse-mount: `qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G` +2. Attach this file via gluster:// to qemu guest and observe an error +3. Attach this file via fuse mount, run a guest -- no error. +4. Create file via gluster:// : `qemu-img create -f qcow2 gluster://v0/234.qcow2 10g` +5. Attach this file (via GFAPI or via fuse mount) to qemu guest and run guest -- there is no error. +Additional information: +When an empty qcow2 file with virtual size 10G with default cluster size is created, its proper size is 196768 (0x300a0) bytes. If file is created via fuse mount, that is true and file size is 0x300a0 bytes. +In the end of file L1 table resides, its offset is 0x30000 and size is 0xa0. When this qcow2 is attached via fuse mount it seems that i/o requests are conforming to file size and file is read without errors. +But when file with size 0x300a0 is attached via gluster://, qemu aligns i/o requests by 0x200 bytes boundary (see dump below, frame #12. NB: dump is taken from qemu-img create cmd so there are write requests). Thus, request goes beyond the file end and read error occurs. + +When file is created via gluster:// its size is 197120 (0x30200) bytes because write requests are aligned to 512 bytes too. And guest runs normally with it regardless of connection type. + +``` +Thread 1 "qemu-img" hit Breakpoint 1, 0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so +(gdb) bt +#0 0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so +#1 0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0 +#2 0x00007ffff4024ab8 in gf_utime_writev (frame=0x555556126aa8, this=0x7fffe40113d8, fd=0x555556126b88, vector=0x555556130868, count=1, off=196608, flags=0, iobref=0x555556130608, xdata=0x0) at utime-autogen-fops.c:81 +#3 0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0 +#4 0x00007ffff4013c39 in ob_writev (frame=frame@entry=0x555556126aa8, this=0x7fffe4012408, fd=fd@entry=0x555556126b88, iov=iov@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0, + iobref=0x555556130608, xdata=0x0) at open-behind.c:584 +#5 0x00007fffdff37774 in mdc_writev (frame=frame@entry=0x5555561522d8, this=0x7fffe40139e8, fd=fd@entry=0x555556126b88, vector=vector@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0, + iobref=0x555556130608, xdata=0x0) at md-cache.c:2151 +#6 0x00007fffdff143fb in io_stats_writev (frame=0x55555611dc08, this=0x7fffe4015468, fd=0x555556126b88, vector=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at io-stats.c:2952 +#7 0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0 +#8 0x00007fffdfee88ca in meta_writev (frame=0x55555611dc08, this=0x7fffe40173d8, fd=0x555556126b88, iov=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at meta.c:131 +#9 0x00007ffff6942f22 in glfs_pwritev_async_common () from /lib64/libgfapi.so.0 +#10 0x00007ffff69462f6 in glfs_pwritev_async () from /lib64/libgfapi.so.0 +#11 0x00007ffff7fc5839 in qemu_gluster_co_writev () from /usr/lib64/qemu/block-gluster.so +#12 0x0000555555623b7e in bdrv_driver_pwritev (bs=bs@entry=0x55555611eda0, offset=offset@entry=196608, bytes=bytes@entry=512, qiov=qiov@entry=0x7ffff5e9cb40, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1243 +#13 0x00005555556244d2 in bdrv_aligned_pwritev (child=child@entry=0x55555611e3a0, req=req@entry=0x7ffff5e9ca80, offset=196608, bytes=512, align=align@entry=512, qiov=0x7ffff5e9cb40, qiov_offset=0, flags=0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2020 +#14 0x0000555555625433 in bdrv_co_pwritev_part (child=0x55555611e3a0, offset=<optimized out>, bytes=<optimized out>, qiov=<optimized out>, qiov_offset=<optimized out>, flags=0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2188 +#15 0x00005555556267a0 in bdrv_run_co (opaque=0x7ffff5e9cbb0, entry=0x5555556260a0 <bdrv_rw_co_entry>, bs=0x55555611eda0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915 +#16 bdrv_prwv_co (flags=0, is_write=true, qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:966 +#17 bdrv_pwritev (qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1048 +#18 bdrv_pwrite (bytes=160, buf=0x555556116000, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1070 +#19 bdrv_pwrite_sync (child=0x55555611e3a0, offset=offset@entry=196608, buf=buf@entry=0x555556116000, count=count@entry=160) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1084 +#20 0x00005555555f60de in qcow2_grow_l1_table (bs=bs@entry=0x55555610d0a0, min_size=min_size@entry=20, exact_size=exact_size@entry=true) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2-cluster.c:161 +#21 0x00005555555ec252 in qcow2_co_truncate (bs=0x55555610d0a0, offset=<optimized out>, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:4172 +#22 0x000055555562758d in bdrv_co_truncate (child=0x55555617b290, offset=10737418240, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3394 +#23 0x0000555555627a01 in bdrv_truncate_co_entry (opaque=0x7ffff5e9ceb0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3437 +#24 bdrv_run_co (opaque=0x7ffff5e9ceb0, entry=0x555555627980 <bdrv_truncate_co_entry>, bs=0x55555610d0a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915 +#25 bdrv_truncate (child=<optimized out>, offset=<optimized out>, exact=<optimized out>, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3453 +#26 0x0000555555611d32 in blk_truncate (blk=blk@entry=0x55555611e420, offset=<optimized out>, exact=exact@entry=false, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0) + at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/block-backend.c:2184 +#27 0x00005555555e9a0f in qcow2_co_create (create_options=0x55555612c000, errp=errp@entry=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3614 +#28 0x00005555555ea0ec in qcow2_co_create_opts (drv=<optimized out>, filename=<optimized out>, opts=0x5555557a3f90, errp=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3795 +#29 0x00005555555bd631 in bdrv_create_co_entry (opaque=0x7fffffffdff0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block.c:487 +#30 0x00005555556a7d8b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/util/coroutine-ucontext.c:173 +#31 0x00007ffff76a01c0 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 from /lib64/libc.so.6 +#32 0x00007fffffffd820 in ?? () +#33 0x0000000000000000 in ?? () +``` diff --git a/results/classifier/gemma3:12b/files/941 b/results/classifier/gemma3:12b/files/941 new file mode 100644 index 00000000..dbaff0f9 --- /dev/null +++ b/results/classifier/gemma3:12b/files/941 @@ -0,0 +1,42 @@ + +qemu-img cannot repair a qcow2 in an LV because size is mis-detected when qcow2 is on an LV +Description of problem: +This is RHEV with Tb's of VMs which need to be repaired due to a datacenter-wide (the real datacenter) power outage. + +Each of these VMs are on individual LVs but qemu-img check fails to perform repairs: + + +``` +ERROR cluster 24481205 refcount=0 reference=1 +ERROR cluster 24481206 refcount=0 reference=1 +Rebuilding refcount structure +ERROR writing refblock: No space left on device <============ +qemu-img: Check failed: No space left on device +``` + +Running qemu-img check or info on the LV (/dev/dm-*) works well but repairs cannot be completed: + +``` +# qemu-img info /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc +image: /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc +file format: qcow2 +virtual size: 1.5 TiB (1649267441664 bytes) +disk size: 0 B <================================ +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: true + refcount bits: 16 + corrupt: false + extended l2: false +``` +Steps to reproduce: +1. Have a damaged VM with its qcow2 in an LV +2. run 'qemu-img check <device>' verify that it properly detects the blocks which need fixing. +3. run 'qemu-img check -r all <device>', it exits with 'no space left on device´ after a few seconds. +Additional information: +https://bugzilla.redhat.com/show_bug.cgi?id=1519071 + + +Here is one example: diff --git a/results/classifier/gemma3:12b/files/943 b/results/classifier/gemma3:12b/files/943 new file mode 100644 index 00000000..5282de82 --- /dev/null +++ b/results/classifier/gemma3:12b/files/943 @@ -0,0 +1,2 @@ + +Calling get-fsinfo on a virtual machine does not include ZFS (zfsonlinux, debian guest tested) volumes diff --git a/results/classifier/gemma3:12b/files/944 b/results/classifier/gemma3:12b/files/944 new file mode 100644 index 00000000..42ec2ca2 --- /dev/null +++ b/results/classifier/gemma3:12b/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/gemma3:12b/files/946 b/results/classifier/gemma3:12b/files/946 new file mode 100644 index 00000000..6ace710f --- /dev/null +++ b/results/classifier/gemma3:12b/files/946 @@ -0,0 +1,13 @@ + +qemu-img can't create qcow2 file on nfs path，which report error(Image is not in qcow2 format) +Description of problem: +I mount a nfs disk on my host,and use qemu-img to create a qcow2 file on this nfs path,but it not work,i have no idea,This problem has come up before in red-hat community: +[BUGID:1817640](https://bugzilla.redhat.com/show_bug.cgi?id=1817640#) +Steps to reproduce: + + +**strace file:** +[qemu-img-strace.log](/uploads/85517b7550ba1ea459f85cfd37b74332/qemu-img-strace.log) + +See form this strace file,in the line 1077,we can see pread64 read result is empty,it casuse the error,but i don't know why the resulut is empty. + diff --git a/results/classifier/gemma3:12b/files/950 b/results/classifier/gemma3:12b/files/950 new file mode 100644 index 00000000..767f4903 --- /dev/null +++ b/results/classifier/gemma3:12b/files/950 @@ -0,0 +1,24 @@ + +7.0.0-rc2 hw/9pfs/9p.h cannot find XATTR_SIZE_MAX +Description of problem: +``` +[844/2583] Compiling C object tests/qtest/qos-test.p/virtio-rng-test.c.o +ninja: job failed: clang -m64 -mcx16 -Itests/qtest/qos-test.p -Itests/qtest -I../tests/qtest -I. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -flto -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/dummy/qemu-7.0.0-rc2/linux-headers -isystem linux-headers -iquote . -iquote /home/dummy/qemu-7.0.0-rc2 -iquote /home/dummy/qemu-7.0.0-rc2/include -iquote /home/dummy/qemu-7.0.0-rc2/disas/libvixl -iquote /home/dummy/qemu-7.0.0-rc2/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -fsanitize=cfi-icall -fsanitize-cfi-icall-generalize-pointers -fPIE -MD -MQ tests/qtest/qos-test.p/virtio-9p-test.c.o -MF tests/qtest/qos-test.p/virtio-9p-test.c.o.d -o tests/qtest/qos-test.p/virtio-9p-test.c.o -c ../tests/qtest/virtio-9p-test.c +In file included from ../tests/qtest/virtio-9p-test.c:18: +/home/dummy/qemu-7.0.0-rc2/hw/9pfs/9p.h:497:2: error: Missing definition for P9_XATTR_SIZE_MAX for this host system +#error Missing definition for P9_XATTR_SIZE_MAX for this host system + ^ +1 error generated. +ninja: subcommand failed +make[1]: *** [Makefile:163: run-ninja] Error 1 +make[1]: Leaving directory '/home/dummy/qemu-7.0.0-rc2/build' +make: *** [GNUmakefile:11: all] Error 2 +The command '/bin/sh -c make -j"`grep -c '^processor' /proc/cpuinfo`"' returned a non-zero code: 2 + +``` +Steps to reproduce: +1. build with attached Dockerfile +Additional information: +This problem is introduced by lore.kernel.org/all/20220227223522.91937-7-wwcohen@gmail.com/ + +`XATTR_SIZE_MAX` is in `<linux/limits.h>` which is included by `9p.c` but not `9p.h`. However the `9p.h` checks existence of XATTR_SIZE_MAX, so any other file including `9p.h` would be illegal. This is clearly misplacement of header including. diff --git a/results/classifier/gemma3:12b/files/96 b/results/classifier/gemma3:12b/files/96 new file mode 100644 index 00000000..430a6eb4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/96 @@ -0,0 +1,2 @@ + +qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend diff --git a/results/classifier/gemma3:12b/files/961757 b/results/classifier/gemma3:12b/files/961757 new file mode 100644 index 00000000..5f694a4b --- /dev/null +++ b/results/classifier/gemma3:12b/files/961757 @@ -0,0 +1,20 @@ + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". \ No newline at end of file diff --git a/results/classifier/gemma3:12b/files/974 b/results/classifier/gemma3:12b/files/974 new file mode 100644 index 00000000..d4b1a9a1 --- /dev/null +++ b/results/classifier/gemma3:12b/files/974 @@ -0,0 +1,4 @@ + +Enable virtio-9pfs on windows hosts +Additional information: +attn: @schoenebeck diff --git a/results/classifier/gemma3:12b/files/986 b/results/classifier/gemma3:12b/files/986 new file mode 100644 index 00000000..5825c4a4 --- /dev/null +++ b/results/classifier/gemma3:12b/files/986 @@ -0,0 +1,40 @@ + +vpc images are created with bigger virtual size than required +Description of problem: +Required virtual size is 895287296, but as qemu-img info reports it is 895426560. +Steps to reproduce: +1. qemu-img create -f vpc img1.vpc 895287296 +2. qemu-img info img1.vpc +Additional information: +Converting back and forth is not possible as a result + ``` +$ qemu-img info openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +image: openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +file format: raw +virtual size: 854 MiB (895287296 bytes) +disk size: 854 MiB + +$ qemu-img create -f vpc img1.vpc 895287296 +Formatting 'img1.vpc', fmt=vpc size=895287296 + +$ qemu-img convert -n \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -O vpc img1.vpc + +$ qemu-img compare \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -F vpc img1.vpc +Warning: Image size mismatch! +Images are identical. + +$ qemu-img create -f raw img2.raw 895287296 +Formatting 'img2.raw', fmt=raw size=895287296 + +$ qemu-img convert -n -f vpc img1.vpc -O raw img2.raw +qemu-img: output file is smaller than input file + +$ qemu-img compare \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -F raw img2.raw +Content mismatch at offset 0! + ``` diff --git a/results/classifier/gemma3:12b/files/991 b/results/classifier/gemma3:12b/files/991 new file mode 100644 index 00000000..101db2fe --- /dev/null +++ b/results/classifier/gemma3:12b/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. |