PID: 0.102
graphic: 0.095
socket: 0.095
other: 0.090
device: 0.078
semantic: 0.076
performance: 0.075
permissions: 0.073
debug: 0.063
network: 0.062
KVM: 0.052
files: 0.050
boot: 0.048
vnc: 0.041
files: 0.225
device: 0.150
PID: 0.109
socket: 0.096
debug: 0.075
boot: 0.059
KVM: 0.058
other: 0.054
semantic: 0.051
vnc: 0.039
network: 0.031
graphic: 0.019
performance: 0.017
permissions: 0.016
virtual fat do not working in qemu 1.5.0
Guest : windows Seven / XP
Qemu version : 1.5.0
cmd line :
-drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on
generated by libvirt :
works with qemu <= 1.4.1
with qemu 1.5.0 , guest does not see the floppy content.
Regards
same issue with qemu 1.5.1
floopy content is seen under linux. not under Windows guest
On Fri, May 31, 2013 at 03:26:47PM -0000, prochazka nicolas wrote:
> Public bug reported:
>
> Guest : windows Seven / XP
> Qemu version : 1.5.0
> cmd line :
> -drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on
> generated by libvirt :
>
>
>
>
>
>
>
>
>
>
> works with qemu <= 1.4.1
>
> with qemu 1.5.0 , guest does not see the floppy content.
Thanks for reporting this bug. The vvfat block driver is not actively
maintained, but you can help us track down this bug:
Since it used to work in QEMU 1.4.1 you could use git-bisect(1) to
identify the commit that broke vvfat.
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search
https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
http://code-worrier.com/blog/git-bisect-basics/
Something along the lines of:
$ git clone git://git.qemu.org/qemu.git
$ cd qemu
$ git bisect start
$ git bisect bad master
$ git bisect good v1.4.1
Then build from source and test at each bisect step:
$ ./configure --target-list=x86_64-softmmu && make
$ qemu -drive file=fat:floppy:...
If it fails:
$ git bisect bad
If it succeeds:
$ git bisect good
At the end of the process it will tell you which commit broke vvfat.
Stefan
Triaging old bug tickets... Have you ever bisected the problem? Can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
[Expired for QEMU because there has been no activity for 60 days.]