In Qubes 3.2 with i3, in any qube, regardless of which template I use, and
regardless of which physical keyboard I use, the right Alt key is useless when
mapped as AltGr, because it generates spurious Alt_L events.
With a standard American keyboard (or Polish one; they're equivalent except for
I'm getting the same bug as reported at
https://github.com/QubesOS/qubes-issues/issues/2018
The bug was originally reported against r3.1 and fedora-23-minimal, and fixed
in r3.2 and fedora-24-minimal. However, I'm getting it on r3.2, using fedora-26
(full, not minimal) for both my USB VM and
awokd writes:
> I wonder if this might be related to a recent patch in testing. Are both
> your dom0 and templates on the same repository (current vs. testing) and
> updated? A recent patch also required a reboot once both were updated.
Both on current, and both updated, and rebooted since last
Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not SSD?
Have you noticed the disk thrashing to be far worse under 4.0? I suspect it
might have something to do with the new use of LVM combining snapshots with
thin provisioning.
The problem seems to be triggered by
On Qubes 4.0, I get intermittent bugs when using qvm-prefs.
One example:
[user@dom0 ~]$ qvm-prefs sys-whonix netvm
sys-firewall
[user@dom0 ~]$ qvm-prefs sys-whonix netvm ""
usage: qvm-prefs [-h] [--verbose] [--quiet] [--help-properties] [--get]
[--set] [--default]
Am I the only one having a problem with Qubes spontaneously rebooting on Intel
hardware? Only other reports I see are about AMD problems, but I'm using an
Intel Core i3.
Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. Got it
on Qubes 3.2, and now 4.0 too (new
For no apparent reason, dom0 suddenly starting consuming practually all CPU
power, and the system is unusably sluggish. Have a dual core Core-i3, and
xentop says dom0 is taking anywhere from 112% to 201% CPU.
top in dom0 shows load average ranging from 2 to 3. Occasionally qubesd,
qvm-pool, or
Chris Laprise writes:
> Can Qubes access all of that RAM? Look at the total_memory figure from
> 'xl info'.
Yes, it can.
One additional data point: after the typical one-minute boot time for a qube,
it's using no swap space, and dom0 is also using no swap space, even though
both do have
Unman writes:
> I don't recognise this on a somewhat under powered laptop with HDD -
> definitely not "minutes at a time". Is there something significant about
> the disks that you cite, or are those just examples?
Nothing significant about #21 in particular. The thrashing procs are whichever
awokd writes:
> I haven't had any of those problems you listed. Only thing I can think of
> are the basics- have you installed anything in dom0? Did you install a
> release candidate of Qubes, then upgrade? Do you have enough RAM to
> comfortably support the amount of running VMs?
Nothing
On Qubes 4.0, I did a full backup to an external hard drive using the standard
backup utility, which completed successfully. 225GB total, compressed 130GB,
took about 12 hours.
Then I tried to verify it (restore with verify-only option), and watched it for
a few minutes to make sure it was
11 matches
Mail list logo
