Your message dated Tue, 8 Oct 2024 08:38:43 +0300
with message-id <[email protected]>
and subject line Re: Bug#1084199: qemu-sys: Windows 10 guest freezes after a
few moments running under QEMU/KVM
has caused the Debian Bug report #1084199,
regarding qemu-sys: Windows 10 guest freezes after a few moments running under
QEMU/KVM
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1084199: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084199
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qemu-system
Version: 1:9.1.0+ds-8
Severity: important
X-Debbugs-Cc: [email protected]
Dear Maintainer,
* What led up to the situation?
I have been running a Windows 10 guest in QEMU/KVM without issues for over 2
years. After a recent update of the qemu packages to the version just before
the current one in sid, the Windows guest starts normally but freezes
completely just a few moments after logging in. The GUI becomes unresponsive
and the only solution is to force the instance to quit.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I reverted to version 1:9.0.2+ds-2+b1 of all the qemu packages via
snapshot.debian.org.
* What was the outcome of this action?
The Windows guest behaves normally and usefully.
I would be happy to help debug this problem but I could not figure out where to
look in the host logs for any sign of trouble with QEMU, and the Windows
instance doesn't run normally for long enough to look at the Windows Events
display.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (650, 'unstable'), (650, 'stable'), (500,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages qemu-system depends on:
ii qemu-system-arm 1:9.0.2+ds-2+b1
ii qemu-system-mips 1:9.0.2+ds-2+b1
ii qemu-system-misc 1:9.0.2+ds-2+b1
ii qemu-system-ppc 1:9.0.2+ds-2+b1
ii qemu-system-sparc 1:9.0.2+ds-2+b1
ii qemu-system-x86 1:9.0.2+ds-2+b1
qemu-system recommends no packages.
qemu-system suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
08.10.2024 04:26, Hank Knox wrote:
I found a fix!
I looked a little more carefully at the bug report you referenced and saw something about updated virtio drivers so I downloaded and mounted
virtio-win-0.1.262.iso as a CD on the Windows VM, fired it up, installed virtio-win-x64.msi and virio-win-guest-tools.exe, closed Windows, set the
Video to QXL, restarted Windows, and voilà, it works just fine. So the problem isn't with QEMU but with out-of-date or overwritten Windows drivers.
You can close this bug now.
Oh wow! :)
Well. Somehow checking for the drivers is the very first step to do for me.
Not even the first, it is a "pre-debugging" step, like a step zero, it occurs
automatically before doing anything else. So I assumed you obviously did that
step zero and didn't dare to ask :)
Congratulations! :)
And I think now you see how interesting things might turn, and you don't have
any reasons to be jealous anymore ;)
Thanks for all your help with this. Maybe another time we'll get to bisect a
git repo together...
You're welcome.
Thanks,
/mjt
--- End Message ---
