Here is the exact working command line I used for Windows 95C (OSR2.5):
qemu-system-i386 -cpu pentium -m 128 -vga std -no-kvm -hda
~/Win95C.qcow2 -nodefaults -no-hpet -no-acpi -nodefaults -monitor stdio
-sdl -boot menu=on,order=c,splash-time=2000 -accel tcg,thread=single
To install the OS I simpl
I tried reverting that commit on top of master but it did not help, so
I'm guessing it broke yet again (differently) somewhere else. I'll try
reverting cd1bfd5 on top of the very next commit and bisect from there
to master, and see where that takes me.
--
You received this bug notification becaus
Just finished a bisect between cfcca36 (working) and current master (not
working), here is the result:
$ git bisect bad
cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit
commit cd1bfd5ef336166b275a09dc9842542bf5e63ae3
Author: Gerd Hoffmann
Date: Wed Jun 20 12:17:34 2018 +0200
So it looks like even though that commit fixed it, it seems to break
again (differently) in 3.0.0, so I'll need to do another bisect between
cfcca36 and v3.0.0 then I guess. And keep working my way up to master as
well.
--
You received this bug notification because you are a member of qemu-
devel
e3af7c788b73a6495 was indeed one of the bad commits I tested during the
bisect. If I apply cfcca361d77142f25f on top of it, Windows starts up
normally instead of giving me a BSOD on bootup.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Hopefully third time's the charm. I ran yet another bisect, between
2.5.0 (working) and 2.11.0 (not working), this time reinstalling the
entire OS from scratch with a blank disk every single time. Results:
$ git bisect good
e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 is the first bad commit
commit e3
Just FYI that was the second bisect I had to do, the first time it
produced an even more unrelated commit, so I assumed I must have done
something wrong... apparently that is still the case. After trying the
"working" commit outside of the Docker container, it now does not
work... so I'm at a loss
I am not using anything related to migration, just launching with a
simple flat qcow2 file, no snapshots, backing stores or anything like
that.
The host is Archlinux x64 but I'm running inside of a docker container
that runs Ubuntu 18.04.
The command-line is:
qemu-system-i386 -spice port=5800,di
Whoops, 3.11.0 does not exist. Went back and did a full bisect. 3.0.0
works fine, and the breakage starts before 3.0.1 and 3.1.0 was released,
specifically, with commit 05306935b1ae49107c2dc2f301574dd6c29b6838.
--
You received this bug notification because you are a member of qemu-
devel-ml, whic
I was able to get both running on 3.11.0, but something broke again by
the time I re-tested on 4.0.0. 98 seems to work on 4.0 at least, but 95
just reboots infinitely after trying to boot from HDD after the initial
setup. I tried searching their mailing list and asking around but nobody
seems inter
I just tried the latest git and it actually boots fine with your
command... so I guess whatever issue I was having (the null dereference
in the timer code I pasted above) must have been fixed... however I've
noticed another issue with a different command that causes the bootup to
hang:
qemu-system
** Description changed:
I created an empty 128G qcow2 image and booted from a Mac OS 9.2.1
Install CD, in which I was able to install the OS successfully to the
hard drive. Upon reboot, this time from the hard drive directly, qemu-
- system-ppc segfaults.
+ system-ppc segfaults. Host system
Public bug reported:
I created an empty 128G qcow2 image and booted from a Mac OS 9.2.1
Install CD, in which I was able to install the OS successfully to the
hard drive. Upon reboot, this time from the hard drive directly, qemu-
system-ppc segfaults. Host system is Ubuntu 16.04.2 with latest qemu
13 matches
Mail list logo
