Re: [qubes-users] networking issues

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-17 14:35, randallrba...@gmail.com wrote:
> I was also told to install this into the fedora 23 template but
> once I do i get this
> 
> [CODE] v[user@fedora-23-net ~]$ wget
> http://www.broadcom.com/docs/linux_sta/$FILE --2016-08-17
> 14:50:34--  http://www.broadcom.com/docs/linux_sta/ Resolving
> www.broadcom.com (www.broadcom.com)... failed: No address
> associated with hostname. wget: unable to resolve host address
> ‘www.broadcom.com’[/CODE] I have looked everywhere and all I can
> find are the posts where the user makes a small mistake that he
> fixes himself.
> 

By default, TemplateVMs have access only to the Updates Proxy. You
should first enable all network access by checking the "Allow full
access for N minutes" box on the "Firewall rules" tab, then try this
again.

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

iQIcBAEBCgAGBQJXtU0XAAoJENtN07w5UDAwTRoQAIS1hpojDMN8OASYJXElcR9N
YpKYnzHF0FzW0BECw9Wzgs58ATYBsTGQ7qA9MlWaS1UhL0U9PuNNZl+QzxVxV9ca
NGVqHIspY/SDtrpc5NqlsK5cOzCNOLpvdpxhHqaBHLxbSlUlz00yv/kXc6PPLLJq
r8qbyJhDTQG9lGYR1kFFMa+p8H+kyAJzkAlx97LDXFk+CL9edFaniFoaWTvDRVvV
Nk3sM32JPTHmbVAV/BzDNouDmXkxgHxnFIL+h9YX/Z7slmBbYF9fwi4pO/K3MIRL
82RvlCyjYsl/Du17zkknrkOCNneCbXA8MQs9vrPc5PT5oR+XPIxdRT2kGliziIV1
yqmAfR0QtwSC1Q7Ek0NYCL4nVHwP9GW6/FV+LFNCjS/8yQqlmqiTtykl+/UPhDba
gF6SNZQaFZML/tnvbyPXTFNjdYOQBq5gGmrqWONxcQXXmX/XPQkh7QFS+ssI+KYl
tO5oPycDMS7rqnrY7D1WPxaaDLcTuBp6AzEnCSP/z7mVJkrxqHsH9anjhGwU4NpE
qKslZb5XXJHaUmV9ENjg/jpKC3mZfUdXeu8fTnEl9MWOOd62qiTN6mjlVO+GoPeQ
EOIAG5EBHBI573hPJFEUlwNyvTp7ITMDGdn7fO9odIEe8Ccv8EWILO9uJfBaYGGO
rSrWBzL1h9WFHv3fA+s4
=HcEU
-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/fb61e953-2586-f880-f8e6-64a3003f724c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Altering the backup engine.

[Drew White]

Hi folks,

Any davs here able to tell me how to set Qubes Manager default to use a 
different archiving method other than gzip ?

gzip is the default, but I don't know how or where to change it in the manager 
code, I've tried to find the command it uses, but I'm unable to find the 
command anywhere. Either I'm not looking in the right place, or the command 
isn't what I believe it is.

Please help?

Sincerely
Drew.

-- 
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/029c179d-8c3f-4b20-9c80-740102d8f524%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to Remove Template / Preun: Domain not found

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-17 12:17, entr0py wrote:
> New Qubes 3.1 installation with Advanced (No Configuration)
> option.
> 
> After restoring dom0 + serviceVMs + serviceTemplates, tried to 
> `sudo yum remove qubes-template-fedora-23`
> 
> Received: Error in PREUN scriptlet in rpm package... 
> libvirt.libvirtError: Domain not found [from libvirt.py line 4066
> lookupByName]
> 
> `sudo yum list qubes-template-fedora-23` shows template installed
> from @anaconda/R3.1 repo.
> 
> `sudo qubes-dom0-update qubes-template-fedora-23` returns "No Match
> for argument qubes-template-fedora-23"
> 
> Thanks for help.
> 

Just a quick check: If you do "qvm-prefs -l fedora-23" (in dom0), is
the value for installed_by_rpm "True"?

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

iQIcBAEBCgAGBQJXtUqHAAoJENtN07w5UDAwelUQALeJbgBQc/IHuqOldGA4P3kS
Cq8fsWe9pqQiTWDWUP2HMPEcONXkxEHbq3PdZofYkiyBkDlBLu58F1a7cTFgGpfU
ToS+DK2od1Cax9rKKLnUef2LYE5BpMGsNn7QEdOt6xZPCeluRlANIm4kMDWkLTFP
xzgWpjZ1SwhQF1ahv6vMGq0V+NjMujP8ecvR85P5JVTABvEQSnhhasu5qB/qUl7e
PtRuR3KncS2dURBxLEiUew+I+nWkW65lARX5X/OB2lYu2TeOT9CWSkjzfllacTtH
KVDJE9nL3TnKpYt0h2e2qrka5XjeGkzi1K1cxcBXZqWkz5gd397W0Xcz5fBn3Vgl
aYs53VnvM5aAZemqa5+vYEATCRHB1ourRSddWYTIDKEI2gtfEu0j4eDwG8ZTL8gR
CdTxzEGHrZLEoxNdata8L/p4FiCgW8YHFOQg1n5H6n6PTQwYr3jJty1nYMfvXWr0
+Tbv5uQTPFa22oiOVEHJQ3yrHjeSv85KPf/8S25WhffPMImn0oMMOUUDcioG28c5
jw9037MWER0c5fsjrBOewvlUnyldXILhPa+3ZQvWJvTKtFpsUoucM7skDej8Ugn3
TLoShOqcpsq8UQiOTB5NtkhwTbfnBwWVHsSpGaiMzC9zZclCGv2p8w2J6rvjJVlh
5HNY970p/HtWs1JTNpOa
=CQ+x
-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/c0a21f73-4c6b-435a-d87e-055d723c281f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

> So I took kwinrulesrc from the old system and copied it right into the new 
> system manually with no issues. No idea why restoring dom0 wasn't able to do 
> so. Now I gotta wade through all the other config files... Hopefully, not 
> missing anything else.

Mystery is partially solved. Upon reboot, the entries in the good kwinrulesrc 
file were mostly cleared and replaced with references. Window Rules must use 
some type of unique identifiers that aren't carried over... Maybe an 
export/import would work. The important thing is that Qubes Restore doesn't 
appear to have an issue.

-- 
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/1ec95ba0-83a9-4729-bdd4-8e4a686d9482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

On Thursday, August 18, 2016 at 12:41:16 AM UTC, Chris Laprise wrote:
> On 08/17/2016 06:41 PM, entr0py wrote:
> >> On 08/17/2016 03:20 PM, entr0py wrote:
> >>> Just migrated my Qubes 3.1 system to new hardware and it went 
> >>> surprisingly smoothly :)
> >>>
> >>> I noticed however that my KDE Window Rules did not get backed up / 
> >>> restored (not sure which).
> >>>
> >>> It's kind of irrelevant at this point since we're moving away from KDE 
> >>> but I'd still like to know why that happened and if there are other 
> >>> config files that I need to copy over manually.
> >>>
> >>> Most of the files in ~/.kde/share/config/ have permissions user:user 600 
> >>> so it shouldn't be a problem to back up. Is a KDE lock on those files 
> >>> preventing them from being overwritten on the restore? Any other files I 
> >>> should bring back manually? (Just noticed some keybindings not working...)
> >>>
> >>> Thanks.
> >> If the KDE version stayed the same (4.x) then I'd expect the dom0
> >> restore to include window rules and keybindings.
> >>
> >> Did you restart the system after the restore?
> >>
> >> Chris
> > Yes, more details:
> >
> > 1. Backed up the entire system (all up-to-date): dom0, all templates, all 
> > vms;
> > 2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
> > installed anyway)
> > 3. Did an incremental restore as follows:
> > a. restored dom0 - noticed that the following did not restore: desktop 
> > background, sound prefs,
> >application menu settings (application menu entries were correct)
> > b. reboot
> > c. restored service templates & service vms
> > d. updated dom0 - noticed window rules were not restored
> > e. reboot
> > f. restored dom0 AGAIN - thinking that dom0 update might have some 
> > effect
> >window rules did not restore BUT desktop background did.
> > g. restored all other templates & vms
> > h. noticed that keybindings did not restore
> >
> > I think all of these KDE settings are stored in ~/.kde/share/config/. 
> > Specifically, the window rules are located in kwinrulesrc. I guess I could 
> > reconnect backup drive and go find out if files were backed up to begin 
> > with. My hunch is that the problem is on the restore end. How can I tell if 
> > files are locked? And if locked can Qubes restore overwrite them?
> >
> 
> Doesn't dom0 restore move the current home dir into a subdir, then write 
> the restored files to the correct locations?
> 
> The only way I can think of that failing is if the initial move was 
> piecemeal and didn't catch everything.
> 
> Another explanation for the problem is that KDE might store some 
> settings elsewhere, such as /etc or /usr/share.
> 
> FWIW, although I prefer using KDE I have never relied on a restore 
> process to get my desktop settings back. I think its better to have a 
> written checklist of customizations that need to be done after an 
> installation.
> 
> Chris

Yes, that's the approach I usually take when performing upgrades. Thought I 
would be lazy this time since everything was remaining constant. Plus, I was 
anticipating having to do it all over again for 3.2... :)

-- 
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/9b5cc523-ae38-43d0-b923-67c62d47452a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[Chris Laprise]

On 08/17/2016 06:41 PM, entr0py wrote:

On 08/17/2016 03:20 PM, entr0py wrote:

Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
smoothly :)

I noticed however that my KDE Window Rules did not get backed up / restored 
(not sure which).

It's kind of irrelevant at this point since we're moving away from KDE but I'd 
still like to know why that happened and if there are other config files that I 
need to copy over manually.

Most of the files in ~/.kde/share/config/ have permissions user:user 600 so it 
shouldn't be a problem to back up. Is a KDE lock on those files preventing them 
from being overwritten on the restore? Any other files I should bring back 
manually? (Just noticed some keybindings not working...)

Thanks.

If the KDE version stayed the same (4.x) then I'd expect the dom0
restore to include window rules and keybindings.

Did you restart the system after the restore?

Chris

Yes, more details:

1. Backed up the entire system (all up-to-date): dom0, all templates, all vms;
2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
installed anyway)
3. Did an incremental restore as follows:
a. restored dom0 - noticed that the following did not restore: desktop 
background, sound prefs,
   application menu settings (application menu entries were correct)
b. reboot
c. restored service templates & service vms
d. updated dom0 - noticed window rules were not restored
e. reboot
f. restored dom0 AGAIN - thinking that dom0 update might have some effect
   window rules did not restore BUT desktop background did.
g. restored all other templates & vms
h. noticed that keybindings did not restore

I think all of these KDE settings are stored in ~/.kde/share/config/. 
Specifically, the window rules are located in kwinrulesrc. I guess I could 
reconnect backup drive and go find out if files were backed up to begin with. 
My hunch is that the problem is on the restore end. How can I tell if files are 
locked? And if locked can Qubes restore overwrite them?



Doesn't dom0 restore move the current home dir into a subdir, then write 
the restored files to the correct locations?


The only way I can think of that failing is if the initial move was 
piecemeal and didn't catch everything.


Another explanation for the problem is that KDE might store some 
settings elsewhere, such as /etc or /usr/share.


FWIW, although I prefer using KDE I have never relied on a restore 
process to get my desktop settings back. I think its better to have a 
written checklist of customizations that need to be done after an 
installation.


Chris

--
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/dd322451-6141-d22e-fe16-7787b2fe8c8d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

On Wednesday, August 17, 2016 at 10:42:29 PM UTC, entr0py wrote:
> > On 08/17/2016 03:20 PM, entr0py wrote:
> >> Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
> >> smoothly :)
> >>
> >> I noticed however that my KDE Window Rules did not get backed up / 
> >> restored (not sure which).
> >>
> >> It's kind of irrelevant at this point since we're moving away from KDE but 
> >> I'd still like to know why that happened and if there are other config 
> >> files that I need to copy over manually.
> >>
> >> Most of the files in ~/.kde/share/config/ have permissions user:user 600 
> >> so it shouldn't be a problem to back up. Is a KDE lock on those files 
> >> preventing them from being overwritten on the restore? Any other files I 
> >> should bring back manually? (Just noticed some keybindings not working...)
> >>
> >> Thanks.
> > 
> > If the KDE version stayed the same (4.x) then I'd expect the dom0
> > restore to include window rules and keybindings.
> > 
> > Did you restart the system after the restore?
> > 
> > Chris 
> 
> Yes, more details:
> 
> 1. Backed up the entire system (all up-to-date): dom0, all templates, all vms;
> 2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
> installed anyway)
> 3. Did an incremental restore as follows:
>a. restored dom0 - noticed that the following did not restore: desktop 
> background, sound prefs, 
>   application menu settings (application menu entries were correct)
>b. reboot
>c. restored service templates & service vms
>d. updated dom0 - noticed window rules were not restored
>e. reboot
>f. restored dom0 AGAIN - thinking that dom0 update might have some effect
>   window rules did not restore BUT desktop background did.
>g. restored all other templates & vms
>h. noticed that keybindings did not restore
> 
> I think all of these KDE settings are stored in ~/.kde/share/config/. 
> Specifically, the window rules are located in kwinrulesrc. I guess I could 
> reconnect backup drive and go find out if files were backed up to begin with. 
> My hunch is that the problem is on the restore end. How can I tell if files 
> are locked? And if locked can Qubes restore overwrite them?
> 

So I took kwinrulesrc from the old system and copied it right into the new 
system manually with no issues. No idea why restoring dom0 wasn't able to do 
so. Now I gotta wade through all the other config files... Hopefully, not 
missing anything else.

-- 
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/7e47ff2c-3adb-42fd-b41b-8e9c68cbb202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[entr0py]

> On 08/17/2016 03:20 PM, entr0py wrote:
>> Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
>> smoothly :)
>>
>> I noticed however that my KDE Window Rules did not get backed up / restored 
>> (not sure which).
>>
>> It's kind of irrelevant at this point since we're moving away from KDE but 
>> I'd still like to know why that happened and if there are other config files 
>> that I need to copy over manually.
>>
>> Most of the files in ~/.kde/share/config/ have permissions user:user 600 so 
>> it shouldn't be a problem to back up. Is a KDE lock on those files 
>> preventing them from being overwritten on the restore? Any other files I 
>> should bring back manually? (Just noticed some keybindings not working...)
>>
>> Thanks.
> 
> If the KDE version stayed the same (4.x) then I'd expect the dom0
> restore to include window rules and keybindings.
> 
> Did you restart the system after the restore?
> 
> Chris 

Yes, more details:

1. Backed up the entire system (all up-to-date): dom0, all templates, all vms;
2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
installed anyway)
3. Did an incremental restore as follows:
   a. restored dom0 - noticed that the following did not restore: desktop 
background, sound prefs, 
  application menu settings (application menu entries were correct)
   b. reboot
   c. restored service templates & service vms
   d. updated dom0 - noticed window rules were not restored
   e. reboot
   f. restored dom0 AGAIN - thinking that dom0 update might have some effect
  window rules did not restore BUT desktop background did.
   g. restored all other templates & vms
   h. noticed that keybindings did not restore

I think all of these KDE settings are stored in ~/.kde/share/config/. 
Specifically, the window rules are located in kwinrulesrc. I guess I could 
reconnect backup drive and go find out if files were backed up to begin with. 
My hunch is that the problem is on the restore end. How can I tell if files are 
locked? And if locked can Qubes restore overwrite them?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/57acba4a-c8ec-323b-9a52-6e73dc24438e%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network Access dom0

[Desobediente]

The bumblebee docs tell you to use yum/dnf without gpg.

I haven't found their keys also. Normally it sits on a keyserver.example.com
or keys.example.com

Giving the circumstances, I'd guess there aren't any.

There is a "just works" way to do it, but I'm not the one telling how to do
that. Just ask them to generate gpg keys.

-- 
iuri.neocities.org

-- 
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/CAF0bz4RSUZXtPdwPKgjPh-sLaE7U4LW1uK-vT_3YUeggmzs%3DDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] networking issues

[randallrbaker]

i have a bcm 4360 wireless card  on my motherboard and I cant seam to get the 
drivers installed. I was told to install this to net vm  [CODE]wget 
http://git.io/vuLC7 -v -O fedora23_broadcom_wl_install.sh && sh 
./fedora23_broadcom_wl_install.sh;[/CODE]  but I ended up getting this mess

[CODE][user@sys-net ~]$ wget http://git.io/vuLC7 -v -O 
fedora23_broadcom_wl_install.sh && sh ./fedora23_broadcom_wl_install.sh;
URL transformed to HTTPS due to an HSTS policy
--2016-08-17 14:13:11--  https://git.io/vuLC7
Resolving git.io (git.io)... 54.243.161.116, 23.23.111.66, 23.23.173.104
Connecting to git.io (git.io)|54.243.161.116|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: 
https://gist.githubusercontent.com/onpubcom/7f41dc9cbe90556b2113/raw/a69939c941319741744bea28dadf273f118d67a2/fedora23_broadcom_wl_install.sh
 [following]
--2016-08-17 14:13:11--  
https://gist.githubusercontent.com/onpubcom/7f41dc9cbe90556b2113/raw/a69939c941319741744bea28dadf273f118d67a2/fedora23_broadcom_wl_install.sh
Resolving gist.githubusercontent.com (gist.githubusercontent.com)... 
151.101.40.133
Connecting to gist.githubusercontent.com 
(gist.githubusercontent.com)|151.101.40.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1058 (1.0K) [text/plain]
Saving to: ‘fedora23_broadcom_wl_install.sh’

fedora23_broadcom_w 100%[===>]   1.03K  --.-KB/sin 0s  

2016-08-17 14:13:11 (76.1 MB/s) - ‘fedora23_broadcom_wl_install.sh’ saved 
[1058/1058]

Last metadata expiration check performed 0:43:02 ago on Wed Aug 17 13:30:10 
2016.
Package gcc-5.3.1-6.fc23.x86_64 is already installed, skipping.
Package kernel-devel-1000:4.1.24-10.pvops.qubes.x86_64 is already installed, 
skipping.
Dependencies resolved.
Nothing to do.
Sending application list and icons to dom0
Complete!
mkdir: cannot create directory ‘hybrid_wl_f23’: File exists
--2016-08-17 14:13:14--  
http://www.broadcom.com/docs/linux_sta/hybrid-v35_64-nodebug-pcoem-6_30_223_271.tar.gz
Resolving www.broadcom.com (www.broadcom.com)... 209.132.249.240
Connecting to www.broadcom.com (www.broadcom.com)|209.132.249.240|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2928541 (2.8M) [application/octet-stream]
Saving to: ‘hybrid-v35_64-nodebug-pcoem-6_30_223_271.tar.gz.4’

hybrid-v35_64-nodeb 100%[===>]   2.79M   892KB/sin 3.4s

2016-08-17 14:13:17 (847 KB/s) - 
‘hybrid-v35_64-nodebug-pcoem-6_30_223_271.tar.gz.4’ saved [2928541/2928541]

Makefile
lib/
lib/wlc_hybrid.o_shipped
lib/LICENSE.txt
src/
src/include/
src/include/typedefs.h
src/include/linuxver.h
src/include/bcmutils.h
src/include/siutils.h
src/include/packed_section_start.h
src/include/epivers.h
src/include/linux_osl.h
src/include/bcmendian.h
src/include/packed_section_end.h
src/include/pcicfg.h
src/include/bcmdefs.h
src/include/bcmcrypto/
src/include/bcmcrypto/tkhash.h
src/include/wlioctl.h
src/include/osl.h
src/shared/
src/shared/bcmwifi/
src/shared/bcmwifi/include/
src/shared/bcmwifi/include/bcmwifi_channels.h
src/shared/bcmwifi/include/bcmwifi_rates.h
src/shared/linux_osl.c
src/wl/
src/wl/sys/
src/wl/sys/wl_dbg.h
src/wl/sys/wlc_key.h
src/wl/sys/wl_linux.h
src/wl/sys/wl_linux.c
src/wl/sys/wlc_wowl.h
src/wl/sys/wl_iw.c
src/wl/sys/wlc_pub.h
src/wl/sys/wl_iw.h
src/wl/sys/wl_export.h
src/wl/sys/wl_cfg80211_hybrid.h
src/wl/sys/wlc_ethereal.h
src/wl/sys/wl_cfg80211_hybrid.c
src/wl/sys/wlc_utils.h
src/wl/sys/wlc_types.h
src/common/
src/common/include/
src/common/include/proto/
src/common/include/proto/bcmeth.h
src/common/include/proto/ieee80211_radiotap.h
src/common/include/proto/ethernet.h
src/common/include/proto/802.1d.h
src/common/include/proto/bcmip.h
src/common/include/proto/bcmevent.h
src/common/include/proto/802.11.h
src/common/include/proto/wpa.h
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` clean
make[1]: *** /lib/modules/4.1.13-9.pvops.qubes.x86_64/build: No such file or 
directory.  Stop.
Makefile:165: recipe for target 'clean' failed
make: *** [clean] Error 2
install -D -m 755 wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless
install: cannot create regular file 
‘/lib/modules/4.1.13-9.pvops.qubes.x86_64/kernel/drivers/net/wireless/wl.ko’: 
Read-only file system
Makefile:168: recipe for target 'install' failed
make: *** [install] Error 1
depmod: ERROR: openat(/lib/modules/4.1.13-9.pvops.qubes.x86_64, 
modules.dep.tmp, 1101, 644): Read-only file system
depmod: ERROR: openat(/lib/modules/4.1.13-9.pvops.qubes.x86_64, 
modules.dep.bin.tmp, 1101, 644): Read-only file system
depmod: ERROR: openat(/lib/modules/4.1.13-9.pvops.qubes.x86_64, 
modules.alias.tmp, 1101, 644): Read-only file system
depmod: ERROR: openat(/lib/modules/4.1.13-9.pvops.qubes.x86_64, 
modules.alias.bin.tmp, 1101, 644): Read-only file system
depmod: ERROR: openat(/lib/modules/4.1.13-9.pvops.qubes.x86_64, 
modules.softdep.tmp, 1101, 644): Read-only file system
depmod: ERROR: 

[qubes-users] HCL: HP Elitebook 850 G3

[David Hobach]

3.2rc2:
Everything appears to work, incl. assigning the wifi controller to the 
netvm and the USB 3 controller & sd card reader to the usb VM.


TPM wasn't tested so far.

Booting from USB flash drive requires some workarounds (manually select 
the EFI file to boot from in the BIOS - eventually every time you boot): 
http://fomori.org/blog/?p=892


3.1:
Doesn't install (skylake driver issue maybe?).

KR
David

--
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/2bbc7c09-d3cb-3d90-84aa-24bedab11004%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-HP-HP_EliteBook_850_G3-20160817-231937.yml
Description: application/yaml


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Network Access dom0

[zackptg5]

On Wednesday, August 17, 2016 at 4:39:24 PM UTC-4, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Aug 17, 2016 at 11:58:14AM -0700, Andrew David Wong wrote:
> > On 2016-08-17 11:50, zackp...@gmail.com wrote:
> > > On Wednesday, August 17, 2016 at 2:45:25 PM UTC-4,
> > > zack...@gmail.com wrote:
> > >> On Wednesday, August 17, 2016 at 1:51:37 PM UTC-4, Andrew David 
> > >> Wong wrote:
> > > On 2016-08-16 20:00, zackp...@gmail.com wrote:
> > > On Tuesday, August 16, 2016 at 10:44:06 PM UTC-4, Andrew 
> > > David Wong wrote: On 2016-08-16 18:46, zackp...@gmail.com 
> > > wrote:
> >  On Tuesday, August 16, 2016 at 8:25:03 PM UTC-4, 
> >  Andrew David Wong wrote: On 2016-08-16 17:20, 
> >  zackp...@gmail.com wrote:
> > >>> Unfortunately, I need to install bumblebee for 
> > >>> better power management for my laptop. Copying 
> > >>> over the rpms and installing them are easy
> > >>> enough but my concern is with any dependencies
> > >>> that may be needed
> > >>> 
> >  
> >  Maybe there's a way to define your own repo and 
> >  piggyback on the usual dom0 update mechanism, but
> >  I've never really played around with this (due to
> >  the security risks), so I don't know if it's
> >  possible.
> >  
> >  The predefined repos are in /etc/yum.repos.d/. Here
> >  are the basics of the dom0 update system:
> >  
> >  https://www.qubes-os.org/doc/software-update-dom0/
> >  
> >  Here are the technical details:
> >  
> >  https://www.qubes-os.org/doc/dom0-secure-updates/
> >  
> >  And, in case it helps, an explanation of networking
> >  in Qubes:
> >  
> >  https://www.qubes-os.org/doc/networking/
> >  
> >  
> >  Alright, added the bumblebee repos. But when trying
> >  to install anything from them or run a
> >  qubes-dom0-update (this is all from dom0 terminal), I
> >  get "Failed to synchronize cache for repo
> >  'bumblebee', disabling"
> >  
> >  Are there some kind of special exceptions I need to
> >  add to the sys-firewall vm?
> >  
> > > 
> > > Are you downloading updates via Tor (sys-whonix)? If so,
> > > try requesting a new identity (press 'n' in tor-arm) or
> > > just wait 10 minutes, then try again.
> > > 
> > > I did not install the tor network for the whole system so
> > > it shouldn't be using tor. Any ideas on the cache error?
> > > 
> > > 
> > > Well, the cache error is why I asked. I frequently get that error 
> > > when updating over Tor, but not otherwise. What is your default 
> > > UpdateVM? (Qubes Manager -> System -> Global settings -> UpdateVM)
> > > 
> > > And what is that VM's NetVM?
> > > 
> > >> 
> > >> All default settings: update vm is sys-firewall and it's net is 
> > >> sys-net
> > > 
> > > Perhaps I'm adding the repos to the wrong place. I added them in 
> > > dom0. Should I instead add them to the sys-firewall template vm?
> > > 
> > 
> > Sorry, I don't know. As I said, I've never tried playing around with
> > the system in that way. Maybe someone else can offer you better advice.
> 
> If you want to install package from other repository to dom0, then yes,
> add it in dom0 /etc/yum.repos.d. You also need to import package signing
> key (sudo rpm --import /path/to/the/key).
> As usual - be very careful when installing additional stuff in dom0, as
> it may compromise system security.
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJXtMt0AAoJENuP0xzK19csdf8H/jZnFQsU4ZFK6HaZqZQZrNQM
> KLkxYHgLK5qIc2gwfigeTEjbvsNFEewqp5q1QZkdqGT2eUTH6BcyloLH3PFN66k7
> jQSxUi7BwOWbLlJd/tXsevKK8Y9JNHxWwbk9ALQ5xtrb4a0HscCREM+YRbiHq0pT
> sQvw6b9MrRQW03iX24xqOsWzI7wARVf8f6FsMZ1PVo6cdV2pDXBRghlv+zfxxxn8
> ELTkQarUFZKx39OUJpQg6NBzw+6g9WNfypGcB2ZliRlHuIbAaeetKUMjuoIK0eLA
> MS3Ak2rmjhH+qDF9Wd3z05eq6o1Mms15a42vgLnQb46a4vismVOODi9Fiac2Loc=
> =9Gpo
> -END PGP SIGNATURE-

So is it the lack of signing causing the cache errors? I also have no idea 
where to import the signing key from

-- 
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/824e5ad9-9e60-4eba-8fc0-b88780c05f86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network Access dom0

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Aug 17, 2016 at 11:58:14AM -0700, Andrew David Wong wrote:
> On 2016-08-17 11:50, zackp...@gmail.com wrote:
> > On Wednesday, August 17, 2016 at 2:45:25 PM UTC-4,
> > zack...@gmail.com wrote:
> >> On Wednesday, August 17, 2016 at 1:51:37 PM UTC-4, Andrew David 
> >> Wong wrote:
> > On 2016-08-16 20:00, zackp...@gmail.com wrote:
> > On Tuesday, August 16, 2016 at 10:44:06 PM UTC-4, Andrew 
> > David Wong wrote: On 2016-08-16 18:46, zackp...@gmail.com 
> > wrote:
>  On Tuesday, August 16, 2016 at 8:25:03 PM UTC-4, 
>  Andrew David Wong wrote: On 2016-08-16 17:20, 
>  zackp...@gmail.com wrote:
> >>> Unfortunately, I need to install bumblebee for 
> >>> better power management for my laptop. Copying 
> >>> over the rpms and installing them are easy
> >>> enough but my concern is with any dependencies
> >>> that may be needed
> >>> 
>  
>  Maybe there's a way to define your own repo and 
>  piggyback on the usual dom0 update mechanism, but
>  I've never really played around with this (due to
>  the security risks), so I don't know if it's
>  possible.
>  
>  The predefined repos are in /etc/yum.repos.d/. Here
>  are the basics of the dom0 update system:
>  
>  https://www.qubes-os.org/doc/software-update-dom0/
>  
>  Here are the technical details:
>  
>  https://www.qubes-os.org/doc/dom0-secure-updates/
>  
>  And, in case it helps, an explanation of networking
>  in Qubes:
>  
>  https://www.qubes-os.org/doc/networking/
>  
>  
>  Alright, added the bumblebee repos. But when trying
>  to install anything from them or run a
>  qubes-dom0-update (this is all from dom0 terminal), I
>  get "Failed to synchronize cache for repo
>  'bumblebee', disabling"
>  
>  Are there some kind of special exceptions I need to
>  add to the sys-firewall vm?
>  
> > 
> > Are you downloading updates via Tor (sys-whonix)? If so,
> > try requesting a new identity (press 'n' in tor-arm) or
> > just wait 10 minutes, then try again.
> > 
> > I did not install the tor network for the whole system so
> > it shouldn't be using tor. Any ideas on the cache error?
> > 
> > 
> > Well, the cache error is why I asked. I frequently get that error 
> > when updating over Tor, but not otherwise. What is your default 
> > UpdateVM? (Qubes Manager -> System -> Global settings -> UpdateVM)
> > 
> > And what is that VM's NetVM?
> > 
> >> 
> >> All default settings: update vm is sys-firewall and it's net is 
> >> sys-net
> > 
> > Perhaps I'm adding the repos to the wrong place. I added them in 
> > dom0. Should I instead add them to the sys-firewall template vm?
> > 
> 
> Sorry, I don't know. As I said, I've never tried playing around with
> the system in that way. Maybe someone else can offer you better advice.

If you want to install package from other repository to dom0, then yes,
add it in dom0 /etc/yum.repos.d. You also need to import package signing
key (sudo rpm --import /path/to/the/key).
As usual - be very careful when installing additional stuff in dom0, as
it may compromise system security.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXtMt0AAoJENuP0xzK19csdf8H/jZnFQsU4ZFK6HaZqZQZrNQM
KLkxYHgLK5qIc2gwfigeTEjbvsNFEewqp5q1QZkdqGT2eUTH6BcyloLH3PFN66k7
jQSxUi7BwOWbLlJd/tXsevKK8Y9JNHxWwbk9ALQ5xtrb4a0HscCREM+YRbiHq0pT
sQvw6b9MrRQW03iX24xqOsWzI7wARVf8f6FsMZ1PVo6cdV2pDXBRghlv+zfxxxn8
ELTkQarUFZKx39OUJpQg6NBzw+6g9WNfypGcB2ZliRlHuIbAaeetKUMjuoIK0eLA
MS3Ak2rmjhH+qDF9Wd3z05eq6o1Mms15a42vgLnQb46a4vismVOODi9Fiac2Loc=
=9Gpo
-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/20160817203915.GD9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[Chris Laprise]

On 08/17/2016 03:20 PM, entr0py wrote:

Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
smoothly :)

I noticed however that my KDE Window Rules did not get backed up / restored 
(not sure which).

It's kind of irrelevant at this point since we're moving away from KDE but I'd 
still like to know why that happened and if there are other config files that I 
need to copy over manually.

Most of the files in ~/.kde/share/config/ have permissions user:user 600 so it 
shouldn't be a problem to back up. Is a KDE lock on those files preventing them 
from being overwritten on the restore? Any other files I should bring back 
manually? (Just noticed some keybindings not working...)

Thanks.


If the KDE version stayed the same (4.x) then I'd expect the dom0 
restore to include window rules and keybindings.


Did you restart the system after the restore?

Chris

--
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/b9244b9e-fd43-cb07-5c1e-43f0d473cbf5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Missing config files after Backup / Restore

[entr0py]

Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
smoothly :)

I noticed however that my KDE Window Rules did not get backed up / restored 
(not sure which).

It's kind of irrelevant at this point since we're moving away from KDE but I'd 
still like to know why that happened and if there are other config files that I 
need to copy over manually.

Most of the files in ~/.kde/share/config/ have permissions user:user 600 so it 
shouldn't be a problem to back up. Is a KDE lock on those files preventing them 
from being overwritten on the restore? Any other files I should bring back 
manually? (Just noticed some keybindings not working...)

Thanks.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/3c2b0cac-082d-cd14-7baa-13909dc1f23a%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL HP G250 G5

[BruceH2016]

Qubes-R3.2-rc2-x86_64 installs fine, keyboard & language etc all 
detected correctly.


Initially I tried to preserve the Windows recovery partition so I could 
revert back if ever I wanted, but I couldn't get the machine to dual 
boot. So, in the end, I chose to free all space and let the installer do 
its thing, which worked nicely.


Install options chosen:
o Default VM templates chosen (vault, work, personal & untrusted)
o Whonix etc installed, but I didn't activate and haven't tested yet.
o No disk encryption (am just experimenting at the moment)
o Attaching the USB handler to sys-net works fine

Regards,

--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

--
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/b2e709e0-8744-55bb-c73f-043f40066bac%40scorecrow.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-HP-HP_250_G5_Notebook_PC-20160817-193812.cpio.gz
Description: GNU Zip compressed data
---
layout:
  'hcl'
type:
  'notebook'
hvm:
  'yes'
iommu:
  'yes'
tpm:
  'unknown'
brand: |
  HP
model: |
  HP 250 G5 Notebook PC
bios: |
  F.09
cpu: |
  Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Skylake Host Bridge/DRAM Registers [8086:1904] (rev 08)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation HD Graphics 520 [8086:1916] (rev 07) (prog-if 00 [VGA 
controller])
gpu-short: |
  FIXME
network: |
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller (rev 15)
  Intel Corporation Wireless 3165 (rev 81)
memory: |
  7954
scsi: |
  SanDisk SD8SNAT- Rev: 1006
  DVDRW  DU8A6SH   Rev: DH61

versions:

- works:
yes
  qubes: |
R3.2
  xen: |
4.6.1
  kernel: |
4.4.14-11
  remark: |
FIXME
  credit: |
Bruce Horrocks
  link: |
FIXLINK

---

[qubes-users] Unable to Remove Template / Preun: Domain not found

[entr0py]

New Qubes 3.1 installation with Advanced (No Configuration) option.

After restoring dom0 + serviceVMs + serviceTemplates, tried to 
`sudo yum remove qubes-template-fedora-23`

Received: Error in PREUN scriptlet in rpm package...
   libvirt.libvirtError: Domain not found [from libvirt.py line 4066 
lookupByName]

`sudo yum list qubes-template-fedora-23` shows template installed from 
@anaconda/R3.1 repo.

`sudo qubes-dom0-update qubes-template-fedora-23` returns
   "No Match for argument qubes-template-fedora-23"

Thanks for help.


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/e411cdcc-675e-cf97-6590-c8f95998c4f3%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Multiple Graphic Cards - how to make dom0 use internal one?

[zackptg5]

On Tuesday, May 5, 2015 at 11:45:50 AM UTC-4, Vít Šesták wrote:
> Yes, a wiki topic might be useful, but I will likely not write it until 
> https://github.com/QubesOS/qubes-issues/issues/988 is fixed, because it makes 
> explaining the process to all too complicated and fixing it should be 
> relatively easy.
> 
> Regards,
> Vít Šesták 'v6ak'
> 
> On Tuesday, May 5, 2015 at 5:27:52 PM UTC+2, David Hobach wrote:Thanks for 
> sharing your acquired knowledge; I guess it will help some users!
> 
> 
> 
> Personally I didn't care about power consumption too much; that's why I 
> 
> didn't have the same problem. I had an nvidia GPU though which I had to 
> 
> blacklist (without bumblebee).
> 
> 
> 
> Might be worth having a wiki article on the topic.
> 
> 
> 
> On 05.05.2015 09:08, Vít Šesták wrote:
> 
> > Now, it seems to be rather solved. At least the Nvidia power consumption
> 
> > seems to be gone. The power consumption now seems to be on par with my
> 
> > non-virtualized Ubuntu 12.04.* with Bumblebee and proprietary Nvidia
> 
> > drivers. This suggests proprietary drivers are not needed (I don't have
> 
> > them in Ubuntu) for low power consumption. Just having a working
> 
> > Bumblebee is likely enough. (BTW, using Nvidia GPU in Qubes does not
> 
> > seem to make any sense if Intel GPU is present, expect for HDMI.)
> 
> >
> 
> > I've done multiple attempts, they include:
> 
> > * Adding the Bumblebee repo to dom0 (the most tricky part for multiple
> 
> > reasons)
> 
> > * Installing Bumblebee (in dom0)
> 
> > * Installing bbswitch (in dom0)
> 
> > * Installing TLP (in dom0)
> 
> > * Now, I don't have blacklisted nouveau through grub. (It might have
> 
> > collided with Bumblebee. The Bumblebee does its own blacklisting,
> 
> > though. But it seems to be reasonable to remove all your attempts to
> 
> > blacklist the Nvidia kernel modules, since it is handled by Bumblebee.)
> 
> > * sudo systemctl enable tlp && sudo systemctl enable tlp-sleep.service
> 
> > && sudo systemctl enable bumblebee # Maybe all of there are unnecessary,
> 
> > but I am not sure about default settings
> 
> > * reboot :)
> 
> >
> 
> > I hope I've written everything important there for solving the Nvidia
> 
> > power consumption. Some of the steps might be unneeded. I hope the most
> 
> > important part is installing Bumblebee (and adding Bumblebee
> 
> > repository). Installing bbswitch might be also needed, but Bumblebee has
> 
> > multiple backends, so I am not 100% sure. Installing TLP has might have
> 
> > no impact on Nvidia power consumption, but it might improve other HW
> 
> > power consumption (powertop is now more happy), so it is advisable.
> 
> >
> 
> > When I reinstall Qubes, I hope I can reproduce these steps.
> 
> >
> 
> > Now, Qubes seems to be usable for me. I've to solve some other issues
> 
> > (backup size, USB isolation, hard SSD+HDD mixing, minor sound issues),
> 
> > but none of them seems to be a blocker.
> 
> >
> 
> > If you are unsure about some of these steps, you can ask. I hope I can
> 
> > provide some help.
> 
> >
> 
> > Regards,
> 
> > Vit Sestak 'v6ak'
> 
> >
> 
> > On Monday, May 4, 2015 at 12:27:03 PM UTC+2, Vít Šesták wrote:
> 
> >
> 
> >     Reported the two issues under
> 
> >     https://github.com/QubesOS/qubes-issues/issues/988
> 
> >      and
> 
> >     https://github.com/QubesOS/qubes-issues/issues/987
> 
> >      .
> 
> >
> 
> >     I've tried both bbswitch and bumblebee. I was able to install both,
> 
> >     but I was not able to cut the power consumption down. But I have not
> 
> >     tried to find the issue, I can try it later… At least, I have some
> 
> >     little progress :)
> 
> >
> 
> >     Regards,
> 
> >     Vít Šesták 'v6ak'
> 
> >
> 
> >     On Monday, May 4, 2015 at 11:34:06 AM UTC+2, Vít Šesták wrote:
> 
> >
> 
> >         Finally got Bumblebee installed! I'll restart the Qubes in order
> 
> >         to see if there is a progress.
> 
> >
> 
> >         Problem #1: /var/lib/qubes/updates/errors not automatically
> 
> >         deleted, so qubes-dom0-updates gave it up if there was a problem
> 
> >         in the past:
> 
> >         
> > https://github.com/abeluck/qubes-core/commit/a680976f1e48664c543272c2f4ce6ef08b024c50#diff-c2fc1ccc6b7d0d54b8baa948e60180d3R90
> 
> >         
> > 
> 
> >
> 
> >         Problem #2: Too strict regexp for parsing the output of rpm -K
> 
> >         caused GPG key rejection. On the bumlbebee package, rpm -K 1.
> 
> >         returns the checks in different order and 2. returns "gpg"
> 
> >         instead of "pgp". Problematic code:
> 
> >         
> > https://github.com/abeluck/qubes-core/commit/2950ee717005eb148461c83a92eb088c9a542f92#diff-9edf4e30fdc866530e395a45a829c27bR37
> 
> >         
> > 

[qubes-users] HCL HP G250 G5

[Bruce Horrocks]

Qubes-R3.2-rc2-x86_64 installs fine, keyboard & language etc all detected 
correctly.

Initially I tried to preserve the Windows recovery partition so I could revert 
back if ever I wanted, but I couldn't get the machine to dual boot. So, in the 
end, I chose to free all space and let the installer do its thing, which worked 
nicely.

Install options chosen:
o Default VM templates chosen (vault, work, personal & untrusted)
o Whonix etc installed, but I didn't activate and haven't tested yet.
o No disk encryption (am just experimenting at the moment)
o Attaching the USB handler to sys-net works fine

Regards,

--
Bruce Horrocks
Hampshire, UK

-- 
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/C6EC0392-5D2E-4A6A-9C84-0F73E4B2FF89%40scorecrow.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-HP-HP_250_G5_Notebook_PC-20160817-193812.cpio.gz
Description: GNU Zip compressed data


Qubes-HCL-HP-HP_250_G5_Notebook_PC-20160817-193812.yml
Description: Binary data

Re: [qubes-users] Network Access dom0

[zackptg5]

On Wednesday, August 17, 2016 at 2:45:25 PM UTC-4, zack...@gmail.com wrote:
> On Wednesday, August 17, 2016 at 1:51:37 PM UTC-4, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2016-08-16 20:00, zackp...@gmail.com wrote:
> > > On Tuesday, August 16, 2016 at 10:44:06 PM UTC-4, Andrew David
> > > Wong wrote: On 2016-08-16 18:46, zackp...@gmail.com wrote:
> >  On Tuesday, August 16, 2016 at 8:25:03 PM UTC-4, Andrew
> >  David Wong wrote: On 2016-08-16 17:20, zackp...@gmail.com
> >  wrote:
> > >>> Unfortunately, I need to install bumblebee for better 
> > >>> power management for my laptop. Copying over the rpms
> > >>> and installing them are easy enough but my concern is
> > >>> with any dependencies that may be needed
> > >>> 
> >  
> >  Maybe there's a way to define your own repo and piggyback on 
> >  the usual dom0 update mechanism, but I've never really
> >  played around with this (due to the security risks), so I
> >  don't know if it's possible.
> >  
> >  The predefined repos are in /etc/yum.repos.d/. Here are the 
> >  basics of the dom0 update system:
> >  
> >  https://www.qubes-os.org/doc/software-update-dom0/
> >  
> >  Here are the technical details:
> >  
> >  https://www.qubes-os.org/doc/dom0-secure-updates/
> >  
> >  And, in case it helps, an explanation of networking in
> >  Qubes:
> >  
> >  https://www.qubes-os.org/doc/networking/
> >  
> >  
> >  Alright, added the bumblebee repos. But when trying to
> >  install anything from them or run a qubes-dom0-update (this
> >  is all from dom0 terminal), I get "Failed to synchronize
> >  cache for repo 'bumblebee', disabling"
> >  
> >  Are there some kind of special exceptions I need to add to
> >  the sys-firewall vm?
> >  
> > > 
> > > Are you downloading updates via Tor (sys-whonix)? If so, try 
> > > requesting a new identity (press 'n' in tor-arm) or just wait 10 
> > > minutes, then try again.
> > > 
> > > I did not install the tor network for the whole system so it 
> > > shouldn't be using tor. Any ideas on the cache error?
> > > 
> > 
> > Well, the cache error is why I asked. I frequently get that error when
> > updating over Tor, but not otherwise. What is your default UpdateVM?
> > (Qubes Manager -> System -> Global settings -> UpdateVM)
> > 
> > And what is that VM's NetVM?
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJXtKQNAAoJENtN07w5UDAwgCAQALBilZjsa427/RgmJLZROGQQ
> > nPBW72xPCH4uh8T/mY35O40N2ueEXjfYnkbuSc1g6K/w1ne75fGNzOhhE7RbpDFl
> > 8hBM7BGWFq9wsoG5tzdaWAiO5NrozkFF3N1TPUwDvlav9Q+h4yrrcyY06TXroaWM
> > h/Kxj7JnLLR/HUAOUCHykhX2f0JGf32Xk56sEFXGdTooWbDu4uO8SHtYOFbNyxWA
> > mc98MqzjAQJq//2VcqlbfS9w7TUnr40aN9njUOg6q87WvXxYjq7TPdlX2ohCpknL
> > DZXSyXjZ24RV2ywH8sGwyPV4u6sRuMAJEvcUzdsKHMDGs7p4LEaiQxxnjKL7J2/1
> > Zv4TJE4Hl3EdPmwVoe5v8rusSIYAeJzFP0WMNkW0LPFjaqZ2PMN48Ei/I0r9fWAw
> > yaL6ES1usDLZRS2AC4gK7DqUkfwqH0HqhNurvd1VXTyQVnsPGLuSksi0OC5FKKXy
> > Noc0iCwT7qUMbya7UmkEReDAg4jWJL+BCPy+2uSouIMmy5oPFU0VO9d5KCFkfmUT
> > QqW30Un3iI5wEM3IZH/F5w/T/rTexr/Aftog3gPK0wBV5L2QTdncICngKW8iY+Nn
> > +6O7zm7l5M2z9DCQXyCr0b13vrpD0bAFhVHTefbjpFWjnhP9QfpvKbT0+bS04t8a
> > xU89APHg0+2iPCnme6SQ
> > =Als4
> > -END PGP SIGNATURE-
> 
> All default settings: update vm is sys-firewall and it's net is sys-net

Perhaps I'm adding the repos to the wrong place. I added them in dom0. Should I 
instead add them to the sys-firewall template vm? 

-- 
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/c3c930b1-89fe-4c60-95f1-5732b38a9948%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN Link Up, NetVM set to VpnVM but AppVMs still don't have net access?

[Chris Laprise]

On 07/26/2016 05:32 PM, gaikokujinkyofu...@gmail.com wrote:

On Monday, July 25, 2016 at 5:12:42 PM UTC-10, Chris Laprise wrote:


The shebang refers to the '#!/bin/bash' at the start of the script; that
is required for it to run.

A. Ok. Well I checked and I had forgotten to remove the origonal #!/bin/sh 
but it was the same file I had used before that had worked? Anyway, I edited it 
and now only one line and it is bash. But still can't access anything other 
than direct ip addresses via the appvm that is using the vpnvm?


The last three lines you refered to, of the .ovpn, I believe I added as the 
Qubes VPN doc instructed, anyway I just c/p'd from the .ovpn I have:

script-security 2
up 'qubes-vpn-handler.sh up'
down 'qubes-vpn-handler.sh down'

Is that what you were referring to?

Yes.

Something else you can try is to bypass the DHCP stuff and add the DNS
server manually in your .ovpn with a line like this:
setenv vpn_dns 'X.X.X.X'

Replace X's with DNS server address.

I tried this next, added both like

setenv vpn_dns 'X.X.X.X X.X.X.X'


(tried without quotes too) but still no go. I then noticed that there was a 
commented line in the qubes-vpn-handler.sh script so I added that line in that 
script and took it out of the ovpn file, still not able to ping non ip 
addresses...


Then when you connect and list your nat table again, you should see the
DNS IP there.

Chris


and both times (restarting vpnvm/appvm) the new DNS didn't show up when i tried 
to list the nat tables?

I would have thought manually putting in the DNS would have been sufficent?



I thought I'd let you know another user was having the same symptoms (IP 
access but no DNS) because Network Manager was running in the vpn vm... 
https://groups.google.com/d/msgid/qubes-users/f35d90b9-2632-4f91-afff-3e1f8ac26302%40googlegroups.com


If you had enabled Network Manager in that vm you should disable it. 
Other possible workarounds are putting a 7sec delay in handler script, 
or renaming the qubes-setup-dnat-to-ns file before openvpn is run (see 
linked thread for details).


Chris

--
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/30344390-4f39-eb08-a62b-274f41bdc0e2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: installing Signal on Qubes mini-HOWTO

[Chris Laprise]

On 08/17/2016 11:35 AM, johnyju...@sigaint.org wrote:

On the Signal matter, just some personal paranoia Re: Signal and Google
Play Services:

I've been the subject of some rather intense and ongoing hacking (iPhone,
iPad, Android phone/tablet, PC, MacBook, cable modem connection, you name
it).

On the Android phone, I wiped it several times, and switched to Cyanogen,
but the "weirdness" kept coming back.  (Seeing stuff being recorded,
logged, queued to upload etc., when scrutinizing the filesystem with adb.)
  The issues often seemed to dance around Google Play Services.

The problem kept coming back, until last time, when I wiped the phone yet
again, but didn't install Google Play Store (and thus no Google Play
Services).  Things *appear* to be stable and secure now, with no
logging/recording/uploading weirdness showing up on the filesystem.

I'd like to install and use Signal for obvious reasons, but I honestly
don't trust Google Store/Services enough to take the risk.

(I have a psycho ex with some crooked cop buddies, so I half suspect some
law enforcement/government hook might be present in Google Play Services.
Speculation of course.  But I'll personally stay clear for now.  I'm not
doing anything illegal, but with crooked cops it really doesn't matter
much.  :) )

I did get a copy of Signal from apkmirror, but I expect it might not work
without Play Services, and I'm not sure it'd be smart to implicitly trust
apkmirror, either.  So I'll keep my SmartPhone as a DumbPhone for now.

I was kind of excited to hear about Signal for Chromium, but disappointed
to find it relied upon you also having it installed on your smartphone.

Aand then there's this:
http://arstechnica.com/security/2015/06/not-ok-google-chromium-voice-extension-pulled-after-spying-concerns/

Not cool, Google.

Cheers.  :)



I have to say I don't understand the logic of tying an app like Signal 
to Google, meaning the user is attached to Google at the hip. Especially 
when an app like Ring.cx operates without a browser or even a server, 
which seems far less risky.


Chris

--
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/1d8e9316-1a77-9f6a-952a-880b847ae52f%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: keepassX under debian 8

[Foppe de Haan]

On Wednesday, August 17, 2016 at 2:18:33 PM UTC+2, Gorka Alonso wrote:
> El miércoles, 17 de agosto de 2016, 10:26:23 (UTC+2), Foppe de Haan  escribió:
> > On Wednesday, August 17, 2016 at 10:08:24 AM UTC+2, Foppe de Haan wrote:
> > > After switching the template for my vault to debian-8 (mainly because of 
> > > the lower memory footprint), I noticed that, for reasons that elude me, 
> > > Jessie comes with an extremely outdated keepassx build (.4.3), which 
> > > doesn't support keepass 2 databases. (-> 
> > > https://packages.debian.org/search?suite=default=all=any=names=keepassx
> > >  )
> > > As I am a bit of a novice wrt linux, is there a way to tell debian to 
> > > (apt-)get the backported build? (And should I report this in the issue 
> > > tracker?)
> > 
> > (Oh, I figured out how to get the backported build. So that just leaves the 
> > question whether I should report this somewhere, as I doubt it is intended 
> > that the deb8 template would include a version of keepassx that doesn't 
> > support keepass 2 databases.)
> 
> Not sure it is a Qubes issue, since .4.3 is the version [1] of keepassx 
> shipped Debian-stable (Jessie). Looks to me like Debian's fault.
> 
> That being said I preafer Keepass 2, which I use both on windows host (.net 
> framework dependency) and with linux (mono dependency) because if has a cool 
> google drive syncronization plugin.
> 
> [1] https://packages.debian.org/stable/allpackages

Oh, okay. I had assumed keepassx had been added/included by the Qubes devs, 
rather than simply being installed by default 'by' debian-8. If the latter is 
the case, then I guess this doesn really matter.

Anyway, if keepass 2 has gdrive (sync) integration via a plugin, I might try 
that, thanks. More elegant solution than installing dropbox. Cheers. :)

-- 
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/34246d6d-ba7f-4937-bc0a-2c8f5e20d89a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: installing Signal on Qubes mini-HOWTO

[johnyjukya]

On the Signal matter, just some personal paranoia Re: Signal and Google
Play Services:

I've been the subject of some rather intense and ongoing hacking (iPhone,
iPad, Android phone/tablet, PC, MacBook, cable modem connection, you name
it).

On the Android phone, I wiped it several times, and switched to Cyanogen,
but the "weirdness" kept coming back.  (Seeing stuff being recorded,
logged, queued to upload etc., when scrutinizing the filesystem with adb.)
 The issues often seemed to dance around Google Play Services.

The problem kept coming back, until last time, when I wiped the phone yet
again, but didn't install Google Play Store (and thus no Google Play
Services).  Things *appear* to be stable and secure now, with no
logging/recording/uploading weirdness showing up on the filesystem.

I'd like to install and use Signal for obvious reasons, but I honestly
don't trust Google Store/Services enough to take the risk.

(I have a psycho ex with some crooked cop buddies, so I half suspect some
law enforcement/government hook might be present in Google Play Services. 
Speculation of course.  But I'll personally stay clear for now.  I'm not
doing anything illegal, but with crooked cops it really doesn't matter
much.  :) )

I did get a copy of Signal from apkmirror, but I expect it might not work
without Play Services, and I'm not sure it'd be smart to implicitly trust
apkmirror, either.  So I'll keep my SmartPhone as a DumbPhone for now.

I was kind of excited to hear about Signal for Chromium, but disappointed
to find it relied upon you also having it installed on your smartphone.

Aand then there's this:
http://arstechnica.com/security/2015/06/not-ok-google-chromium-voice-extension-pulled-after-spying-concerns/

Not cool, Google.

Cheers.  :)

> On 08/15/2016 08:49 PM, Ben Wika wrote:
>> Is F-Droid's Silence any better than Signal given it can run without
>> Google Play Store?
>
> The issue is not so much the Google Play Store, but the Google Play
> Services. Silence has been forked of Signal and works completely
> different now. In contrast to today's Signal, Silence only encrypts SMS
> while Signal only sends Signal messages via their server.
>
> Kind Regards,
> Torsten
>
> --
> 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/b6d870f0-3405-9cc3-1216-0c1048cb9a8b%40grobox.de.
> 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/2a92c6cb161a26a3f02c3ba8c603147e.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB Root Drive Corruption

[johnyjukya]

Thanks for the feedback.  The fact USB is a bad idea all around for
security (and potentially stability), and the fact I was getting minor
corruption, should have been a warning to me to move the drive right onto
the SATA bus, rather than risking worse corruption.  I guess I only have
myself to blame.

I guess I'll "get back on the horse," lol, with the 3.2 release candidate,
and an internal drive.  Qubes offers enough to keep on tryin'.

Thankfully I run things in a relatively "amnesiac" fashion to start with,
so any useful or valuable data was on a separate, internal, encrypted hard
drive, and unharmed.

Thanks.

> johnyju...@sigaint.org:
>> Well, my wild enthusiasm with Qubes has turned into complete frustration
>> and exasperation this morning.
>>
>> The "mild" corruption I was seeing on boot (running Qubes from a USB
>> 2.5"
>> HD) wasn't quite so mild the last time I booted.
>>
>> This time, rather than "recovering journal... done," the fsck spewed
>> more
>> than I've ever seen an fsck spew, and the filesystem was trashed.  /var
>> ended up as a symlink to liblber-2.4.so.2.10.2.  I found /var/lib/qubes
>> in
>> lost+found (along with 350 other directories).  Argh!
>>
>> I'd highly recommend that nobody run Qubes 3.1 from an external USB
>> drive.
>>
>> I'm going back to another OS as my daily system.
>>
>> I'll probably give Qubes 3.2rc a try on an internal hard drive, as a
>> secondary OS, to see if that solves my HD and video corruption issues.
>> If
>> not, I'll probably wait for Qubes to mature a bit more before using it
>> in
>> any serious manner.
>
> I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive
> (for about a month each).  3.0rc1 encountered kernel panics about once
> per day (which wasn't the case when run from an internal drive) and
> booted much slower than from an internal drive, but I didn't notice any
> obvious drive corruption from it.  3.2rc1 had no issues whatsoever and
> wasn't much slower than internal.  I haven't tried any release of 3.1.
>
> So, my guess is that the issue you're encountering either was fixed
> between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in
> some way unique to your setup.  Maybe a hardware issue?
>
> Cheers,
> -Jeremy Rand
>
> --
> 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/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc.
> 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/242ab62b9fdfba9c77ebf9748842b412.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB Root Drive Corruption

[Jeremy Rand]

johnyju...@sigaint.org:
> Well, my wild enthusiasm with Qubes has turned into complete frustration
> and exasperation this morning.
> 
> The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5"
> HD) wasn't quite so mild the last time I booted.
> 
> This time, rather than "recovering journal... done," the fsck spewed more
> than I've ever seen an fsck spew, and the filesystem was trashed.  /var
> ended up as a symlink to liblber-2.4.so.2.10.2.  I found /var/lib/qubes in
> lost+found (along with 350 other directories).  Argh!
> 
> I'd highly recommend that nobody run Qubes 3.1 from an external USB drive.
> 
> I'm going back to another OS as my daily system.
> 
> I'll probably give Qubes 3.2rc a try on an internal hard drive, as a
> secondary OS, to see if that solves my HD and video corruption issues.  If
> not, I'll probably wait for Qubes to mature a bit more before using it in
> any serious manner.

I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive
(for about a month each).  3.0rc1 encountered kernel panics about once
per day (which wasn't the case when run from an internal drive) and
booted much slower than from an internal drive, but I didn't notice any
obvious drive corruption from it.  3.2rc1 had no issues whatsoever and
wasn't much slower than internal.  I haven't tried any release of 3.1.

So, my guess is that the issue you're encountering either was fixed
between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in
some way unique to your setup.  Maybe a hardware issue?

Cheers,
-Jeremy Rand

-- 
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/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: installing Signal on Qubes mini-HOWTO

[Torsten Grote]

On 08/15/2016 08:49 PM, Ben Wika wrote:
> Is F-Droid's Silence any better than Signal given it can run without Google 
> Play Store?

The issue is not so much the Google Play Store, but the Google Play
Services. Silence has been forked of Signal and works completely
different now. In contrast to today's Signal, Silence only encrypts SMS
while Signal only sends Signal messages via their server.

Kind Regards,
Torsten

-- 
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/b6d870f0-3405-9cc3-1216-0c1048cb9a8b%40grobox.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB Root Drive Corruption

[johnyjukya]

Well, my wild enthusiasm with Qubes has turned into complete frustration
and exasperation this morning.

The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5"
HD) wasn't quite so mild the last time I booted.

This time, rather than "recovering journal... done," the fsck spewed more
than I've ever seen an fsck spew, and the filesystem was trashed.  /var
ended up as a symlink to liblber-2.4.so.2.10.2.  I found /var/lib/qubes in
lost+found (along with 350 other directories).  Argh!

I'd highly recommend that nobody run Qubes 3.1 from an external USB drive.

I'm going back to another OS as my daily system.

I'll probably give Qubes 3.2rc a try on an internal hard drive, as a
secondary OS, to see if that solves my HD and video corruption issues.  If
not, I'll probably wait for Qubes to mature a bit more before using it in
any serious manner.

By chance, I did manage to stash away the dmesg from the last failed boot,
before the fsck destroyed the filesystem.

Just for posterity, some system details:
- Qubes 3.1
- USB->Sata controller was ID 152d:2329 JMicron Technology Corp. / JMicron
USA Technology Corp. JM20329 SATA Bridge
- AMD64 dual core system, 4G RAM
- Drive was a Samsung HM500LI

Qubes reported errors on it during the excitement, but repeated badblocks
scans from Tails showed zero errors on the drive.

Relevant portions from the dmesg save:


...
[Wed Aug 17 06:42:41 2016] usb 1-8: new high-speed USB device number 6
using ehci-pci
[Wed Aug 17 06:42:41 2016] usb 1-8: New USB device found, idVendor=152d,
idProduct=2329
...
[Wed Aug 17 06:42:41 2016] usb 1-8: New USB device strings: Mfr=1,
Product=2, SerialNumber=5
[Wed Aug 17 06:42:41 2016] usb 1-8: Product: USB to ATA/ATAPI Bridge
[Wed Aug 17 06:42:41 2016] usb 1-8: Manufacturer: JMicron
[Wed Aug 17 06:42:41 2016] usb 1-8: SerialNumber: 
[Wed Aug 17 06:42:41 2016] usb-storage 1-8:1.0: USB Mass Storage device
detected
[Wed Aug 17 06:42:41 2016] usb-storage 1-8:1.0: Quirks match for vid 152d
pid 2329: 8020
[Wed Aug 17 06:42:41 2016] scsi host7: usb-storage 1-8:1.0
...
[Wed Aug 17 06:42:41 2016] scsi 4:0:0:0: Direct-Access SAMSUNG 
HM500LI   PQ: 0 ANSI: 2 CCS
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: Attached scsi generic sg2 type 0
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] 976773168 512-byte logical
blocks: (500 GB/466 GiB)
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Write Protect is off
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Mode Sense: 34 00 00 00
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Write cache: disabled, read
cache: enabled, doesn't support DPO or FUA
[Wed Aug 17 06:42:41 2016]  sdb: sdb1 sdb2
[Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Attached SCSI disk
...
[Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): INFO: recovery required on
readonly filesystem
[Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): write access will be enabled
during recovery
[Wed Aug 17 06:42:52 2016] EXT4-fs warning (device dm-2):
ext4_clear_journal_err:4737: Filesystem error recorded from previous
mount: IO failure
[Wed Aug 17 06:42:52 2016] EXT4-fs warning (device dm-2):
ext4_clear_journal_err:4738: Marking fs in need of filesystem check.
[Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): recovery complete
[Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): mounted filesystem with ordered
data mode. Opts: (null)
[Wed Aug 17 06:42:53 2016] systemd-journald[84]: Received SIGTERM
...
[Wed Aug 17 06:43:04 2016] Adding 3948540k swap on
/dev/mapper/qubes_dom0-swap.  Priority:-1 extents:1 across:3948540k FS
[Wed Aug 17 06:43:17 2016] EXT4-fs (dm-2): re-mounted. Opts: (null)
[Wed Aug 17 06:43:17 2016] EXT4-fs (sdb1): mounted filesystem with ordered
data mode. Opts: (null)
[Wed Aug 17 06:43:17 2016] systemd-journald[638]: Received request to
flush runtime journal from PID 1
[Wed Aug 17 06:43:18 2016] sd 4:0:0:0: [sdb] FAILED Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[Wed Aug 17 06:43:18 2016] sd 4:0:0:0: [sdb] CDB: Write(10) 2a 00 1d 4c 41
a8 00 00 08 00
[Wed Aug 17 06:43:18 2016] blk_update_request: I/O error, dev sdb, sector
491536808
[Wed Aug 17 06:43:18 2016] Aborting journal on device dm-2-8.
[Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2):
ext4_journal_check_start:56: Detected aborted journal
[Wed Aug 17 06:43:18 2016] EXT4-fs (dm-2): Remounting filesystem read-only
[Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2):
ext4_journal_check_start:56: Detected aborted journal
[Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2):
ext4_journal_check_start:56: Detected aborted journal
[Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2):
ext4_journal_check_start:56: Detected aborted journal
[Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2):
ext4_journal_check_start:56: Detected aborted journal
...
[Wed Aug 17 06:50:11 2016] EXT4-fs (dm-4): recovery complete
[Wed Aug 17 06:50:11 2016] EXT4-fs (dm-4): mounted filesystem with ordered
data mode. Opts: (null)
-

The 

[qubes-users] Re: keepassX under debian 8

[Gorka Alonso]

El miércoles, 17 de agosto de 2016, 10:26:23 (UTC+2), Foppe de Haan  escribió:
> On Wednesday, August 17, 2016 at 10:08:24 AM UTC+2, Foppe de Haan wrote:
> > After switching the template for my vault to debian-8 (mainly because of 
> > the lower memory footprint), I noticed that, for reasons that elude me, 
> > Jessie comes with an extremely outdated keepassx build (.4.3), which 
> > doesn't support keepass 2 databases. (-> 
> > https://packages.debian.org/search?suite=default=all=any=names=keepassx
> >  )
> > As I am a bit of a novice wrt linux, is there a way to tell debian to 
> > (apt-)get the backported build? (And should I report this in the issue 
> > tracker?)
> 
> (Oh, I figured out how to get the backported build. So that just leaves the 
> question whether I should report this somewhere, as I doubt it is intended 
> that the deb8 template would include a version of keepassx that doesn't 
> support keepass 2 databases.)

Not sure it is a Qubes issue, since .4.3 is the version [1] of keepassx shipped 
Debian-stable (Jessie). Looks to me like Debian's fault.

That being said I prefer Keepass 2, which I use both on windows host (.net 
framework dependency) and with linux (mono dependency) because if has a cool 
google drive syncronization plugin.

[1] https://packages.debian.org/stable/allpackages

-- 
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/59c3277d-bf99-4dcf-b63d-66608b272460%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does QUBES recommend SSD drives..?

[Sandy Harris]

On Tue, Aug 16, 2016 at 10:45 PM,   wrote:

> The Qubes website recommends SSD drives.
>
> Is there any particular reason..?

The main one is speed. For the boot drive in workstations or
laptops, I've been using SSDs for years. The performance
gain was large enough to justify them for me at 2005 prices.
At today's prices, I'd say it is a no-brainer for almost anyone.

SSDs are also quieter, use less power, produce less
heat, and are more likely to survive being bumped or
dropped.

On the other hand, mechanical disks are still much
cheaper if you need large storage.

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

[qubes-users] Can not install Qubes R3.1

[thaenaran]

Hello,
I have problems with installation Qubes R3.1.
I wrote iso to usb stick using dd on Linux. 

I tried different ways install cubes to my laptop:
  1. UEFI mode, "Test this media and install Qubes R3.1", got anacoda 
installer screen and then black screen with non-blinking text cursor at the the 
top-left
  2. UEFI mode, "Troubleshooting -- verbose boot and install Qubes R3.1" the 
same situation
  3. Legacy mode, "Install Qubes" got graphics screen with Qubes logo at the 
center and the progress bar frozen at about 5-10 percents 
  4. Legacy mode, "Troubleshooting" -> "Install qubes in basic graphics mode" I 
was able to configure my installation but when installation was started 
installer said: "(anaconda:1039): Gdk-ERROR **: error: XDG_RUNTIME_DIR not set 
in the environment. Pane is dead"

Here is my laptop specifications:
  HP evny,
  i7-6500U,
  8 GB RAM, 
  BIOS: Insyde, version F.36
  Virtualization technology: enabled

-- 
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/28e9f11e-51ba-4606-9d94-def3b84cfa8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Salt InterVM Configuration explorations and pitfalls in 3.2-rc2

[nekroze . lawson]

Hi Marek,

Thanks for the response and my apologies on the late follow up.

> Hmm, that's strange. I use salt regularly to update all the templates at 
> once and haven't noticed anything like this. 
> Do you see any not cleaned up VMs after that? Like 
>  `disp-mgmt-something`. 

There where no left behind disp VM's and this persisted across boots. I have 
yet to retry this git repo fully enabled as I have needed a stable system for 
work recently but will return to this soon.


> The output is logged to /var/log/qubes/mgmt-*.log. Also take a look at 
> --show-output option. 

Thanks! that is perfect. The help message lead me to believe it was to show the 
command line runs that where executed by salt or something other than the 
report so I did not try it admittedly.

> > There are also a handful of other problems smaller problems I have 
> > encountered while trying to configure everything I need with salt. For 
> > example the fedora-23-minimal templates are unmanageable via salt, all of 
> > the internal > > VM salt configuration just doesn't work on on them from my 
> > experiments.
> 
> It may be that salt requires some additional packages to preform its 
> actions. Minimal template have really minimal package set installed. 
> But you probably can install additional stuff using pkg.installed. 
> Yes, it may require calling `qubesctl --all state.highstate` twice. 

I believe it says in the docs that the only requirements in the target VM for 
salt inter-vm management to work is scp because ssh looks of it or something. 
Turns out scp is not installed in the fedora-23-minimal template by default, 
however, even after installing it the installation of a package does not work 
for the minimal template. Using the revelation that is the --show-output switch 
I can see this happening. 

Its quite long so here is a paste of the section of output pertaining to 
fedora-23-minimal template http://pastebin.com/kCe29p9L but the tail of it is:

  stderr:
  ln: failed to create symbolic link ‘/tmp/salt-shim-sandbox/scp’: File 
exists
  WARNING: Unable to locate current thin  version: 
/tmp/.root_d510cd__salt/version.
  stdout:
  ERROR: Failure deploying thin: /usr/bin/scp
  _edbc7885e4f9aac9b83b35999b68d015148caf467b78fa39c05f669c0ff89878
  deploy
  
  ln: failed to create symbolic link ‘/tmp/salt-shim-sandbox/scp’: File 
exists
  WARNING: Unable to locate current thin  version: 
/tmp/.root_d510cd__salt/version.


> In any case, if you put Fedora-based VM behind sys-whonix, and set it as 
> UpdateVM, it should work. 

That does indeed seem to fix the problem. Is there a reason why the whonix 
setup choice that uses whonix for dom0 updates not also build an update vm that 
uses sys-whonix and is based off of fedora?

> > There are some aspects of configuring the dom0 experience in Qubes that 
> > does not seem to be possible from salt. For example there is no way to 
> > specify which applications are available in the menu for an appVM, 
> 
> Indeed there is no module for this, but you can simply edit 
> `whitelisted-appmenus.list` file in the VM directory with file.managed. 
> Then appmenus regeneration will be triggered at nearest template 
> upgrade, which will probably happen a moment later anyway (as dom0 is 
> configured before all the VMs).

I have tried this and found it not to work. I have not been able to get the 
application to appear in the application menu in xfce, nor is it enabled when I 
view the VM's apps list in the qubes-manager. I can confirm the line is in the 
right place from the state and matches the .desktop file in 
/usr/share/applications which should be where it looks. I have not rebooted yet 
but I have done multiple full highstate reruns on all vms after applying this 
state. It wasn't until I booted up the template the appVM was based on and ran 
qvm-sync-appmenus that it started to appear. I am still trying to find a way to 
emulate this is a sane but simple way with salt.

> Its "meminfo-writer" service (qvm.service). 

Brilliant. Poor assumption on my part that because there was a tickbox it 
wouldn't match one to one for a service but I guess the tickbox is just a 
redirect to the service for convenience from the memory tab.

> BTW do you know a salt module for editing XML files - just like 
> file.line or so? It would be really useful for configuring some desktop 
> environment settings - almost all Xfce configuration is in XML files...

The best would be augeas.change state which uses augeas which can make 
modifying structured data type files a one line thing. It would be perfect for 
this but has some dependencies (python-augeas) but I am not sure if templates 
would need that installed or just dom0.

Thank you for your time,
Taylor Lawson

-- 
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, 

[qubes-users] Re: keepassX under debian 8

[Foppe de Haan]

On Wednesday, August 17, 2016 at 10:08:24 AM UTC+2, Foppe de Haan wrote:
> After switching the template for my vault to debian-8 (mainly because of the 
> lower memory footprint), I noticed that, for reasons that elude me, Jessie 
> comes with an extremely outdated keepassx build (.4.3), which doesn't support 
> keepass 2 databases. (-> 
> https://packages.debian.org/search?suite=default=all=any=names=keepassx
>  )
> As I am a bit of a novice wrt linux, is there a way to tell debian to 
> (apt-)get the backported build? (And should I report this in the issue 
> tracker?)

(Oh, I figured out how to get the backported build. So that just leaves the 
question whether I should report this somewhere, as I doubt it is intended that 
the deb8 template would include a version of keepassx that doesn't support 
keepass 2 databases.)

-- 
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/134556c4-0577-4dc5-a3a9-88cda73a52bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does QUBES recommend SSD drives..?

[Robin Schneider]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17.08.2016 09:47, Robin Schneider wrote:
> On 17.08.2016 04:45, neilhard...@gmail.com wrote:
>> The Qubes website recommends SSD drives.
> 
>> Is there any particular reason..?
> 
>> Does Qubes use read/write to the hard drive any more than Windows... to
>> the point where it's going to cause drive failure a lot earlier..?
> 
>> Or is it simply a speed thing..?
> 
>> Or what.?
> 
> 
> Hi
> 
> I am pretty sure the main reason is speed. Also depending on your setup 
> (snapshots/btrfs) there might be alot of random read operations.
> 
> But when you look at the recently published paper [DiskFiltration: Data 
> Exfiltration from Speakerless Air-Gapped Computers via Covert Hard Drive 
> Noise][1] there might also be another good reason to use SSDs ;)
> 
> [1]: https://arxiv.org/pdf/1608.03431v1.pdf

To bring the paper into perspective in regards to Qubes OS: Qubes OS does
mitigate such an possibility already in that only the VM which controls a
(S)ATA controller with an HDD attached could do that. So the impact of such a
side-channel data leak should be pretty low for Qubes OS users when you keep
that in mind.

- -- 
Live long and prosper
Robin `ypid` Schneider
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXtBi8AAoJEIb9mAu/GkD4s5kP/3Qh3fgGEcsi/Jrt8+74lDQN
qQzJjWYusNfPy7jwR+P5R7zJjkPXkU79/P77d5kVGYN3UQULU0DpvsIgVw3V3fTI
vQzbj33hlOXCsAjG6V/FfE1TL5QWKpZV7I2Q2oQoUfe8HNNhvmu/QoSNlDFRIoj3
KMso2iqQPCMLzjUESWM95i9HBmNfzfH4fZyDKF1stqTIm9POr3k26excqV+WfOoi
RV7l7j87Ejn+yI/BhMGTI8VbdfV1e+8Yfl4tJmb06PfqKpDCn6gUi9Bp1+RcjGHC
JYzdEQ0y2tbZMvh1V4JJpvhu4OTT35BK7ML2hTLxdd3HKkAaFfK0+fD++pPeQI28
Cg/mQeUhitUhu12m7Qi1ilGRSekGUknt4pmBWJaISWzKjUwld9sN0or01swq/1qs
mQIQ0+BGMwMsuFb7356QMyNjSa60cu4i9ehxR905zH2ZDseiNVYBMpKZb7NvIOgM
eKy7HES0MdxNzEPn+LgMa3mliR9t2qdQ0JDeJUfd8xLtfBVe+rcZx/GTRoP817RZ
71Q4n3/Jkh0NVwEiNilFvz4N4j94kW0Lpymv6Je4gBjzaXEcbTOrmG4R3RVK1btB
N44SPjOVE8dhKIjQrv3nsEeCtjkVip79gecinjqeZ4wE8Xvo/Fi1ppYu0fQaSy3X
pu93R1Z/aS/Rm1e9JOIQ
=4iX2
-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/20851865-c3e6-8056-7d99-3900428bf667%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does QUBES recommend SSD drives..?

[Robin Schneider]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17.08.2016 04:45, neilhard...@gmail.com wrote:
> The Qubes website recommends SSD drives.
> 
> Is there any particular reason..?
> 
> Does Qubes use read/write to the hard drive any more than Windows... to the
> point where it's going to cause drive failure a lot earlier..?
> 
> Or is it simply a speed thing..?
> 
> Or what.?
> 

Hi

I am pretty sure the main reason is speed. Also depending on your setup
(snapshots/btrfs) there might be alot of random read operations.

But when you look at the recently published paper [DiskFiltration: Data
Exfiltration from Speakerless Air-Gapped Computers via Covert Hard Drive
Noise][1] there might also be another good reason to use SSDs ;)

[1]: https://arxiv.org/pdf/1608.03431v1.pdf

- -- 
Live long and prosper
Robin `ypid` Schneider
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXtBaXAAoJEIb9mAu/GkD4ZlcQANTjVBR2MbYidSzgOv4Di/GZ
EQZnqUwFhGtbvoZ623z7ZDxl8Vn4BpohAx4kUU/stmA0nm7nJcd3y8/j43quUUYy
L4jJQmVk6pd6p1i1I9N24Ra0TkteQHPn0bJ7r+U5p8xVPYdDz0iseQMCHHLKSPc5
L8/VoMIqYFFcmDccbu7oHKaCU3nqCTpYsO89bu0RjhLlAE2+EiXc3c8jK/R0+xuC
os7OV05ltMjhS1LH3SRgYWHPvvihDr9kcR+REhKVJ0NNmAFnsevZ0zgsPTGHqJrs
JZ7Rm4s4782Q80sTDOeMqQZfU2RbWn8Hm0+GEVio4XFbA882AW1cpJd7juOus3M6
m34LHl5s+2E8fWttbqNjlXCsI7gU0MfB1rwVNCK2MVObpjgAZyudJ+ArI9THGMXz
eAwQ6v7scHuBjI+ufrbNnGdtnRNkEhCjYKXCyr+NTWj+nCM3+xgBmQscAg+50eU8
Wl5IueIwkawzUoNCs+1oTOZyyW+SRPZhrfL8Jt9ftw7I5MqneobceH8k/YX9kYnp
HLmSQZ+170ZoW7LVvSnyiKUgYnhWI5JdKPlyX1CiOLVcP3gPCYtJ6kMKPOW+fhZl
RCh3uMzDr1nb7TCN2dOJ33gt9df7M1eraEjYQztuzOi9BfSq0rhx701hhjS9md7c
JKPUwVrj+YGlhJ/kvT5K
=3I7z
-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/87eef10e-4735-a02d-99b2-4b1388a29842%40riseup.net.
For more options, visit https://groups.google.com/d/optout.