Chris Laprise:
On 7/25/19 11:04 AM, brendan.h...@gmail.com wrote:
...there are very very early test-builds of Qubes R4.1 out there
utilizing Xen 4.12 and Fedora 30. This 2019-07-01 build appears
semi-stable in light testing. It is, at a high level (and Marek can
correct me if I am wrong), the R4.01 codebase with up-to-date Xen and
dom0 Fedora w/ any Qubes-related changes to ensure these work with the
Qubes code base.
I was able to install that particular test build on a Thinkpad X230
for testing: https://openqa.qubes-os.org/tests/3021
(note: click on assets tab for link to download the ISO)
It might be worth installing one of those as well on another drive to
see if newer Xen/Fedora combinations resolve sleep issues or get you
closer to resolution.
Interesting link!
I was just thinking this could be an "old Fedora" problem. But that also
suggests there may be a way to patch the current dom0 to handle suspend
correctly. Of course, domU is a factor if sys-net or sys-usb are running.
... But it works on Fedora 29 with 4.18, and not Qubes R4.0.1 with 4.19.
Is a Fedora 29 kernel 4.18 different than a Fedora 25 kernel 4.18? i.e.
different branches/backports or something? Or could something besides
the kernel be causing the difference in behavior?
Trying Fedora 25 with 4.8.6, just for good measure... This is
interesting. At resume, the fan comes on but the screen doesn't power on
(just as in Qubes), but this time, unlike in Qubes, pressing caps lock
*does* turn on the light. Alt-SysRq-B doesn't do anything (it might be
disabled), but incidentally, when I pressed Print Screen I heard a
camera shutter sound effect, and Ctrl-Alt-Del powered it off after 60
seconds. So, the OS is responsive after resume (unlike Qubes), just the
screen is still powered off.
Also, instead of powering off the screen due to inactivity, it just
turns it black instead, much like Qubes.
So it's almost starting to sound like it was a graphics driver issue or
something that was fixed sometime between Fedora 25 and Fedora 29, but
somehow still hasn't made it to Qubes. Still way too early to say, though.
Claudia:
Have you tried suspend/resume with no VMs running at all? This can be
accomplished by manually shutting down appVMs then service VMs, or with
the command 'qvm-shutdown --all --force --wait'.
Pretty sure I did, but re-tested to be certain. With all VMs stopped,
resuming makes the fan come on, but the screen doesn't power on, and
pressing the caps-lock key doesn't turn its light on. I have to
long-press the power button and restart.
I could have sworn when I tested this before, resume wouldn't make the
fan come on or anything at all. Although, it would be easy to mistake
one for the other, because the fan isn't the most reliable output
channel. From the time I tested Ubuntu onward, I started using
`sha256sum /dev/urandom` to intentionally get the fan running before
suspend. So it makes sense, in prior testing the fan probably just
wasn't running loud enough to hear.
So, if that's the case, that means I'm getting the same result in normal
Qubes as in Qubes with VT-x & VT-d disabled. This is good news, as means
it's probably not some firmware-related virtualization problem, right?
Just to humor myself, I was going to try testing if I could hear sound
from Qubes after resume, but it seems audio isn't working at all. Which
is a whole 'nother problem. Aplay says "... unable to open slave; audio
open error: no such file or directory." `echo -e '\a'` doesn't work even
on a TTY (lsmod shows pcspkr), and `beep` isn't installed.
If this works, then the problem may be in the VMs such as sys-net or
sys-usb. This is possible because those VMs control hardware that must
also respond to special commands related to sleep/wake.
Makes sense, but unfortunately (or fortunately) I couldn't even get it
to resume properly under Qubes even with VT-x & VT-d disabled.
If it doesn't work, then the problem is probably entirely in dom0 and
Fedora 25. Assuming you already have the testing 4.19 kernel, have you
Well, that's good news. At least, I'd rather the problem be in dom0
kernel than in firmware! It also means it's probably not device-related,
if I'm following correctly. But, there's still a chance it could be Xen,
too, right?
I don't suppose it's possible to upgrade Qubes to Fedora 29, or so?
thought of upgrading it to the even newer 5.x one as 'latest'? The
latest kernel is installed by specifying the special package named
'kernel-latest'.
Installed 5.1.15-1. Hangs between Xen and dom0 kernel (blank screen with
no underscore) about 50% of the time. Same result. Fan comes back on,
but no caps lock light. Tried again with all VMs stopped. Same result.
So all this kind of makes me think
1) there are special kernel patches or something in Fedora and Ubuntu
that aren't in Qubes, or
2) the issue is caused by something other than the kernel entirely, or
3) it's Xen
I still have to try the R4.1 test build.
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/46d2acec-30aa-f8a6-c6bf-f9f3027e243b%40vfemail.net.
