Re: [qubes-users] Confused about verifying signatures

[Patrick Bouldin]

On Thursday, August 16, 2018 at 6:43:50 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-08-16 17:35, Andrew David Wong wrote:
> > On 2018-08-16 15:47, Patrick Bouldin wrote:
> >> Hi trying to validate 4.0. I downloaded the 
> >> qubes-master-signing-key.asc and then not able to progress. I did 
> >> find Joanna's qubes master signing key footprint, but I don't know 
> >> how to compare or take the next step...
> > 
> >> I did this with 3.0 a few years ago but can't remember...
> > 
> >> I did check the web site and still don't know.
> > 
> >> Thanks.
> > 
> > 
> > If you just want to see the fingerprint of the key you downloaded as a
> > file so that you can compare it to the fingerprint you obtained
> > through another channel, this is probably the simplest way:
> > 
> >   $ gpg2 qubes-master-signing-key.asc
> >   gpg: WARNING: no command supplied.  Trying to guess what you mean ...
> >   pub   rsa4096 2010-04-01 [SC]
> > 427F11FD0FAA4B080123F01CDDFA1A3E36879494
> >   uid   Qubes Master Signing Key
> > 
> 
> If you're using gpg instead of gpg2, there's the --with-fingerprint
> option:
> 
>   $ gpg --with-fingerprint qubes-master-signing-key.asc 
>   gpg: keyring `/home/user/.gnupg/secring.gpg' created
>   pub  4096R/36879494 2010-04-01 Qubes Master Signing Key
>   Key fingerprint = 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlt1/gQACgkQ203TvDlQ
> MDASEA//a1TzjaaAPwNS12GHWollY2WGqpSK7RZNEsHkBSJYPTaNayqOHXx2yzQ2
> Re5uPgpHofCYxNx96VhKFDE9rIo17ozrLrr+ZywESDn5GoIzM7BtUaKTR5GQWZx1
> E9vALH50GtNJAdb/SumOcdsDxrDj139wjcAuypWBDXK6lxF2hR/nDr7RZMxvfwTF
> uixM4LP7zhwOafLAbhXsa9wyu6ZsooTicdiSit+iQPk15oxLGjUSncQcIYuRLdvX
> yLht5/2ZPST1Jm9HyEEwOllMN4eFrMAc/StHhVxPWlUiqtr3xMki3IWZV+xi8sMh
> Ri0HmASNzLn4JwNQnPFQqnT+Z4Im8tiH24w/T8eHhP2hLo8tEfd5aq26xl0NoRbU
> Hcc69XXjzITQIi2d7YZHgtNgrml8zCjTRF+9p14cLyFFl2ISJsEZeus/egQWE6Rv
> aRMR+IPDG8HqCWepV+Y/of3lb+uqd7SBVJdcRavf/Jrlf/9AOeCRDUteTGsiJE14
> U9FksIiiZRclcHR+NFeZSbINvwlwNx2tO7o7YcbBxmqPMzsg20gHYfuI3GAnMY/R
> yHX52v6sXcM/4Y08TrTTHV1l+/EPUOnOb3adaIejNyEiHB5WiQ3fgoEwpX3GkKTb
> iCt4TJJKo6KRSG2EzMMLH0s69gGphqLtgC5+zEQg4X7NWpFzWX4=
> =cBsO
> -END PGP SIGNATURE-

Thanks and a quick question. I did get a final "Good signature", but curious, 
does that process actually modify the iso at all? Just would like to know 
because I pulled the iso file from my other pc and it will be easier to build 
the flash there.

-- 
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/8b5b5988-ee3d-43ab-a229-e1a2d176e27f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to open "green" URL's in a new red window?

[Marcus Linsner]

On Monday, February 16, 2015 at 11:00:29 AM UTC+1, Laszlo Zrubecz wrote:
> On 02/16/15 10:53, kerste...@gmail.com wrote:
> > Hello,
> > 
> > I have the document D1 with the URL1 inside the green Domain.
> > 
> > If I click on this domain, than the green Domain with the firefox is 
> > starting...
> > 
> > Can I define, that all URL's, which get opened by clicking on the URL, are 
> > opend in another domain with the appropiate web-security level, e.g. red?
> 
> You can define it in OS level (default applications in GUI)
> You can use qvm-open-in-vm or qvm-open-in-dvm commands to open new links...
> 
> 
> -- 
> Zrubi

Has anyone added a new menu entry such as "Open Link in New qube VM" to 
Firefox's context menu, maybe under "Open Link in New Tab" for example? If not, 
I'll post a link to it when I've finished it (would require recompiling firefox 
btw - and I'm still learning how to do it under Fedora 28) because I really 
need something like this in order to open links from my google-search-VM into 
other VM(s).

-- 
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/d170b474-3680-414e-83f9-7733fbc75270%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: please stay tuned on Whonix news

[John S.Recdep]

On 08/15/2018 07:23 PM, Patrick Schleizer wrote:
> It is important to read the latest Whonix news to stay in touch with
> ongoing developments. This way users benefit from notifications
> concerning important security vulnerabilities and improved releases
> which address identified issues, like those affecting the updater or
> other core elements.
> 
> Read more:
> https://www.whonix.org/wiki/Stay_Tuned
> 

did something happen?

by "updater"  meaning sudo apt-get update && sudo apt-get dist-upgrade   ?

seemed to be broken the other day, but seems ok
don't see anything new on vuln issues
https://forums.whonix.org/c/news

guess I can check again next month  :)

-- 
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/d1af25f4-68c7-3cd0-04e7-b49470e2c37a%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Suggested order for loading Qubes 4.0?

[John S.Recdep]

On 08/16/2018 04:25 AM, Patrick Bouldin wrote:
> Hello, I got some great advice about having two hard drives since I want 
> Windows on one drive and qubes on another. So I now have a good I7 laptop 
> with two - 1/2 TB SSDs. I had in mind to load it this way, is the following 
> correct?
> 
> I'm starting with both SSDs empty, no OS on either.
> 
> 1 Physically install both drives
> 
> 2 Install Windows on disk 1 after booting to flash drive with windows ISO
> 
> 3 Unplug windows based SSD drive just to be sure I'm on the right drive next
> 
> 4 Boot to bios, modify bios to change 2nd SSD (to be Qubes) FROM Windows UEFI 
> to other OS (correct?)
> 
> 5 Boot to a flash drive loaded with the Qubes 4.0 install ISO 
> 
> This is the part I'm really not clear about, remember I'm working with two 
> drives, booting to either the drive to windows or the drive to qubes. So, am 
> I following the advice here?: https://www.qubes-os.org/doc/multiboot/
>   - select custom layout, assign existing /boot partition as /boot, deselect 
> the 
> 'Format' option, continue with installation.   
> 
> Or, do I let Qubes install in automatic configuration and then manually 
> modify the grub file?
> 
> 
> Thanks,
> Patrick
> 

Sounds like what I did/do   with windows 10 ; since it doesn't involve
Grub ,  probably won't be a problem ..

In my case however,  the uefi, I believe doesn't label the drive with
the  drive name, but changes it to  "windows" or "qubes" , which
concerns me , as I think it incorrect, I think that may be how uefi
works  ymmv,  why not try it

what is a "windows uefi" ?
looks to me like
https://www.qubes-os.org/doc/multiboot

doesn't apply to you, its for single disk dual booting

-- 
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/2efb6aec-c949-f5fc-6d4c-7420f9a7d8f4%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: how do you clear "move/copy to other app vm" context windows

[John S.Recdep]

On 08/16/2018 08:32 AM, cubit wrote:
> Is there a way to copy the suggested VMs in the "move/copy to other app vm" 
> as I have a few entries that no longer exist and would like to get rid of 
> them?
> 
> 
> CuBit
> 

I suppose you've tried  qvm-sync-appmenus in dom0

and/or  in the VMM  "refresh applications" 


though, just a wild guess not an educated one

-- 
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/ab909792-06b3-a23a-caed-fe303502d44c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Incredible HD thrashing on 4.0

[Marcus Linsner]

On Thursday, August 16, 2018 at 10:06:54 PM UTC+2, Brendan Hoar wrote:
> On Thursday, August 16, 2018 at 3:21:27 PM UTC-4, Marcus Linsner wrote:
> > The good news is that I've realized that the OOM triggering was legit: I 
> > had firefox set to use 12 cores at once and 14GiB of RAM was clearly not 
> > enough! (8 and no ccache was good though - did compile it twice like so) 
> > 
> > The bad news is that I still don't know why the disk-read thrashing was 
> > happening for me, but I will default to blame the OOM (even though no swap 
> > was active, ie. I swapoff-ed the swap partition earlier) due to previous 
> > experience with OOM triggering on bare-metal hardware: I seem to remember 
> > SSD disk activity led being full-on during an impending OOM and everything 
> > freezing!
> 
> Maybe this applies:
> 
> https://askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap
> 
> [[if kswapd0 is taking any CPU and you do not have swap, the system is nearly 
> out of RAM and is trying to deal with the situation by (in practise) swapping 
> pages from executables. The correct fix is to reduce workload, add swap or 
> (preferably) install more RAM. Adding swap will improve performance because 
> kernel will have more options about what to swap to disk. Without swap the 
> kernel is practically forced to swap application code.]]
> 
> This could be a reason you only see reads hammering the drive, maybe?
> 
> Also worth remembering: every read is decrypting block(s) which takes some 
> CPU (even on systems with AES-NI support).
> 
> Brendan

Thank you Brendan! The following comment(from the webpage that you linked) 
explained the constant disk-reading best for me:

"For example, consider a case where you have zero swap and system is nearly 
running out of RAM. The kernel will take memory from e.g. Firefox (it can do 
this because Firefox is running executable code that has been loaded from disk 
- the code can be loaded from disk again if needed). If Firefox then needs to 
access that RAM again N seconds later, the CPU generates "hard fault" which 
forces Linux to free some RAM (e.g. take some RAM from another process), load 
the missing data from disk and then allow Firefox to continue as usual. This is 
pretty similar to normal swapping and kswapd0 does it.  " - Mikko Rantalainen 
Feb 15 at 13:08

$ sysctl vm.swappiness
vm.swappiness = 60

In retrospect, I apologize for hijacking this thread, because it now appears to 
me that my issue is totally different from the OP(even though the subject still 
applies):

On Friday, August 10, 2018 at 9:02:31 PM UTC+2, Kelly Dean wrote:
> 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 individual qubes doing ordinary bursts 
> of disk access, such as loading a program or accessing swap, which would 
> normally take just a few seconds on Qubes 3.2, but dom0 then massively 
> multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on for 
> minutes at a time, and in some cases, more than an hour.
> 
> iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1], 
> reading the disk at rates ranging from 10 to 50 MBps (max throughput of the 
> disk is about 100). At this rate, for how prolonged the thrashing is, it 
> could have read and re-read the entire virtual disk multiple times over, so 
> there's something extremely inefficient going on.
> 
> Is there any solution other than installing a SSD? I'd prefer not to have to 
> add hardware to solve a software performance regression.

-- 
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/c184a781-3883-443a-b719-6b6817a4de7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - Updated, just lost Tor Browser for Whonix-dvm??

[bm-2ctjsegdfzqngqwuqjswro6jrwlc9b3mn3]

On Wed, 15 Aug 2018 12:59:06 -0700 (PDT)
sm...@tutamail.com wrote:

> I just transitioned to the new Whonix 14 templates, everything was
> working great however I just updated both the -gw and -ws templates
> and lost the Tor Browser(AnonDist) from the whonix-ws-14-dvm after
> update? When I launch a "whonix-ws-14-dvm" browser I get a pop-up
> asking: "Tor Browser not installed/Start Tor Browser download?".
> 
> What I tried:
> 
> To customize the -dvm's in Debian and Fedora I have run the following
> to customize -dvm's (other then whonix):
> 
> [user@dom0 ~]$ qvm-run -a debian-dvm gnome-terminal
> 
> Then in new terminal of “-dvm” type “firefox” to launch firefox, then
> I customize the browser.
> 
> I tried the following with Whonix-dvm:
> [user@dom0 ~]$ qvm-run -a whonix-ws-14-dvm gnome-terminal
> 
> The problem I am having is:
> 1) The "whonix-ws-14-dvm" starts but no gnome terminal launches?
> 2) Since whonix doesn't use "Firefox" what would I type to launch the
> "Tor Browser"? Assuming I eventually get a gnome terminal to launch
> 3) How do I install the Tor Browser safely into either the template
> or -dvm?
> 
> Other notes:
> - I created an AppVM using the updated "whonix-ws-14" template,
> received a popup that "Tor Browser" is not installed, installed the
> oldest browser per the recommendation on the pop-up, however after
> installing another pop-up states: "Signature looks quite old
> already...check signature looks sane".  I was able to navigate to an
> Onion site, whonix check came back OK.
> 
> 
> Thanks again for the help...
> 


The same happened to me after updates. Running 'update-torbrowser' in
whonix-ws fixed the problem. 

-- 
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/3607F008-35B9-42BC-A7C1-A2E902625691%40mail.bitmessage.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Confused about verifying signatures

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-08-16 17:35, Andrew David Wong wrote:
> On 2018-08-16 15:47, Patrick Bouldin wrote:
>> Hi trying to validate 4.0. I downloaded the 
>> qubes-master-signing-key.asc and then not able to progress. I did 
>> find Joanna's qubes master signing key footprint, but I don't know 
>> how to compare or take the next step...
> 
>> I did this with 3.0 a few years ago but can't remember...
> 
>> I did check the web site and still don't know.
> 
>> Thanks.
> 
> 
> If you just want to see the fingerprint of the key you downloaded as a
> file so that you can compare it to the fingerprint you obtained
> through another channel, this is probably the simplest way:
> 
>   $ gpg2 qubes-master-signing-key.asc
>   gpg: WARNING: no command supplied.  Trying to guess what you mean ...
>   pub   rsa4096 2010-04-01 [SC]
> 427F11FD0FAA4B080123F01CDDFA1A3E36879494
>   uid   Qubes Master Signing Key
> 

If you're using gpg instead of gpg2, there's the --with-fingerprint
option:

  $ gpg --with-fingerprint qubes-master-signing-key.asc 
  gpg: keyring `/home/user/.gnupg/secring.gpg' created
  pub  4096R/36879494 2010-04-01 Qubes Master Signing Key
  Key fingerprint = 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlt1/gQACgkQ203TvDlQ
MDASEA//a1TzjaaAPwNS12GHWollY2WGqpSK7RZNEsHkBSJYPTaNayqOHXx2yzQ2
Re5uPgpHofCYxNx96VhKFDE9rIo17ozrLrr+ZywESDn5GoIzM7BtUaKTR5GQWZx1
E9vALH50GtNJAdb/SumOcdsDxrDj139wjcAuypWBDXK6lxF2hR/nDr7RZMxvfwTF
uixM4LP7zhwOafLAbhXsa9wyu6ZsooTicdiSit+iQPk15oxLGjUSncQcIYuRLdvX
yLht5/2ZPST1Jm9HyEEwOllMN4eFrMAc/StHhVxPWlUiqtr3xMki3IWZV+xi8sMh
Ri0HmASNzLn4JwNQnPFQqnT+Z4Im8tiH24w/T8eHhP2hLo8tEfd5aq26xl0NoRbU
Hcc69XXjzITQIi2d7YZHgtNgrml8zCjTRF+9p14cLyFFl2ISJsEZeus/egQWE6Rv
aRMR+IPDG8HqCWepV+Y/of3lb+uqd7SBVJdcRavf/Jrlf/9AOeCRDUteTGsiJE14
U9FksIiiZRclcHR+NFeZSbINvwlwNx2tO7o7YcbBxmqPMzsg20gHYfuI3GAnMY/R
yHX52v6sXcM/4Y08TrTTHV1l+/EPUOnOb3adaIejNyEiHB5WiQ3fgoEwpX3GkKTb
iCt4TJJKo6KRSG2EzMMLH0s69gGphqLtgC5+zEQg4X7NWpFzWX4=
=cBsO
-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/9ce6f7d7-47ca-8c8b-bc3b-01668d67eb56%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Confused about verifying signatures

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-08-16 15:47, Patrick Bouldin wrote:
> Hi trying to validate 4.0. I downloaded the 
> qubes-master-signing-key.asc and then not able to progress. I did 
> find Joanna's qubes master signing key footprint, but I don't know 
> how to compare or take the next step...
> 
> I did this with 3.0 a few years ago but can't remember...
> 
> I did check the web site and still don't know.
> 
> Thanks.
> 

If you just want to see the fingerprint of the key you downloaded as a
file so that you can compare it to the fingerprint you obtained
through another channel, this is probably the simplest way:

  $ gpg2 qubes-master-signing-key.asc
  gpg: WARNING: no command supplied.  Trying to guess what you mean ...
  pub   rsa4096 2010-04-01 [SC]
427F11FD0FAA4B080123F01CDDFA1A3E36879494
  uid   Qubes Master Signing Key

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlt1/BcACgkQ203TvDlQ
MDCmuA//Y7xSLlrHkdO4zLm+7FP3xyBFMCguQkVqLQ5JYcRuvCJRVtORHQL6V/rg
A7WL7pfOaADv9hT8uCgr/wMnjfYE2L3IwyL1l7MzxKDB0XjqE7e/0xwVXRIjj9ow
UynpuDQXsdiRn+Xyj52eLZiNUBrbuNbVjuTXIJTpuasAt0ZVYRLN8abv19EIbmqs
1LmNdIPoHGYW7oFPS64OiZ+phQgVMC28+dkIWF6xo3i9XETSTFvJhB3miwhNYYOq
Ge4Xg9fzFFoz2NTHMPvm7g66hoyTaz6kODFEX7r2Sn6uJVyF/lvBqujg3q2BBiKK
z1UlF/bGQiv9bcKYwgtyd6ipSoNlbTYGkZ3cTIcKA4X/gtVtFI8/mpI+0xG5iaPz
YWs9t3QQoUd/Z5SGZhT4D5aUyMwuo6+jxajNjS4mfjLNuPdbFEvPjNuAFwDamvKW
D0OQJoQ/DVvgVzfU/L0L3bH3GMiutZSyIW69/iZCgaLgUkxU8wduCN0T0o2RrxQz
00qn+LMlYJHe8d2omj1jPQBbuZQ+jetbsj2vZrsnfCVUylGZqzAxcqLJUtxn2NYn
oKYaqd0o9k2zkBgiQv1TEltcekG3h4mTmqa5c6OgJpt+U0dBARHscKdhWE64x/p6
ycAN9dHkpGVcV99PPVeNuh4EmOhxc5lrflUujeUzGS8mUmgqy2w=
=wZdA
-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/8b5041d3-9fb0-9605-374e-98ec0b1702b1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Samsung Notebook 9 NP900X5T-X01US

[Jascha Dub]

The laptop comes with Windows 10. To install had to disable TPM and enable
legacy boot and UEFI The installer would fail similarly to Issue  #3789 (
https://github.com/QubesOS/qubes-issues/issues/3789). To get the installer
to work had to wipe all of the Windows 10 partitions off the HD. Then
allowed to install cleanly.

Everything works except being able to control keyboard backlight which is
known issue with other distros as well with workarounds.

-- 
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/CAB%3DLajsv4V0%2B_xhwT5ZKKcAyYR3K-0BTdUFs74o-EMN1K0Q66A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-SAMSUNG_ELECTRONICS_CO___LTD_-900X5T-20180816-174918.yml
Description: application/yaml

[qubes-users] Re: Incredible HD thrashing on 4.0

[brendan . hoar]

On Thursday, August 16, 2018 at 3:21:27 PM UTC-4, Marcus Linsner wrote:
> The good news is that I've realized that the OOM triggering was legit: I had 
> firefox set to use 12 cores at once and 14GiB of RAM was clearly not enough! 
> (8 and no ccache was good though - did compile it twice like so) 
> 
> The bad news is that I still don't know why the disk-read thrashing was 
> happening for me, but I will default to blame the OOM (even though no swap 
> was active, ie. I swapoff-ed the swap partition earlier) due to previous 
> experience with OOM triggering on bare-metal hardware: I seem to remember SSD 
> disk activity led being full-on during an impending OOM and everything 
> freezing!

Maybe this applies:

https://askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap

[[if kswapd0 is taking any CPU and you do not have swap, the system is nearly 
out of RAM and is trying to deal with the situation by (in practise) swapping 
pages from executables. The correct fix is to reduce workload, add swap or 
(preferably) install more RAM. Adding swap will improve performance because 
kernel will have more options about what to swap to disk. Without swap the 
kernel is practically forced to swap application code.]]

This could be a reason you only see reads hammering the drive, maybe?

Also worth remembering: every read is decrypting block(s) which takes some CPU 
(even on systems with AES-NI support).

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/0be4cbfa-1899-4d6a-b0c0-bd1994482553%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: X470 and IOMMU Groups...

[taii...@gmx.com]

On 08/16/2018 10:18 AM, FaB wrote:
>>
 Hi, Taiidan! The OP seemed to recognize it was ideal to have devices in
>>
>>> separate IOMMU groups, so I assumed he was familiar with the warnings in
>>> https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues and
>>> just wondering if it was technically possible.
> 
> I am fully aware of the security problematics of PCI passthrough, but until
> there is a secure solution to passthrough GFX to a VM (Qubes 4.1 I hope !)
> I am going to continue this way and accept the security decline.

There won't really be.

The issue mainly comes from:

* Hostile firmware re-writes.
* Lack of FLR on most graphics devices.
* The additional complexity of IOMMU-GFX assignment vs regular IOMMU
assigned devices like a network device or HBA.

It isn't that bad if you only assign a single card to a single VM and if
you need it you need it.

Practical reality is that short of being assange or some other very high
profile person no one is going to waste such a high tech exploit on you
when there are much easier ways to go about things.

-- 
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/d956988e-d697-3585-0468-adfa912f6c19%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


0xDF372A17.asc
Description: application/pgp-keys

Re: [qubes-users] Re: X470 and IOMMU Groups...

[taii...@gmx.com]

On 08/16/2018 07:47 AM, Marcus Linsner wrote:
>>
>> I've observed that Qubes installation rarely ever succeeds on X370 
>> motherboards so I believe the same case applies to X470 motherboards with a 
>> higher chance of failure since it is newer. The reason for this I believe is 
>> because these high-end gaming motherboards have alot of functionalities/bugs 
>> that break/interfere with Qubes installation which is an awful letdown.
> 
> I've had no issues installing Qubes R4.0 several times(for fun) on Asus PRIME 
> X370-A motherboard. 
> 
> As an aside, this motherboard even has a setting to use Z370's Trusted 
> Platform Module (TPM) [1] - BIOS setting "Firmware-based Trusted Platform 
> Module (fTPM)", so I assume that I can set up Anti Evil Maid in Qubes but 
> haven't tried yet. 
> 
> [1] shown as Intel® Platform Trust Technology (Intel® PTT) [2] in this link: 
> https://www.intel.com/content/www/us/en/products/chipsets/desktop-chipsets/z370.html
> [2] PTT to TPM mapped in this link: 
> https://www.intel.com/content/www/us/en/support/articles/07452/mini-pcs.html
> 

fTPM is an ME application - it is fake security and usually won't work
with anything that wants a real TPM.

I of course always recommend purchasing a device with no black box
supervisor processors like ME/PSP.

-- 
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/72c2fe14-4d70-082f-fb57-42070ca3720e%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


0xDF372A17.asc
Description: application/pgp-keys

[qubes-users] Re: Incredible HD thrashing on 4.0

[Marcus Linsner]

On Thursday, August 16, 2018 at 8:03:52 PM UTC+2, Marcus Linsner wrote:
> On Thursday, August 16, 2018 at 7:50:14 PM UTC+2, Marcus Linsner wrote:
> > On Thursday, August 16, 2018 at 7:35:26 PM UTC+2, Marcus Linsner wrote:
> > > $ cat /proc/meminfo
> > > MemTotal:7454500 kB
> > > MemFree: 5635088 kB
> > > MemAvailable:6574676 kB
> > > Buffers:   53832 kB
> > > Cached:  1094368 kB
> > > SwapCached:0 kB
> > > Active:   724832 kB
> > > Inactive: 747696 kB
> > > Active(anon): 233816 kB
> > > Inactive(anon):95768 kB
> > > Active(file): 491016 kB
> > > Inactive(file):   651928 kB
> > > Unevictable:   73568 kB
> > > Mlocked:   73568 kB
> > > SwapTotal: 0 kB
> > > SwapFree:  0 kB
> > > Dirty:   292 kB
> > > Writeback: 0 kB
> > > AnonPages:398016 kB
> > > Mapped:54320 kB
> > > Shmem:  5256 kB
> > > Slab: 134680 kB
> > > SReclaimable:  74124 kB
> > > SUnreclaim:60556 kB
> > > KernelStack:4800 kB
> > > PageTables:10524 kB
> > > NFS_Unstable:  0 kB
> > > Bounce:0 kB
> > > WritebackTmp:  0 kB
> > > CommitLimit: 3727248 kB
> > > Committed_AS:1332236 kB
> > > VmallocTotal:   34359738367 kB
> > > VmallocUsed:   0 kB
> > > VmallocChunk:  0 kB
> > > HardwareCorrupted: 0 kB
> > > AnonHugePages: 0 kB
> > > ShmemHugePages:0 kB
> > > ShmemPmdMapped:0 kB
> > > CmaTotal:  0 kB
> > > CmaFree:   0 kB
> > > HugePages_Total:   0
> > > HugePages_Free:0
> > > HugePages_Rsvd:0
> > > HugePages_Surp:0
> > > Hugepagesize:   2048 kB
> > > DirectMap4k:  327644 kB
> > > DirectMap2M:14008320 kB
> > > DirectMap1G:   0 kB
> > 
> > I resumed the firefox compilation and noticed that the memory jumped back 
> > to 14GB again - I was sure it was more than that 7.4GB before:
> > 
> > $ cat /proc/meminfo 
> > MemTotal:   14003120 kB
> > MemFree: 4602448 kB
> > MemAvailable:6622252 kB
> > Buffers:  186220 kB
> > Cached:  1986192 kB
> > SwapCached:0 kB
> > Active:  7482024 kB
> > Inactive:1448656 kB
> > Active(anon):6667828 kB
> > Inactive(anon):95780 kB
> > Active(file): 814196 kB
> > Inactive(file):  1352876 kB
> > Unevictable:   73568 kB
> > Mlocked:   73568 kB
> > SwapTotal: 0 kB
> > SwapFree:  0 kB
> > Dirty:306392 kB
> > Writeback:  4684 kB
> > AnonPages:   6811888 kB
> > Mapped:   199164 kB
> > Shmem:  5340 kB
> > Slab: 239524 kB
> > SReclaimable: 177620 kB
> > SUnreclaim:61904 kB
> > KernelStack:5968 kB
> > PageTables:28612 kB
> > NFS_Unstable:  0 kB
> > Bounce:0 kB
> > WritebackTmp:  0 kB
> > CommitLimit: 7001560 kB
> > Committed_AS:8571548 kB
> > VmallocTotal:   34359738367 kB
> > VmallocUsed:   0 kB
> > VmallocChunk:  0 kB
> > HardwareCorrupted: 0 kB
> > AnonHugePages: 0 kB
> > ShmemHugePages:0 kB
> > ShmemPmdMapped:0 kB
> > CmaTotal:  0 kB
> > CmaFree:   0 kB
> > HugePages_Total:   0
> > HugePages_Free:0
> > HugePages_Rsvd:0
> > HugePages_Surp:0
> > Hugepagesize:   2048 kB
> > DirectMap4k:  327644 kB
> > DirectMap2M:14008320 kB
> > DirectMap1G:   0 kB
> > 
> > 
> > Oh man, I'm hitting that disk thrashing again after just a few minutes: 
> > 202MiB/sec reading, 0.0 writing.
> > 
> > Paused qube, reading stopped.
> > Resumed qube sooner than before and it's still thrashing...
> > 
> > It'a a fedora 28 template-based VM.
> > 
> > I shut down another VM and I thought dom0 crashed because it froze for like 
> > 10 sec before the notification message told me that that VM stopped.
> 
> Ok, I caught kswapd0 at 14% in a 'top' terminal on the offending qube, before 
> the disk thrashing begun(which froze all terminals too) and then the only 
> process at 100% after disk thrashing stopped! and here's the continuation of 
> the log, btw the thrashing only stopped after OOM killed the rustc 
> process(which, my guess was triggeding kswapd0 to use 100% cpu or what):
> 
> [ 6871.435899] systemd-coredum: 4 output lines suppressed due to ratelimiting
> [ 6871.485869] audit: type=1130 audit(1534438842.909:179): pid=1 uid=0 
> auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" 
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
> [ 6871.486357] audit: type=1130 audit(1534438842.910:180): pid=1 uid=0 
> auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" 
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [ 7076.504392] kauditd_printk_skb: 5 callbacks suppressed
> [ 

Re: [qubes-users] VMWare vmdk converted to raw image - Will Not Boot (Windows or Linux)

[joeviocoe]

On Wednesday, 15 August 2018 06:52:02 UTC-4, awokd  wrote:

> 
> > $ qvm-create --verbose Win10 --class StandaloneVM --property
> > virt_mode=hvm --property kernel='' --property memory=4096 --property
> > maxmem=4096 --label=red --root-copy-from Win10.raw
> 
> How large is the root created when you use this method? Default is only
> 10GB, but both your images are much larger. Try manually creating the HVM
> without the copy, resizing the root volume to match the raw size, then
> "copy Win10.raw /dev/mapper/qubes_dom0-vm--Win10--root".

Yes.  Thank you.  That did it.

Set the system storage max size to greater than the filesytem size of the raw 
image.
dd if=Win10.raw of=/dev/mapper/qubes_dom0-vm--Win10--root

Now both boot.
 
I guess system storage should be a pref option in qvm-create, so we can still 
use --root-copy-from.  Or, better yet, determine size automatically and prompt 
the user to accept the larger storage size.

-- 
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/6e3978e1-82bc-4394-8d56-8655b4987181%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Audio and suspend issues; misc questions

[AJ Jordan]

Hi all,

I've just recently installed Qubes on a brand-new System76 Oryx Pro
(it's on my list to send an HCL report soon). It's working ok overall
but I've run into a couple of issues and questions and was hoping for
some help resolving them. I'm including most of them all in one email
in an attempt to flood people's inboxes less; hope that's okay.

Thanks in advance! I'm sure I'm forgetting something, but that's the
way it goes :P

Cheers,

-AJ

=== SOUND ===

Audio output does not work. Playing audio in an AppVM and running
`pavucontrol` in dom0 clearly shows the little volume indicator for
the VM fluctuating, but nothing actually comes out of the speakers. So
it seems like VM PulseAudio -> dom0 PulseAudio is working OK, but dom0
PulseAudio isn't outputting anything.

All volumes in the "Playback" tab are set to 100% and are unmuted. In
the "Output Devices" tab, it's unmuted and set to 100%, and I can see
the volume indicator going up and down. Plugging in headphones does
not help.

Some system information:

$ lspci | grep Audio
00:1f.3 Audio device: Intel Corporation Device a348 (rev 10)

$ ls /sys/class/sound/
card0 controlC0 hwC0D0 pcmC0D0c pcmC0D0p pcmC0D1p seq timer

I'm on a mostly fresh Qubes 4.0 install (this issue was present as
soon as I installed).

=== SUSPEND ===

Resuming from suspend does not work. I just get a black screen (IIRC
it *does* turn on, but remains blank; I can retest if desired but
obviously it's annoying to do so). The computer remains unresponsive
at that point and I have to hold down the power button. Honestly, I'm
not even sure where to start diagnosing this issue. I'd be happy to do
anything that might provide more information.

=== DOM0 SOFTWARE ===

It's unclear to me exactly how bad I should feel installing stuff into
dom0. Specifically, I've installed a program called Redshift[1]
through qubes-dom0-update (i.e. the Fedora repos).

It's my understanding that this *should* be okay, because the software
is coming from a trusted source (Fedora), and isn't being exposed to
VMs in any way. Is that correct?

 [1]: http://jonls.dk/redshift/

=== DETACHING USB BLOCK DEVICES ===

If I attach a USB block device to a Qube and mount then unmount the
filesystem, do I really need to detach the block device from the Qube?
Or can I just pull the drive?

-- 
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/20180816185636.xqyjlwugir6ls7zs%40steevie-cloud.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] how do you clear "move/copy to other app vm" context windows

[cubit]

Is there a way to copy the suggested VMs in the "move/copy to other app vm" as 
I have a few entries that no longer exist and would like to get rid of them?


CuBit

-- 
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/LK3-fk6--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Incredible HD thrashing on 4.0

[Marcus Linsner]

On Thursday, August 16, 2018 at 7:50:14 PM UTC+2, Marcus Linsner wrote:
> On Thursday, August 16, 2018 at 7:35:26 PM UTC+2, Marcus Linsner wrote:
> > $ cat /proc/meminfo
> > MemTotal:7454500 kB
> > MemFree: 5635088 kB
> > MemAvailable:6574676 kB
> > Buffers:   53832 kB
> > Cached:  1094368 kB
> > SwapCached:0 kB
> > Active:   724832 kB
> > Inactive: 747696 kB
> > Active(anon): 233816 kB
> > Inactive(anon):95768 kB
> > Active(file): 491016 kB
> > Inactive(file):   651928 kB
> > Unevictable:   73568 kB
> > Mlocked:   73568 kB
> > SwapTotal: 0 kB
> > SwapFree:  0 kB
> > Dirty:   292 kB
> > Writeback: 0 kB
> > AnonPages:398016 kB
> > Mapped:54320 kB
> > Shmem:  5256 kB
> > Slab: 134680 kB
> > SReclaimable:  74124 kB
> > SUnreclaim:60556 kB
> > KernelStack:4800 kB
> > PageTables:10524 kB
> > NFS_Unstable:  0 kB
> > Bounce:0 kB
> > WritebackTmp:  0 kB
> > CommitLimit: 3727248 kB
> > Committed_AS:1332236 kB
> > VmallocTotal:   34359738367 kB
> > VmallocUsed:   0 kB
> > VmallocChunk:  0 kB
> > HardwareCorrupted: 0 kB
> > AnonHugePages: 0 kB
> > ShmemHugePages:0 kB
> > ShmemPmdMapped:0 kB
> > CmaTotal:  0 kB
> > CmaFree:   0 kB
> > HugePages_Total:   0
> > HugePages_Free:0
> > HugePages_Rsvd:0
> > HugePages_Surp:0
> > Hugepagesize:   2048 kB
> > DirectMap4k:  327644 kB
> > DirectMap2M:14008320 kB
> > DirectMap1G:   0 kB
> 
> I resumed the firefox compilation and noticed that the memory jumped back to 
> 14GB again - I was sure it was more than that 7.4GB before:
> 
> $ cat /proc/meminfo 
> MemTotal:   14003120 kB
> MemFree: 4602448 kB
> MemAvailable:6622252 kB
> Buffers:  186220 kB
> Cached:  1986192 kB
> SwapCached:0 kB
> Active:  7482024 kB
> Inactive:1448656 kB
> Active(anon):6667828 kB
> Inactive(anon):95780 kB
> Active(file): 814196 kB
> Inactive(file):  1352876 kB
> Unevictable:   73568 kB
> Mlocked:   73568 kB
> SwapTotal: 0 kB
> SwapFree:  0 kB
> Dirty:306392 kB
> Writeback:  4684 kB
> AnonPages:   6811888 kB
> Mapped:   199164 kB
> Shmem:  5340 kB
> Slab: 239524 kB
> SReclaimable: 177620 kB
> SUnreclaim:61904 kB
> KernelStack:5968 kB
> PageTables:28612 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit: 7001560 kB
> Committed_AS:8571548 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:   0 kB
> VmallocChunk:  0 kB
> HardwareCorrupted: 0 kB
> AnonHugePages: 0 kB
> ShmemHugePages:0 kB
> ShmemPmdMapped:0 kB
> CmaTotal:  0 kB
> CmaFree:   0 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> DirectMap4k:  327644 kB
> DirectMap2M:14008320 kB
> DirectMap1G:   0 kB
> 
> 
> Oh man, I'm hitting that disk thrashing again after just a few minutes: 
> 202MiB/sec reading, 0.0 writing.
> 
> Paused qube, reading stopped.
> Resumed qube sooner than before and it's still thrashing...
> 
> It'a a fedora 28 template-based VM.
> 
> I shut down another VM and I thought dom0 crashed because it froze for like 
> 10 sec before the notification message told me that that VM stopped.

Ok, I caught kswapd0 at 14% in a 'top' terminal on the offending qube, before 
the disk thrashing begun(which froze all terminals too) and then the only 
process at 100% after disk thrashing stopped! and here's the continuation of 
the log, btw the thrashing only stopped after OOM killed the rustc 
process(which, my guess was triggeding kswapd0 to use 100% cpu or what):

[ 6871.435899] systemd-coredum: 4 output lines suppressed due to ratelimiting
[ 6871.485869] audit: type=1130 audit(1534438842.909:179): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[ 6871.486357] audit: type=1130 audit(1534438842.910:180): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 7076.504392] kauditd_printk_skb: 5 callbacks suppressed
[ 7076.504393] audit: type=1101 audit(1534439047.928:186): pid=5658 uid=1000 
auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix acct="user" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
[ 7076.504502] audit: type=1123 audit(1534439047.928:187): pid=5658 uid=1000 
auid=1000 ses=1 msg='cwd="/home/user" 

[qubes-users] Re: Incredible HD thrashing on 4.0

[Marcus Linsner]

On Thursday, August 16, 2018 at 7:35:26 PM UTC+2, Marcus Linsner wrote:
> $ cat /proc/meminfo
> MemTotal:7454500 kB
> MemFree: 5635088 kB
> MemAvailable:6574676 kB
> Buffers:   53832 kB
> Cached:  1094368 kB
> SwapCached:0 kB
> Active:   724832 kB
> Inactive: 747696 kB
> Active(anon): 233816 kB
> Inactive(anon):95768 kB
> Active(file): 491016 kB
> Inactive(file):   651928 kB
> Unevictable:   73568 kB
> Mlocked:   73568 kB
> SwapTotal: 0 kB
> SwapFree:  0 kB
> Dirty:   292 kB
> Writeback: 0 kB
> AnonPages:398016 kB
> Mapped:54320 kB
> Shmem:  5256 kB
> Slab: 134680 kB
> SReclaimable:  74124 kB
> SUnreclaim:60556 kB
> KernelStack:4800 kB
> PageTables:10524 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit: 3727248 kB
> Committed_AS:1332236 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:   0 kB
> VmallocChunk:  0 kB
> HardwareCorrupted: 0 kB
> AnonHugePages: 0 kB
> ShmemHugePages:0 kB
> ShmemPmdMapped:0 kB
> CmaTotal:  0 kB
> CmaFree:   0 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> DirectMap4k:  327644 kB
> DirectMap2M:14008320 kB
> DirectMap1G:   0 kB

I resumed the firefox compilation and noticed that the memory jumped back to 
14GB again - I was sure it was more than that 7.4GB before:

$ cat /proc/meminfo 
MemTotal:   14003120 kB
MemFree: 4602448 kB
MemAvailable:6622252 kB
Buffers:  186220 kB
Cached:  1986192 kB
SwapCached:0 kB
Active:  7482024 kB
Inactive:1448656 kB
Active(anon):6667828 kB
Inactive(anon):95780 kB
Active(file): 814196 kB
Inactive(file):  1352876 kB
Unevictable:   73568 kB
Mlocked:   73568 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty:306392 kB
Writeback:  4684 kB
AnonPages:   6811888 kB
Mapped:   199164 kB
Shmem:  5340 kB
Slab: 239524 kB
SReclaimable: 177620 kB
SUnreclaim:61904 kB
KernelStack:5968 kB
PageTables:28612 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 7001560 kB
Committed_AS:8571548 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  327644 kB
DirectMap2M:14008320 kB
DirectMap1G:   0 kB


Oh man, I'm hitting that disk thrashing again after just a few minutes: 
202MiB/sec reading, 0.0 writing.

Paused qube, reading stopped.
Resumed qube sooner than before and it's still thrashing...

It'a a fedora 28 template-based VM.

I shut down another VM and I thought dom0 crashed because it froze for like 10 
sec before the notification message told me that that VM stopped.

-- 
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/a0e7f45a-29fa-4330-ab43-eb4f31511bce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Incredible HD thrashing on 4.0

[Marcus Linsner]

On Friday, August 10, 2018 at 9:02:31 PM UTC+2, Kelly Dean wrote:
> 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 individual qubes doing ordinary bursts 
> of disk access, such as loading a program or accessing swap, which would 
> normally take just a few seconds on Qubes 3.2, but dom0 then massively 
> multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on for 
> minutes at a time, and in some cases, more than an hour.
> 
> iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1], 
> reading the disk at rates ranging from 10 to 50 MBps (max throughput of the 
> disk is about 100). At this rate, for how prolonged the thrashing is, it 
> could have read and re-read the entire virtual disk multiple times over, so 
> there's something extremely inefficient going on.
> 
> Is there any solution other than installing a SSD? I'd prefer not to have to 
> add hardware to solve a software performance regression.

Interestingly, I've just encountered this thrashing, but on SSD(it's just 
reading 192MiB/sec constantly), Qubes R4.0 up to date, inside a qube while 
compiling firefox: typing in any of 3 of its terminal windows does not even 
echo anything and the firefox compilation terminal is frozen; the swap (of 1G) 
was turned off a while ago (via swapoff); I used Qube Manager to Pause the 
offending cube and the thrashing stopped. I don't see much on logs.

Ok so I resumed the qube, the thrashing resumed for a few seconds then stopped 
and all terminals were alive again (I can type into them). The log spewed some 
new things (since the updatedb audit which was last while Paused), I'm 
including some long lines from before, note that the log after the unpause 
starts from "[ 6862.846945] INFO: rcu_sched self-detected stall on CPU", as 
follows:


[0.00] Linux version 4.14.57-1.pvops.qubes.x86_64 (user@build-fedora4) 
(gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Mon Jul 23 16:28:54 
UTC 2018
[0.00] Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 
rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 nopat

...

[ 2769.581919] audit: type=1101 audit(1534434741.005:133): pid=10290 uid=1000 
auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix acct="user" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[ 2769.582396] audit: type=1123 audit(1534434741.005:134): pid=10290 uid=1000 
auid=1000 ses=1 msg='cwd="/home/user" cmd=737761706F202F6465762F7876646331 
terminal=pts/3 res=success'
[ 2769.582525] audit: type=1110 audit(1534434741.006:135): pid=10290 uid=0 
auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[ 2769.583384] audit: type=1105 audit(1534434741.007:136): pid=10290 uid=0 
auid=1000 ses=1 msg='op=PAM:session_open 
grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix 
acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 
res=success'
[ 2776.388700] audit: type=1106 audit(1534434747.812:137): pid=10290 uid=0 
auid=1000 ses=1 msg='op=PAM:session_close 
grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix 
acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 
res=success'
[ 2776.388735] audit: type=1104 audit(1534434747.812:138): pid=10290 uid=0 
auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[ 4093.008056] audit: type=1116 audit(1534436064.432:139): pid=29167 uid=0 
auid=4294967295 ses=4294967295 msg='op=add-group id=982 
exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=success'
[ 4093.030620] audit: type=1132 audit(1534436064.454:140): pid=29167 uid=0 
auid=4294967295 ses=4294967295 msg='op=add-shadow-group id=982 
exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=success'
[ 4093.304708] audit: type=1130 audit(1534436064.728:141): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=run-rfbdacad57c5f4bc183d36a7c402c9ae7 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=success'
[ 4094.576065] audit: type=1130 audit(1534436065.999:142): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=man-db-cache-update comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 4094.576138] audit: type=1131 audit(1534436065.999:143): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=man-db-cache-update comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 4094.577822] audit: type=1131 audit(1534436066.001:144): pid=1 uid=0 
auid=4294967295 ses=4294967295 

[qubes-users] Re: Whonix 14 - Updated, just lost Tor Browser for Whonix-dvm??

[smcmj]

Thanks Patrick...

Got it working! I went to the whonix-ws-14 template, added "Tor Browser 
Downloader (AnonDist)" to list of applications, then clicked on "Tor Browser 
Downloader (AnonDist)", the Tor Browser downloaded.

This then populated the whonix-ws-14-dvm with the browser.

Launched the "Tor Browser" as a -dvmno issues!

Thanks again!  

-- 
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/cac9d02d-6832-4590-9fa5-cf218dd73c24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Suggested order for loading Qubes 4.0?

[Patrick Bouldin]

Hello, I got some great advice about having two hard drives since I want 
Windows on one drive and qubes on another. So I now have a good I7 laptop with 
two - 1/2 TB SSDs. I had in mind to load it this way, is the following correct?

I'm starting with both SSDs empty, no OS on either.

1 Physically install both drives

2 Install Windows on disk 1 after booting to flash drive with windows ISO

3 Unplug windows based SSD drive just to be sure I'm on the right drive next

4 Boot to bios, modify bios to change 2nd SSD (to be Qubes) FROM Windows UEFI 
to other OS (correct?)

5 Boot to a flash drive loaded with the Qubes 4.0 install ISO 

This is the part I'm really not clear about, remember I'm working with two 
drives, booting to either the drive to windows or the drive to qubes. So, am I 
following the advice here?: https://www.qubes-os.org/doc/multiboot/
  - select custom layout, assign existing /boot partition as /boot, deselect 
the 
'Format' option, continue with installation.   

Or, do I let Qubes install in automatic configuration and then manually modify 
the grub file?


Thanks,
Patrick

-- 
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/f2522966-130c-4bec-9f78-2dcb54b58d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: X470 and IOMMU Groups...

[FaB]

>
> >>Hi, Taiidan! The OP seemed to recognize it was ideal to have devices in
>
>>separate IOMMU groups, so I assumed he was familiar with the warnings in
>>https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues and
>>just wondering if it was technically possible.

I am fully aware of the security problematics of PCI passthrough, but until
there is a secure solution to passthrough GFX to a VM (Qubes 4.1 I hope !)
I am going to continue this way and accept the security decline.

On Thursday, August 16, 2018 at 1:47:15 PM UTC+2, Marcus Linsner wrote:
> >
> > I've observed that Qubes installation rarely ever succeeds on X370
motherboards so I believe the same case applies to X470 motherboards with a
higher chance of failure since it is newer. The reason for this I believe
is because these high-end gaming motherboards have alot of
functionalities/bugs that break/interfere with Qubes installation which is
an awful letdown.
>
> I've had no issues installing Qubes R4.0 several times(for fun) on Asus
PRIME X370-A motherboard.
My bad: I just realized you were talking about X370 not Z370, and I've
typoed Z370-A above

Qubes 4.0 installs great on X470 Taichi Ultimate (Compatibility Support
Module mode, didn't try true UEFI) and R7 2700 ! GFX passthrough of AMD
5850 in Windows 10 Guest on xl instructions works too. I continue the
testing before posting a complete HCL of the platform. Some error messages
to sort out.

Thanks for the help :)


>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/qubes-users/chNyDUt5suI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ms
> gid/qubes-users/931176ba-4506-4f88-b5b6-5470069d4d94%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADCAy78U1TUKhkjXZixnG_TF-HtrocBOjw2eCyxRsoyhqLto_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Both dVM gnome-terminals are not launching

[Marcus Linsner]

On Friday, June 1, 2018 at 11:31:14 PM UTC+2, qube...@go-bailey.com wrote:
> The Qubes docs at:
> 
> https://www.qubes-os.org/doc/dispvm-customization/
> 
> note the following for disposable vms:
> 
> __
> 
> Note that currently only applications whose main process keeps running 
> until you close the application (i.e. do not start a background process 
> instead) will work. One of known examples of incompatible applications 
> is GNOME Terminal (shown on the list as “Terminal”). Choose different 
> terminal emulator (like XTerm) instead.

Also nautilus (shown on the list as "Files") even though its main process (at 
least when run from another terminal) doesn't return (like gnome-terminal does) 
until its window is closed (actually 11 seconds after its window is closed: try 
"time nautilus; echo returned" and alt+f4 the window as soon as it appears - 
shows like 13 seconds then "returned"). Can anyone explain?

-- 
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/03d443e6-0bef-45c3-a89a-8e1f6a2da69a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

[joeviocoe]

I love the new options.  It works great to open 3 luks volumes on boot now.  2 
of which have an LVM volume group for qubes, the 3rd just an extra ext4 volume.

Two questions:
1)  Can you execute multiple cryptsetup commands at the same time?  It has to 
wait a few seconds for each one in sequence, which lengthens the overall boot 
time.  Or would there be a problem if the script exits before all required luks 
volumes are open?  Maybe run cryptsetup commands with &, then finish by 
checking if all commands are complete.

2)   I would like a stealth mode where the default prompt is for the luks 
passphrase, just like it would be without your module.  In the background, 
looking for the yubikey.  When found, change the prompt to ask for the yubikey 
password.  But then systemd-ask-password would need to be something that can be 
cancelled/replaced by script, is that possible?  The other option would be to 
not change the prompt at all, and just run the ykchalresp command if the 
yubikey is detected, and skip it if not.

Let me know what you think.  
And thank you again for the hard work.

-- 
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/37b463a3-0cf7-4caa-bf5d-c0181f9bd3b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: X470 and IOMMU Groups...

[Marcus Linsner]

On Thursday, August 16, 2018 at 1:47:15 PM UTC+2, Marcus Linsner wrote:
> > 
> > I've observed that Qubes installation rarely ever succeeds on X370 
> > motherboards so I believe the same case applies to X470 motherboards with a 
> > higher chance of failure since it is newer. The reason for this I believe 
> > is because these high-end gaming motherboards have alot of 
> > functionalities/bugs that break/interfere with Qubes installation which is 
> > an awful letdown.
> 
> I've had no issues installing Qubes R4.0 several times(for fun) on Asus PRIME 
> X370-A motherboard. 
My bad: I just realized you were talking about X370 not Z370, and I've typoed 
Z370-A above

-- 
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/931176ba-4506-4f88-b5b6-5470069d4d94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: X470 and IOMMU Groups...

[Marcus Linsner]

> 
> I've observed that Qubes installation rarely ever succeeds on X370 
> motherboards so I believe the same case applies to X470 motherboards with a 
> higher chance of failure since it is newer. The reason for this I believe is 
> because these high-end gaming motherboards have alot of functionalities/bugs 
> that break/interfere with Qubes installation which is an awful letdown.

I've had no issues installing Qubes R4.0 several times(for fun) on Asus PRIME 
X370-A motherboard. 

As an aside, this motherboard even has a setting to use Z370's Trusted Platform 
Module (TPM) [1] - BIOS setting "Firmware-based Trusted Platform Module 
(fTPM)", so I assume that I can set up Anti Evil Maid in Qubes but haven't 
tried yet. 

[1] shown as Intel® Platform Trust Technology (Intel® PTT) [2] in this link: 
https://www.intel.com/content/www/us/en/products/chipsets/desktop-chipsets/z370.html
[2] PTT to TPM mapped in this link: 
https://www.intel.com/content/www/us/en/support/articles/07452/mini-pcs.html

-- 
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/5c2ce6f6-39a5-4259-94ef-3911689a8260%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

[qubes-fan]

Hi Patrick, I summed up how I understand it. Correct me if I am wrong:

- I back up the whonix(13) VMs of choice
- I clone the sys-whonix, anon-whonix, whonix-ws and whonix-gw to -backup 
(whonix-gw is a base template for the sys whonix, and must be deleted before 
install procedure too, right?) 
- I assign sys-whonix-backup to whonix-gw-backup template; anon-whonix-backup 
to whonix-ws-backup template, so they dont suffer the deletion of the whonix-13 
templates
- delete the anon-whonix and sys-whonix VMs
- detele whonix-ws and whonix-gw templates
- [user@dom0 ~]$ sudo qubesctl state.sls qvm.anon-whonix 
- if error appears: 
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
qubes-mgmt-salt-dom0-virtual-machines
-if needed, edit the /etc/yum.repos.d/qubes-templates.repo as per guide
-  clone the -backup VMs to its original names like sys-whonix-backup to 
sys-whonix, and anon-whonix-backup to anon-whonix
- assign new renamed sys-whonix to whonix-gw(14) and anon-whonix to 
whonix-ws(14) templates
- delete anon-whonix-backup, sys-whonix-backup, whonix-ws-backup, 
whonix-gw-backup

Do I get it right?
Thank you
 

Aug 16, 2018, 12:57 PM by qubes-...@tutanota.com 
:c

> Hi Patrick, should one switch the Qubes Tor networking backed normally by the 
> sys-whonix to newly created sys-whonix-backup? It make sense to 
> update/upgrade whonix through Tor.
> thx
>
> Aug 14, 2018, 10:10 PM by > patrick-mailingli...@whonix.org 
> > :
>
>> This is completely untested. Let me know what you think and if this
>> works for you.
>>
>> * A backup of all Qubes VMs using the usual Qubes backup mechanism
>> (independent from below) is advisable anyhow.
>>
>> * One who mind about their contents could clone their sys-whonix to
>> sys-whonix-backup and clone their anon-whonix to anon-whonix-backup.
>> Those who don't mind about their contents probably don't have this issue
>> anyhow?
>>
>> * Then delete anon-whonix and sys-whonix.
>>
>> * Then proceed as per >> https://www.whonix.org/wiki/Qubes/Install 
>> 
>>
>> * Then delete the newly created sys-whonix / anon-whonix.
>>
>> * Clone sys-whonix-backup to sys-whonix.
>>
>> * Clone anon-whonix-backup to anon-whonix.
>>
>> * Finally delete superfluous sys-whonix-backup / anon-whonix-backup.
>>
>> -- 
>> 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/c99cf0c7-5fcd-f75c-cc61-3cb8ebf5a703%40whonix.org
>>  
>> >>
>>  .
>> For more options, visit >> https://groups.google.com/d/optout 
>> >> .
>>
>
>

-- 
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/LK1UdW6--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

[Patrick Schleizer]

qubes-...@tutanota.com:
> Hi Patrick, should one switch the Qubes Tor networking backed normally by the 
> sys-whonix to newly created sys-whonix-backup? It make sense to 
> update/upgrade whonix through Tor.
> thx

If you manage to do that, sure.

-- 
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/c03beeec-6dcc-1a22-f952-2d229bb4a735%40whonix.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

[qubes-fan]

Hi Patrick, should one switch the Qubes Tor networking backed normally by the 
sys-whonix to newly created sys-whonix-backup? It make sense to update/upgrade 
whonix through Tor.
thx

Aug 14, 2018, 10:10 PM by patrick-mailingli...@whonix.org:

> This is completely untested. Let me know what you think and if this
> works for you.
>
> * A backup of all Qubes VMs using the usual Qubes backup mechanism
> (independent from below) is advisable anyhow.
>
> * One who mind about their contents could clone their sys-whonix to
> sys-whonix-backup and clone their anon-whonix to anon-whonix-backup.
> Those who don't mind about their contents probably don't have this issue
> anyhow?
>
> * Then delete anon-whonix and sys-whonix.
>
> * Then proceed as per > https://www.whonix.org/wiki/Qubes/Install 
> 
>
> * Then delete the newly created sys-whonix / anon-whonix.
>
> * Clone sys-whonix-backup to sys-whonix.
>
> * Clone anon-whonix-backup to anon-whonix.
>
> * Finally delete superfluous sys-whonix-backup / anon-whonix-backup.
>
> -- 
> 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/c99cf0c7-5fcd-f75c-cc61-3cb8ebf5a703%40whonix.org
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

-- 
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/LK1NaJx--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] [Qubes 4.0/Kali] Typefont problem on the gnome-terminal

[schwoereraxel]

Hello.
I installed Kali via Katoolin based on Debian 9, and when I run the terminal on 
Kali, I have a typefont problem.
Here's a screen of comparison between Debian 9 terminal and Kali's terminal.
https://www.noelshack.com/2018-33-4-1534416556-terminal.png

I remember that I didn't have this problem on Qubes 3.2.
I already checked typefont of Kali via gnome-tweak-tool but it has the same 
typefont of Debian 9.

I would like to have the same typefont as Debian 9 on Kali's terminal.
Anybody have an idea to resolve this ? 

Thanks.
Axel

-- 
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/bf2e0576-703d-41ca-8f90-b12ee5b2b35b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [Qubes 4.0] How to reinstall an AppVM ?

[schwoereraxel]

Le mardi 14 août 2018 16:14:44 UTC+2, Unman a écrit :
> On Tue, Aug 14, 2018 at 05:45:09AM -0700, schwoerera...@gmail.com wrote:
> > Hello.
> > I've installed Qubes 4.0 and it seems that the AppVM work is bugged.
> > I cannot run an application on this VM, no matter the template...
> > The other VMs (untrusted, personal...) works.
> > So I want to know if it possible to reinstall this AppVM ?
> > Axel 
> > 
> 
> There's nothing special about "work" - you can just remove it with
> 'qvm-remove' and then create another with the same name if you want.
>  
> Check the netvm, firewall and template settings match what you want.
Thanks for your answer Unman.
So I did that and now it's working.
I wanted to do that, but I thought it was possible to reinstall an AppVM.

-- 
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/fabaa183-e20c-4647-b637-4de7c3ea8f53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is Qubes vulnerable to CVE-2018-3620?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Laprise:
> On 08/15/2018 08:40 AM, Rusty Bird wrote:
> > To me as a layman, it looks like Qubes is indeed vulnerable to the
> > XSA-273 data leak, and that fixing it involves
> > 
> > 1. disabling hyperthreading (by adding smt=off to the Xen command line)
> > 2. AND upgrading Intel microcode to 20180807
> 
> On #2, assuming Intel has still abandoned Ivy Bridge and earlier CPUs, I
> wonder if this makes the CoreBoot targeted systems essentially
> unsafe/unusable.

Apparently, there are microcode updates for Ivy Bridge (page 10) and
even Sandy Bridge (page 14):

https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf

> Very bad.

Maybe slightly less so. :)

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbdUnbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf8P8P/3YFam7dyux4Qb4AuzzXX1/i
AV243309HUgr/HXKvQMuOjXnItOcptg/J56lxlNZg4vrgXAEVr1YPMjEFkcgC/9l
iLLV1W76vvURQcEb7FLqAI+UC6L1Pm9Um5qSAHzcY41kE9ASSz1AcEH4abVp6iCB
b3o2YWlMN4Bz9HQq03jb5WD/qoumXdUdmASsTWDA0s9h9TIDrYSXyUJCXg/OAxyO
qBfbfIAeTL7IZ6UB5ewIeGK/lZujmd0c3jhyfQh+7t1/nTBccdz4xK65DKhbxEVY
NIAFj5K2qeZXtxqOGa3XIo8b5oiLsDAQ1uSBJfgC9D325qnROSM5uebIHIOCSixB
su7FjBXu9F5b0l09mib2CmmhrZdo1hf42kxHl/MTo6H8gwpUTO+pxvxcXDouBrEg
Y11YT/j2ux7ugaP6KYML8G3dzXD1GGTENaLD7p4p7hPNwK2QPRcnDWWCZ/cHxOQj
FdCpCz2vBaqy3rPxHu6ujVYCBBBJVMBUsoeH4yhKvkojwAPmIT4r8GYq3epfYU+9
IrzQ8ARKnRpHOqSrAD+9x1AikaNePi5SYsfg8W+ZcZpD767QTFMbZ3mb35oqJEbN
Vg9BCcj1OOVuc/mG+hI3Ki1u3AS/D0RRMKg/fInuTJ4e2N6Z9S8U1dnx/yblVT/X
bAKRaM0Z+0V+Og7C5VS0
=T78o
-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/20180816095435.GB1219%40mutt.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is Qubes vulnerable to CVE-2018-3620?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sphere:
> I have hyperthreading disabled on my BIOS, do I still have to add
> that option to Xen command line?

Disabling it in the BIOS is okay too, according to the XSA.

> By pull request you mean, it's still being grabbed for use and
> installation using qubes-dom0-update right?

Yes, the official microcode package for qubes-dom0-update hasn't been
built/uploaded yet. You could build it yourself with qubes-builder
(after applying the patch from the GitHub pull request), but I think
it's pointless as long as there's no updated Xen package to actually
use the new LD1_FLUSH microcode instruction.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbdUjoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfnLcP/3m8dHksgWS6QW+rDSMpv1tD
4dVpPf76cihRlJpDttXucU7rfqTaldzF6ytIlTHCoZYpa06fOKsqmcKYZ6HE7fn2
iGCCFdDKao+DDfvP3caNupRs4DCD0Z2H1VLXZHwWVniN/s2MVEIv8BN5nWB0HvpH
2R45/lKC5BjMq0l2i42tPp3Nm/CjDbh4X/etqrx2p729Ykw9TTJCkPO1diImdu9N
CYzvA5amIduDRnJrNanBZKANjetHnNQysmEbGXWndgbVshd6JF53zq9CcgArHKZp
LqadTe+d1ayoAaRidVdD+I72h/1wjGDVx2OVcrtVKq6hhqJ24YQHlHO0XKDQfmK3
5xzxgjx9SlFwVw7u9a4osxsmExSMpuXA+9wdmegbNJoFmKgvIfYFLLrWrtvgN2pU
Cvhxbmb7+MtbwVcN9Xlo2LbgKA/bAJ0dRgKcuAWZYH0ceo2tokfKu1GT5asSI8bJ
QHlqE68r8SVZrU7hic6qfaqA2U1MPjJJSh7k19HduhrkwUYL8o9Tzpjgz4mqfAod
hnb+H1GsqHRA8eT4ZyG7YQ5aB5PxBZHFOydAPAfmxjkloEtV78mbuzfWM5bAa8EW
kZ4QRNSY1msm3h6NeJIZroGS1/PBtaDBQXwwiXJ0FmkX5AvVvJ2hltk8VNS1epdj
leeMYghualtPH8s7ka3L
=P5jC
-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/20180816095032.GA1219%40mutt.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

[__ __]

I've added a fallback option now that, if enabled, will prompt for the LUKS
passphrase if no yubikey was found within the configured time.
You can also specify the yubikey slot to use in the config now. And i've
improved the message sending functions.

Regards
the2nd

On Wed, Aug 15, 2018 at 10:29 PM, __ __  wrote:

> Good to know that it works now. 
>
> Maybe i should add an option to make my module work without the yubikey in
> case the yubikey is lost or otherwise not available. This should not be
> hard to implement..
>
> Joeviocoe Gmail  schrieb am Mi., 15. Aug. 2018,
> 22:23:
>
>> Yep, that's simply fixed it. It is strange that it needs to be explicit
>> now when it had not before.
>>
>> also, I see that you are using the same display message function for
>> everything.  1 second sleep time before it hides was too short, so I
>> changed to 60 seconds.
>>
>> Thank you for updating you are awesome module. Both Luks volumes open at
>> boot time now, so I can try extending my LVM to the new drive without
>> leaving the data unencrypted.
>>
>> In case of recovery, I'm not sure how easy it will be to stop using your
>> module with two encrypted volumes that need to be unlocked before the lvm.
>> I don't think the native rd.luks.uuid Will allow comma separated values.
>>
>> I will let you know how well it boots after I extend the lvm to the new
>> drive so you can update your documentation regarding LUKS on LVM.
>> Thanks again.
>>
>> On Wed, Aug 15, 2018, 4:05 PM __ __  wrote:
>>
>>> Hmm, thats strange because it is working for me and it was working for
>>> you before.
>>>
>>> I've updated the github version to explicit install cryptsetup.
>>>
>>> Please let me know if this fixes the problem.
>>>
>>> On Wed, Aug 15, 2018 at 9:45 PM, Joeviocoe Gmail 
>>> wrote:
>>>
 Thanks. Something messed up though.

 I added a single comma, and the uuid for the new Crypt_luks... To that
 line in etc/default/grub.
 I ran mkgrub and dracut -f as per the normal installation.
 Got an error saying it could not find the device, then I realized the
 only recently made the updates to the GitHub.

 Downloaded and installed the new git.  the changes seem pretty
 straightforward, and shouldn't cause a problem.

 But now, I have an error from dracut-initqueue saying cryptsetup
 command not found on line 66 of ykluks.sh

 Also, the yubikey prompt to insert, does not show up.  Just a blank
 screen until I insert the key, then it does prompt for the passphrase.

 I reinstalled the old version I had, removed the second uuid from
 default grub, and reran the mkgrub & dracut -f... It is prompting me to
 insert the yubikey again, but I still have the error of command not found
 for cryptsetup.

 I have two entries in etc/crypttab, for each uuid, but those are both
 commented out.
 I don't know why dracut cannot find the command.
 Now I have to use the full passphrase by removing the yk as shown in
 the recovery steps.

 On Wed, Aug 15, 2018, 12:43 PM __ __  wrote:

> You can add it to the GRUB_CMDLINE_LINUX in /etc/default/grub
>
> On Wed, Aug 15, 2018 at 6:38 PM,  wrote:
>
>> Thanks.  I'll try it.
>> What's the best to add the UUID?  I assume edit the grub.cfg
>> directly.  But will kernel updates overwrite?  Do I need to edit 
>> something
>> else and run dracut -f?
>>
>> --
>> You received this message because you are subscribed to a topic in
>> the Google Groups "qubes-users" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/qubes-users/hB0XaquzBAg/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/f09343a5-6ff7-4283-b8e2-d1df0e3a1b95%
>> 40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>>>

-- 
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/CAA0%2BMPfed9F9VMZ%2BDMKHK1bwA4%3DUufA9Y6Xaw1Syd5roMyDOwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 26 appvm crashes, how to debug?

[Jarle Thorsen]

I'v been running Qubes 3.2 for a long time and never had problems with crashing 
appvms...

Suddenly one of my appvms based on Fedora 2.6 has begun to randomly shut down 
on me. It seems to be related to me using the gnome file manager (related to 
file activity on mounted samba shares?).

Does Qubes come with any debug information that can help me debug what is 
causing my vm to shut down? 

-- 
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/e6cebcd4-6d12-45fb-8d8f-1015ebab0d19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.