Returning to an old topic...
Christian MICHON wrote:
On 8/19/06, J M Cerqueira Esteves [EMAIL PROTECTED] wrote:
So the culprit of the cdrom timeouts seems to be -hdd ...
but why?
I saw the same things few weeks ago. Since then, I do
not use hdd anymore (my qemu host is winXP).
My previous
dmc wrote:
I have a pretty ugly patch against qemu 0.8 which allows the location of
data used with the -snapshot feature to be somewhere other than
/var/tmp. I have a use-case where I am creating many gigabytes of
changes to disk in snapshot mode. When 0.9 came out, I looked, but it
seemed
herbie hancock wrote:
Hello, i had also a reproducible disk crash:
info of the last good image, size is about 3,5GB
I never experienced such a bad problem with qemu before, maybe it is a
problem with qcow2 format ?
After the problems with qcow2 images which I reported here a few weeks
ago,
J M Cerqueira Esteves wrote:
After shutting down the guest, I inspected its image files with
qemu-info, which reported for hda
image: nisaba.hda.qcow
file format: raw
virtual size: 4.3G (4596273152 bytes)
disk size: 4.3G
but hda was supposed to have a virtual size of approximately 20 GB
J M Cerqueira Esteves wrote:
Curiously this damaged image file has 4543348736 bytes.
I wonder if there some new bug triggered by the image file size,
for some size around 45 bytes...
I have a copy of the disk image file as it was just before starting the
qemu run which damaged
J M Cerqueira Esteves wrote:
This time, after installing some packages in a similar Debian guest,
the [guest] system froze while shutting down (using 100% CPU on host).
I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk,
in a by then more than 4GB file) was no longer
Greetings
I got some error messages shortly after booting a Debian guest under
QEMU 0.9.0. I did not annotate those, but they made me believe there
could be disk access problems, and if fact something weird happened to
one of the disk images (this was using two images, for hda and hdb):
After
J M Cerqueira Esteves wrote:
11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a
6c6f 3d 6c6f 0a
65746830 3d 65746830 0a
or, of course (duh, I should have noticed, although I'm not sure this
can help),
lo=lo\n
J M Cerqueira Esteves wrote:
vdeq qemu-system-x86_64 .. -hda .. -hdb .. -hdd .. -cdrom .. -boot d
On many CD reading attempts there were longer-than-normal waits, for
which the kernel reported
hdc: DSC timeout
[...]
But it *didn't* happen when I tried the same installation process only
I submited the attached report to the Debian bug tracking system,
but just now I noticed that that segfault of hwclock with libc6-i686 (in
a guest Debian testing system) only occurs if the virtual machine
is started with -kernel-kqemu. Could this be related to some kqemu bug?
Best regards
As I said before, under
Host CPU: AMD Athlon 64 3500+ (machine: HP dx5150 MT)
Host operating system: Ubuntu 6.06 LTS
Host kernel: one of the Ubuntu pre-packaged ones,
2.6.15-26-amd64-k8 (SMP PREEMPT)
QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa
kqemu: 1.3.0pre9
I
Greetings
Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon
64) crashes while installing a guest Debian amd64 testing (etch) system,
with the host reporting (in kernel logs):
kqemu: aborting: Unexpected exception 0x0d in monitor space
Host CPU: AMD Athlon 64 3500+
J M Cerqueira Esteves wrote:
Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon
64) crashes while installing a guest Debian amd64 testing (etch) system,
with the host reporting (in kernel logs):
kqemu: aborting: Unexpected exception 0x0d in monitor space
I forgot
J M Cerqueira Esteves wrote:
Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon
64) crashes while installing a guest Debian amd64 testing (etch) system,
with the host reporting (in kernel logs):
kqemu: aborting: Unexpected exception 0x0d in monitor space
However
Anthony Liguori wrote:
On Fri, 11 Aug 2006 07:57:41 +0100, J M Cerqueira Esteves wrote:
Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon
64) crashes while installing a guest Debian amd64 testing (etch) system,
with the host reporting (in kernel logs):
kqemu: aborting
15 matches
Mail list logo
