[qubes-users] Qubes OS 3.2.1-rc1 has been released!

2018-10-05 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We're pleased to announce the first release candidate for Qubes 3.2.1!
This is the first and only planned point release for version 3.2.

Features:
- - Fedora 28 TemplateVM
- - Debian 9 TemplateVM
- - Whonix 14 Gateway and Workstation TemplateVMs
- - Linux kernel 4.14

Qubes 3.2.1-rc1 is available for download here:
https://www.qubes-os.org/downloads/#qubes-release-3-2-1-rc1


What is a point release?
- 

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 3.2) inclusive of all updates up to a certain point. Installing
Qubes 3.2 and fully updating it results in the same system as installing
Qubes 3.2.1.


What should I do?
- -

If you're currently using an up-to-date Qubes 3.2 installation, then
your system is already equivalent to a Qubes 3.2.1 installation. No
action is needed.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more
convenient and secure, since it bundles all Qubes 3.2 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 3.2 installer.

As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to
reach EOL (end-of-life) on 2019-03-28. [1]


Release candidate planning
- -

If no major problems are discovered with this release candidate in the
next two weeks, it will be designated the final 3.2.1 release. Please
report any bugs you find. [2]


What about Qubes 4.0.1?
- ---

The Qubes developers are hard at work on 4.0.1, which will be the first
point release for Qubes 4.0. We hope to have further news about this
within the next few weeks. Stay tuned!


[1] https://www.qubes-os.org/doc/supported-versions/#qubes-os
[2] https://www.qubes-os.org/doc/reporting-bugs/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlu4K2EACgkQ203TvDlQ
MDCVBBAAyN6W5nqYHtbtdY9rQdz6IsOLff9etERcb3nfVAaLzr9q76DETivY8Wox
vqw9DCuXJeKhMNAyRoH9nXP64Jhy32tYsZ8ztednu1LhNnS7+5IlGnzkhBFcpPXX
78gUXhH7Ai0Mv6PMCE8P9RBIr5vRheOzwYEOaZXgwgie2o3MNajty2uC8fl3gm/C
kxtOnp8sfZ7if26G0/C4UiDOSD8ZRVrfnZHt04772VGbL0glJhyf0CVRSR1TMVwY
vhxl7q8PwifwRi4uLQ5p3D+WDIMoCEOD86IOOmUXf5tKXtQknuhIw15gN/5V/VSn
/yvYUaPxgLigZfkyqmO5vYu27nSeoGq3YSElLedesk1wAX0oWNhOr4UPQrqxBtXJ
hwx3L+IygS/oFpJ2acciCvhGLwAzCLHlK5SNmqovYoiQecOANvU/CFtWuzjIdwl3
NHln4BdDrBz4b+fQfA1Sgt4CY7qt75/vOnL/EnBwboA6Sg7Nd2CKC1gGVQ7fjZoR
2Tw64JkWFR9BcCtTeXHzJDil5F0W0PCPNAKk3B1zYg6YWtooM5qB24AZWEP9dUNJ
djL9nQqbaexRdRJiyboZcRDgKH5AjYWhWhfIK2TSTWxEWLRB1fJHqWbW2Uy+zWyl
QMoa+5a+ASP3eoHW/QXtBsKh4yi3sHF8zgBiBuHhrLZrWIWbaeM=
=cGAY
-END PGP SIGNATURE-

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8ede7eb8-6b14-b571-4da5-102c636bafa1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Whonix support ending for Qubes 3.2

2018-10-05 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

Due to limited developer time and resources, the Whonix Project [1] will
end support for Qubes 3.2 on 2018-11-15.


Whonix support for Qubes OS
- ---

Please note that there is a distinction between Qubes supporting Whonix
and Whonix supporting Qubes.

1. Qubes supporting Whonix means that Qubes OS allows the secure
   installation and use of Whonix TemplateVMs [2] inside of Qubes OS. In
   this case, the Qubes developers work to ensure that code on the Qubes
   side is set up to accommodate Whonix TemplateVMs. (This is the same
   sense in which Qubes supports Fedora and Debian TemplateVMs.) Here is
   a table [3] of the TemplateVM types that Qubes supports.

2. Whonix supporting Qubes means that Whonix is designed to be
   installable and usable as a pair of TemplateVMs inside of Qubes OS.
   In this case, the Whonix developers work to ensure that code on the
   Whonix side is set up to work inside of Qubes OS. (Similarly, the
   Whonix Project also works to ensure that Whonix can be installed
   inside of VirtualBox, for example.) Here is the Whonix version
   support policy [4] for Qubes OS.

Both directions of support are necessary in order to ensure that Whonix
functions properly inside of Qubes, and the Qubes and Whonix developers
work together toward this shared goal.

This particular announcement concerns the second direction of support:
Whonix supporting Qubes (in particular, ending support for Qubes 3.2).


Difference from EOL
- ---

Whonix 13 recently reached EOL (end-of-life) on 2018-09-30. [5] When a
an OS or TemplateVM version reaches EOL, it no longer receives support
from its maintainer. In this announcement, however, nothing is reaching
EOL. Whonix is ending support for Qubes 3.2 2018-11-15, but the Qubes OS
Project will continue to support Qubes 3.2 as planned until 2019-03-28. [6]


What this means for you as a user
- -

If you are using Qubes 4.0, this announcement does not affect you. If
you are using Qubes 3.2, the Whonix Project will no longer support your
system after 2018-11-15. This means that no developers from the Whonix
Project will be monitoring or working on issues that pertain solely to
Qubes 3.2. Therefore, the Whonix Project cannot guarantee that Whonix
will continue to function as expected on Qubes 3.2.

However, since Qubes 3.2 is a mature platform, it is likely that Whonix
will continue to work normally until Qubes 3.2 reaches EOL on
2019-03-28. Users who decide to continue using Whonix on Qubes 3.2 do so
at their own risk. It is possible that an upgrade could break certain
functionality, such as apt-get upgrading, networking, VM booting, or VM
graphics. The Whonix Project believes it is unlikely (though not
impossible) that a clearnet leak would result from continued use. For
further assistance, please consult the Whonix support page. [7]


[1] https://www.whonix.org/
[2] https://www.qubes-os.org/doc/whonix/
[3] https://www.qubes-os.org/doc/supported-versions/#templatevms
[4] https://www.qubes-os.org/doc/supported-versions/#whonix
[5] https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/
[6] https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future
[7] https://www.whonix.org/wiki/Support

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/10/05/whonix-support-ending-for-qubes-32/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlu4K1AACgkQ203TvDlQ
MDBiPRAAsEGOdG+dLNploLcft4TDVJwg1qK3a4cVb2PVOPAas/hwUgDOPr9592mi
NYZpL0MG6wYMXqOnqXTEF+eYio4giJpRWkwCJmh/hNhOedtQ1DkLYcXY8OQd6YGL
N90Z3JoMbXQb3fDqLR7I1YxOLjByytCnIVRp8e0C5EhBlNlW5MSMXmGy3CJ63jwK
wu8jqhJWR0zGZiUK0JlFvYl0A59A7gfhfHnUN65jMRjuA2YNUXO826zrUAk0c1ts
dfCpphcb1UPN0mtwCkEu+TG4DVguQjQq54OUNXyLKHTgG7ElVU63H/GvILEccSrl
D9mvVBc0dq+yoh44DNZ/IScUdCnnc4GXT6whWvmYSUi1BQY6ap7zGLHTLpx2hsWe
BQspqIsLv/1l51Y2LyzoFQyqR91re59qG2z4FOxsY95PZxcKi5L0JGBEItAQY6Gr
mEll/3rzn2mKR0muA9xDZRJ2AreDwMqD41gGYU+mWsdvmrc48c7bxffsLihS+bA9
S1VrFe63DwbSW4Aej2uIz+noZlDGPW2YCaz58u4gbb/fs61/7UDbq/dsH7eSzJ9H
yiCCjsgE/m7ONeWP+FLkf6iz9a5Du2qZU55tUSokXEt1gtF2YBM1/RtoKXqWv35U
ktINNukuRmfZ3BKbORPaZkmGQLMMsd6TRtKZcIeBhbHk+3Rjz8M=
=pQ2H
-END PGP SIGNATURE-

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75821d00-d847-c83f-6967-7b5dc2b8e6b0%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] traveling change time how ?

2018-10-05 Thread reby
I guess it should be evident but apparently not ?  I've changed the 
timezone manually on the taskbar to the new TZ  , however I see that 
when I update a Template it is still using my home TZ not my current TZ



what are the steps to correctly change to a new TZ  when travelling with 
Q4.0 and a laptop  please ?


I also use whonix-14


thankyou

--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8fd9dd05-638f-c902-5e3b-2c314611d9e0%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

2018-10-05 Thread Otto Kratik
On Friday, October 5, 2018 at 3:26:51 PM UTC-4, Ivan Mitev wrote:
> Every time I had a "failed to synchronize..." erorr it was because there 
> was a problem with the proxy in sys-net. Restarting it usually did the 
> trick, eg:
> 
> sudo systemctl restart qubes-updates-proxy.service
> 
> (run the command sys-net ; the syntax is for R4.0, I don't have R3.2 to 
> test but it shouldn't be too different).
> 
> Check the proxy's status with
> 
> sudo systemctl status qubes-updates-proxy.service


Thanks for your help and suggestion. I just tried both of those commands and 
sys-net reports the update proxy is working perfectly, however there is no 
change in the result from dom0 and I get the same error message as before.

The original interruption glitch happened after dom0 had already successfully 
downloaded all updates, but during the upgrade/install of those new packages. 
Ever since then, this issue has occurred. So I am thinking something local has 
gotten messed up rather than a connection issue.

Any other ideas I should try in order to fix this?

Thanks...

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ce59a818-cea9-4f59-a782-9557d8b48273%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing qr-exec on HVM

2018-10-05 Thread Will Dizon
Unfortunately, it didn't work still when qubes-gui-agent was running.

I tried recompiling everything again, and the results have changed quite a bit. 
 Now, instead of autohiding the HVM window in dom0, I can see a very clear 
failure which points me in the direction of Xorg instead.

Sadly, this feels like a regression, but alas... I'm sure I'll get there 
eventually.

As far as "xl console lfs", dom0 reports "unable to attach console".  And in 
terms of dom0, it is still giving no sense of failure:

$ qvm-run --pass-io personal whoami
user
$ qvm-run --pass-io lfs whoami
$ qvm-run lfs "touch /tmp/dummy"
Running 'touch /tmp/dummy' on lfs

Needless to say, /tmp/dummy doesn't ever emerge.

The new error is

systemctl status qubes-gui-agent.service
...
Process: 660 ExecStart=/usr/bin/qubes-gui $GUI_OPTS (code=exited, 
status=1/FAILURE)
...
lfs qubes-gui[660]: XIO fatal IO error 11 (Resource temporarily unavailable on 
X server ":0"
lfs qubes-gui[660]: after 37 requests (36 known processed) with 0 events 
remaining)

X works (startx shows me a desktop and consoles), but nothing yet from getting 
Qubes GUI agent and qrexec.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/92378a13-da16-44e4-98b7-ee379179bbba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

2018-10-05 Thread Ivan Mitev




On 10/5/18 9:48 PM, Otto Kratik wrote:

Qubes 3.2

Ever since a routine qubes-dom0-update was interrupted in the middle of the 
upgrade process, I can no longer run any updates on dom0. Instead I see the 
message:

"Failed to synchronize cache for repo 'qubes-dom0-cached', disabling."

..in response to most commands that I attempt through yum/dnf/qubes-dom0-update 
to try fixing it. None of the usual approaches like --clean have been 
successful.

What should I try from here to correct the issue?


Every time I had a "failed to synchronize..." erorr it was because there 
was a problem with the proxy in sys-net. Restarting it usually did the 
trick, eg:


sudo systemctl restart qubes-updates-proxy.service

(run the command sys-net ; the syntax is for R4.0, I don't have R3.2 to 
test but it shouldn't be too different).


Check the proxy's status with

sudo systemctl status qubes-updates-proxy.service





Thanks,
Otto



--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/075cfeb5-0057-4ae6-6d7c-7e2de4a7dd5f%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

2018-10-05 Thread Otto Kratik
Qubes 3.2

Ever since a routine qubes-dom0-update was interrupted in the middle of the 
upgrade process, I can no longer run any updates on dom0. Instead I see the 
message:

"Failed to synchronize cache for repo 'qubes-dom0-cached', disabling."

..in response to most commands that I attempt through yum/dnf/qubes-dom0-update 
to try fixing it. None of the usual approaches like --clean have been 
successful.

What should I try from here to correct the issue?

Thanks,
Otto

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f9c6682-13b8-41fc-9338-8df3e6aff04e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Lenovo P52

2018-10-05 Thread brendan . hoar
On Thursday, October 4, 2018 at 3:05:00 PM UTC-4, Achim Patzner wrote:
> I just tried installing Qubes 4.0 on a Lenovo P52 (out of the box, no
> firmware updates) and it didn't even boot the distribution media off
> USB (after trying several USB ports; there are at least three separate
> controllers in this thing). I'm getting exactly 4 lines of mesages
> during boot and as it is a 4k display I would have had to take a photo
> of it to enlarge whatever was written there (so I can't really tell you
> what I saw).
> 
> My first suspicion is the RAM; I ordered it with 128GB to keep it from
> even thinking about swapping. Is there a limit on in the current
> distribution?
> 
> The firmware has old bugs I encountered on P70 already; I turned off
> secure boot and reordered the EFI boot entries resulting in a machine
> that is not even displaying the Lenovo banner after turning it on so I
> have enough time to think about the errors of my ways (kids, don't try
> this at home -- there aren't any replacement mainboards in Europe and a
> "repair" will take 6 weeks so you have to force IBM UK into calling it
> a late DOA if it happens).
> 
> Does anyone have an idea how to convince it to boot?

Ha ha ha, ouch. I am SOOO jealous of you right now ...but also feel so much 
pain for you as well. That's a very expensive doorstop.

There should be 4 SODIMMS. Remove two to try booting with 64GB of RAM? 

Can you not get to the BIOS by vigorously tapping F1 after power on, then reset 
it to factory config?

-Brendan

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fac205d2-0704-4d76-aed4-329f886a8f43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] session managers for VMs?

2018-10-05 Thread brendan . hoar
On Friday, October 5, 2018 at 12:13:42 AM UTC-4, Manuel Amador (Rudd-O) wrote:
> On 2018-09-22 07:13, Daniel Allcock wrote:
> > Even better would be to "hibernate" a qube by suspending it to disk,
> > but I know the qubes team has other priorities. I'm hoping per-vm
> > session management is something I could do right now.
> 
> Best bet would be to implement actual hibernate/thaw for VMs.  That's a
> tall order though.

Under Qubes 4.0, I've found that Win7 VMs can hibernate (at the guest OS level, 
of course), though now I am beginning to suspect that was only with a 
non-templated HVM. Why so difficult for Linux VMs? 

Hmm...ok...
- Significant additional work to support Templating w/ Hibernation, as I 
alluded to above (e.g. managing additional template disk changesets until 
hibernated systems that depend on them are thawed and shut down)? 
- Preferring hypervisor-initiated hibernate for additional security or 
performance reasons?
- More issues?

Brendan

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/efec5ba0-fc15-4801-aeab-325e51a671ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.