[solved] Re: [qubes-users] safely remove yum from debian template?

2020-06-29 Thread Dave C


On Monday, June 29, 2020 at 11:15:39 AM UTC-4, Qubes wrote:
>
> On 6/28/20 11:23 PM, Dave C wrote: 
> > I'd like to 
> > 
> > sudo apt remove yum 
> > 
> > However, apt warns the following: 
> > 
> > The following packages will be REMOVED: 
> >qubes-core-agent-dom0-updates qubes-vm-recommended yum yum-utils 
> > 
>
> Have a look here, 
> https://www.qubes-os.org/doc/removing-templatevm-packages/, scroll down 
> to 'Removing Only Packages Not Needed for a Qubes TemplateVM'. 
>
>
> That's very helpful, thanks.

The example on that page shows `sudo apt-mark manual 
qubes-core-agent-dom0-updates ...`

I'm leaving out qubes-core-agent-dom0-updates, because it requires yum and 
that's what I'm trying to uninstall.  Other than that, I'm following those 
instructions.

The template I'm doing this to is my development template.  I won't be 
using it for a netvm.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/26d8cb11-bc5f-40e4-a22a-09a00a5e81f8o%40googlegroups.com.


[qubes-users] safely remove yum from debian tempate?

2020-06-28 Thread Dave C
I'd like to 

sudo apt remove yum

because the yum files in /etc/bash_completion.d/ break things for fossil 
(autocomplete appends a space instead of slash after directories when 
running fossil).

However, apt warns the following:

The following packages will be REMOVED:
  qubes-core-agent-dom0-updates qubes-vm-recommended yum yum-utils


A) Is it safe to remove qubes-core-agent-dom0-updates and 
qubes-vm-recommended from a debian template?

Also, apt tells me that autoremove would further remove quite a few 
packages, including several from qubes:

  qubes-core-agent-passwordless-root qubes-gpg-split
  qubes-img-converter qubes-input-proxy-sender qubes-mgmt-salt-vm-connector
  qubes-pdf-converter qubes-thunderbird qubes-usb-proxy

B) Is it safe to allow these to be autoremoved?

I'm guessing that it is ok to remove the former (A: yes) and not ok to 
remove the latter (B: no).

I've noticed that installing qubes-vm-recommended brings yum and yum-utils 
along with it.  This leaves me wondering, is there a way to uninstall yum 
on a debian template?

Thanks for any help.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/550e6bc7-8319-4587-83a2-94ea3b7432eao%40googlegroups.com.


[qubes-users] Re: How to get Ledger Nano S connected to VM

2019-11-20 Thread Dave C
I find that with Fedora 30, it is necessary to add the following to 
/rw/config/rc.local (and then restart VM):

# 
http://support.ledgerwallet.com/knowledge_base/topics/ledger-wallet-is-not-recognized-on-linux
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1b7c\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"2b7c\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"3b7c\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"4b7c\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1807\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1808\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2c97\", 
ATTRS{idProduct}==\"\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2c97\", 
ATTRS{idProduct}==\"0001\", MODE=\"0660\", OWNER=\"user\", 
GROUP=\"plugdev\"" >>/etc/udev/rules.d/20-hw1.rules
udevadm trigger
udevadm control --reload-rules



On Saturday, June 29, 2019 at 11:12:16 AM UTC-4, li...@tutanota.com wrote:
>
> Qubes 4.0 default installation with USB keyboard and USB mouse 
> The device-manager-icon works with normal flash drives perfectly 
> ___ 
>
> Tried to follow 
> https://www.whonix.org/wiki/Ledger_Hardware_Wallet#Qubes_R4 <
> https://www.whonix.org/wiki/Ledger_Hardware_Wallet#Qubes_R4> 
> https://www.qubes-os.org/doc/usb-devices/ <
> https://www.qubes-os.org/doc/usb-devices/> 
>
> Ledger Nano S connected and unlocked 
> directly connected (without hub); tested on all USB ports) 
>
> Generated a new VM: 
> VM 'ledger-nano-s' 
> type: Standalone qube based on a template 
> based on Debian 9 
> ___ 
>
> # checking VM 'ledger-nano-s' 
>
> $ sudo apt-get install qubes-usb-proxy 
> Reading package lists... Done 
> Building dependency tree   
> Reading state information... Done 
> qubes-usb-proxy is already the newest version (1.0.21+deb9u1). 
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 
>
> # checking dom0: 
>
> $ qvm-usb 
> BACKEND: DVID DESCRIPTIONUSED BY 
>
> # So, I do not see any USB; more precisely missing the line# 
> sys-usb:2-1.4  Ledger_Nano_S_0001 
>
> $ lsusb 
>
> # show several connected USB devices like my keyboard, mouse and USB hub 
> etc. but no Nano. 
>
> ___ 
>
> How do I uncover the Nano S in Qubes? 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bed2c458-057d-4e9c-abf0-cbdb57a0932e%40googlegroups.com.


Re: [qubes-users] Emergency shell on boot; qubes_dom0-pool00_tmeta: read failed: Input/output error

2019-08-21 Thread Dave C


On Tuesday, August 20, 2019 at 6:41:36 AM UTC-4, Chris Laprise wrote:
>
> On 8/19/19 7:08 PM, Dave C wrote: 
> > Following this thread: 
> https://groups.google.com/forum/m/#!searchin/qubes-users/Lvconvert/qubes-users/bPxKHOfZ3Mg
>  
> > 
> > ... I edited my locking mode (from 4 to 1) in /etc/lvm/lvm.conf, then 
> retried the 'lvm lvconvert --repair ...' 
> > 
> > That command has logged one error so far, "print_req_error: critical 
> medium error, dev nvme1n1, sector [number]" 
> > Since that one error, it hasn't shown anything. Its been running at 
> least ½ hour. I'm not sure if its still at work or has failed but hasn't 
> exited. 
>
> Hi Dave, 
>
> Did the repair operation finish? 
>
> The "critical medium error" indicates a basic hardware access issue, 
> such as a bad hardware sector or block. Best to run a command like 
> 'smartctl -H ' to check drive health status. You could also run 
> a thorough test with 'smartctl -t long '. 
>
> -- 
>
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

I was not able to get anything helpful from `smartctl`. But I ran the 
diagnostics built into my bios on the disk, and that showed read errors.  
I'm pretty confident the disk has hardware problems.

I was able to run `ddrescue` on the disk, so now I am working with a copy 
of the partition, on a good drive.

Unfortunately I still cannot activate the volumes.  But I do get different 
errors:

$ sudo lvconvert --repair qubes_dom0/pool00
  WARNING: Not using lvmetad because of repair.
  WARNING: Disabling lvmetad cache for repair command.
bad checksum in superblock, wanted 823063976
  Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed (
status:1). Manual repair required!

I've been searching the web for a next step, but haven't found it.  I'm not 
sure what "manual repair" would entail or whether it is possible at this 
point.

`ddrescue` indicated it was able to rescue 99.99% of the corrupt 
partition.  So I remain hopeful that I can still extract some of the data, 
but at this point I still cannot activate any volumes in qubes_dom0/pool00.

I'm open to any suggestions!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86efd8aa-22b6-423e-af23-6672146c84eb%40googlegroups.com.


[qubes-users] Emergency shell on boot; qubes_dom0-pool00_tmeta: read failed: Input/output error

2019-08-19 Thread Dave C
Following this thread: 
https://groups.google.com/forum/m/#!searchin/qubes-users/Lvconvert/qubes-users/bPxKHOfZ3Mg

... I edited my locking mode (from 4 to 1) in /etc/lvm/lvm.conf, then retried 
the 'lvm lvconvert --repair ...'

That command has logged one error so far, "print_req_error: critical medium 
error, dev nvme1n1, sector [number]"
Since that one error, it hasn't shown anything. Its been running at least ½ 
hour. I'm not sure if its still at work or has failed but hasn't exited.



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/308b2c20-ce2e-450e-8740-5a922a375419%40googlegroups.com.


[qubes-users] Emergency shell on boot; qubes_dom0-pool00_tmeta: read failed: Input/output error

2019-08-19 Thread Dave C
Cant start qubes on my laptop. The problem started last successful boot. I 
closed the lid, normally the laptop sleeps with a "breathing" led. But instead 
the led stayed solid, opening the lid did not turn the screen back on. I 
couldn't interact with the laptop at that point, so i powered down (for fear of 
draining the battery to zero).

Now I've rebooted, I provide the disk password, then it fails to boot, I'm 
dropped into dracut emergency shell.

To make matters worse, I'm traveling and my only backups are thousands of miles 
away.

Based on advice in similar threads, I've run 'lvm_scan', which shows errors 
including...

/dev/mapper/qubes_dom0-pool00_tmeta: read failed: Input/output error

I've also tried 'lvm lvconvert --repair qubes_dom0/pool00', which fails with

Read-only locking type set. Write locks are prohibited.

I'm comfortable with command lines, but I'm not at all familiar with these lvm 
commands. Any help is greatly appreciated! What should I try next?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68f54bff-84d6-4d05-9cd5-ad745dbda6b4%40googlegroups.com.


[qubes-users] dvm based on debian-9 (launches as regular appvm)

2019-02-03 Thread Dave C
I'm following the instructions on 
https://www.qubes-os.org/doc/disposablevm-customization/, and I'm running into 
a problem launching a debian-9 based dvm.

Here's what I'm doing.  First, I use the GUI to create an appvm, called let's 
say "my-dvm".  Then,

[user@dom0 ~]$ qvm-prefs my-dvm template_for_dispvms True
[user@dom0 ~]$ qvm-features my-dvm appmenus-dispvm 1

Then, I see "Disposable: my-dvm" in the launcher, as expected.  But the problem 
is if I start a terminal from the launcher, it launches "my-dvm" and not i.e. 
"disp1234".  That is, when creating a debian-9 based dvm template, its the 
template that launches, not a dvm.

If I repeat the procedure, but select fedora-29 as the template (instead of 
debian-9), the it works as expected, launching a vm titled "disp1234" (for 
example).

Note, I recently upgraded debian-9 template to the testing respository version 
(because of apt-get security 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/24ede68b-7ec6-4648-9e36-21740f3f5e19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] qubes-dom0-update package reinstall?

2019-02-02 Thread Dave C

On 02.02.2019 17:05, Chris Laprise wrote:

On 2/2/19 10:40 AM, Dave C wrote:
In R4, when fetching updates for Dom0 with "sudo qubes-dom0-update 
--clean --verbose" I get this error message repeated 6 times:


"Unknown configuration value: failovermethod=priority in 
/var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; 
Configuration: OptionBinding with id "failovermethod" does not exist"


I then get the following:


"Dependencies resolved.
Excludes in dnf.conf: qubes-template-debian-9, 
qubes-template-fedora-26, qubes-template-fedora-29
 
  Package  Arch  Version Repository   Size
 
Reinstalling:
  python3-blivet   noarch    2:2.1.6-5.fc25  
qubes-dom0-current   1.0 M
  python3-kickstart    noarch    1000:2.32-4.fc25    
qubes-dom0-current   370 k


Transaction Summary
 
Total size: 1.3 M

Installed size: 1.3 M
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] python3-blivet-2.1.6-5.fc25.noarch.rpm: Already downloaded
[SKIPPED] python3-kickstart-2.32-4.fc25.noarch.rpm: Already downloaded
Complete!
The downloaded packages were saved in cache until the next successful 
transaction.

You can remove cached packages by executing 'dnf clean packages'."


It seems there are two python packages available, but for some reason 
they are downloaded but not installed or re-installed.


Questions:
1. Is the error message regarding "failovermethod" relevant / 
something to worry about?
2. Is anyone else experiencing the issue with these two python 
packages (python3-blivet and python3-kickstart)?


Thanks

P.S: Qubes team - fantastic work with the OS, thanks for your awesome 
contribution to secure computing!


Dave



I don't know about the failover message. But using
'--action=reinstall' is probably necessary here. Or if the version
numbers for the downloads are newer than what is already installed
then you may need to use '--action=upgrade'.


Thanks Chris. Using "--action=reinstall"  manually for each package 
worked, and it reinstalled both packages of the same version numbers. 
Any ideas what could cause DNF to suggest reinstalling the same 
packages?


Also, does anyone also get the "failovermethod" messages when updating 
dom0?
"Unknown configuration value: failovermethod=priority in 
/var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; 
Configuration: OptionBinding with id "failovermethod" does not exist"


Dave

--
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/da25cdd75a488e323dfe256557564faa%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qubes-dom0-update package reinstall?

2019-02-02 Thread Dave C
In R4, when fetching updates for Dom0 with "sudo qubes-dom0-update 
--clean --verbose" I get this error message repeated 6 times:


"Unknown configuration value: failovermethod=priority in 
/var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo; Configuration: 
OptionBinding with id "failovermethod" does not exist"


I then get the following:


"Dependencies resolved.
Excludes in dnf.conf: qubes-template-debian-9, qubes-template-fedora-26, 
qubes-template-fedora-29


 Package  Arch  Version Repository   
  Size


Reinstalling:
 python3-blivet   noarch2:2.1.6-5.fc25  qubes-dom0-current   
 1.0 M
 python3-kickstartnoarch1000:2.32-4.fc25qubes-dom0-current   
 370 k


Transaction Summary


Total size: 1.3 M
Installed size: 1.3 M
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] python3-blivet-2.1.6-5.fc25.noarch.rpm: Already downloaded
[SKIPPED] python3-kickstart-2.32-4.fc25.noarch.rpm: Already downloaded
Complete!
The downloaded packages were saved in cache until the next successful 
transaction.

You can remove cached packages by executing 'dnf clean packages'."


It seems there are two python packages available, but for some reason 
they are downloaded but not installed or re-installed.


Questions:
1. Is the error message regarding "failovermethod" relevant / something 
to worry about?
2. Is anyone else experiencing the issue with these two python packages 
(python3-blivet and python3-kickstart)?


Thanks

P.S: Qubes team - fantastic work with the OS, thanks for your awesome 
contribution to secure computing!


Dave

--
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/60b27b91fae55479a4f180542f66a02e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] xsel via qrexec fails to set clipboard, "conversion refused"

2019-02-01 Thread Dave C
On Sunday, January 13, 2019 at 5:53:12 PM UTC-8, Dave C wrote:
> On Sunday, January 13, 2019 at 2:15:31 AM UTC-8, 799 wrote:
> > Hello Dave,
> > 
> > 
> > 
> > On Fri, 28 Dec 2018 at 19:28, Dave C  wrote:
> > I've written a qrexec script which, among other things, attempts to place 
> > something into the clipboard, using `xsel`.
> > 
> > xsel fails, with error: "xsel: Conversion refused"
> > 
> > 
> > 
> > I don't know what xsel is doing. I have written a script which uses xclip 
> > (which needs to be installed as an additional package).
> > 
> > Maybe you can get some info from there:
> > 
> > 
> > 
> > Copy content from the dom0clipboard to an AppVMs clipboard including a 
> > notification
> > 
> > https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-xclip-to-vm
> > 
> > 
> > 
> > --- --- ---
> > #!/bin/bash
> > # name : qvm-xclip-to-vm
> > # purpose: Copy the clipboard of dom0 to the clipboard of an appvm
> > # Usage : qvm-xclip-to-vm 
> > 
> > 
> > AppVM=$1
> > xclip -o | qvm-run --pass-io $AppVM 'cat | xclip -selection clipboard 
> > &>/dev/null'
> > notify-send --urgency low --icon image --expire-time=5000 "$0" "Clipboard 
> > pasted from dom0 to $AppVM"
> > 
> > --- 8< --- --- ---
> > 
> > 
> > The other way around:
> > 
> > https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-xclip-from-vm
> > 
> > 
> > Additionaly there's a script to do the same for screenshots:
> > https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-screenshot-to-clipboard.sh
> > 
> > 
> > O.
> 
> Hey, good idea.  Not sure why I hadn't thought to try `xclip` earlier.  While 
> I'd still like to know what xsel is complaining about, I'm able to get it 
> working with xclip.
> 
> I've started making a qubes-specific version of `go-hash`, a tool for 
> managing passwords.  I like one feature in particular: open a URL while 
> copying a password to the clipboard.  I renamed my version `qpass`, and 
> created command "appvm" which opens a URL in an appvm while copying the 
> password to that appvm's clipboard.  The "dispvm" command is similar, but 
> opens a disposable vm.
> 
> Work (still a bit in progress) is here: 
> https://github.com/dncohen/qpass/tree/qpass
> 
> The idea is to run `qpass` in a vault, and use it to launch URLs in app vms 
> that have network access.  While qubes copy/paste is pretty good, I find that 
> I can get sloppy with it, sometimes manually pasting to the wrong vm.  I'm 
> hoping this approach is a little more idiot-proof.
> 
> -Dave

Just to update this thread... it turns out I was trying to have xsel work with 
an invalid utf8 string.  I fixed a bug in the code generating a password 
string.  Once it was proper utf8, xsel works fine (although running verbose, it 
still warns "conversion refused" - no idea what it is referring to.)

-- 
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/340cb2b5-e1e5-4c5f-b672-1086797247b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qpass - password manager with qubes-specific features

2019-02-01 Thread Dave C
I recently got interested in a terminal-friendly password manager called 
"go-hash".  It stores usernames, urls and passwords in an encrypted database.  
It calls these "entries" and supports "groups" of entries.  It allows you to 
launch a URL, while putting the password in the clipboard.

I've forked this password manager with some qubes-specific features, under the 
name "qpass". Features include: if you give a "group" the same name as an 
appvm, you can launch the URL in that appvm and with your password copied to 
that appvm's clipboard.  Also, you could launch the URL in a dispvm, again with 
password copied to the dispvm's clipboard.

In short, from a "vault" vm terminal, you can quickly launch an appvm, open a 
URL, and have the password in the appvm clipboard.  Sure, qubes provides easy 
keyboard shortcuts for copying and pasting; but for my flow, the approach of 
this password manager seems a little better.  Example: "appvm personal:gmail" 
would launch the personal vm, open a browser to gmail, and have your password 
in the personal clipboard.

You can build this tool with golang, via `go get github.com/dncohen/qpass`.  To 
launch appvms, you'll need to install a qubes-rpc script in the template vm, 
and also `xsel` or `xclip`.  Details: 
https://github.com/dncohen/qpass, and 
https://github.com/dncohen/qpass/tree/master/qubes

I share this here for a couple reasons.  First, others may be interested in 
using this tool.  Second, I'd appreciate this group's opinions regarding 
go-hash's approach and security.  See the readme for details, i.e. its use of 
Argon2.  I was drawn to it because I noticed the "group" feature could be used 
to know which appvm to launch, and I'm not necessarily qualified to audit other 
aspects for security.


-- 
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/19f1a99b-7609-49e0-ad10-1d1160fe85bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] xsel via qrexec fails to set clipboard, "conversion refused"

2019-01-13 Thread Dave C
On Sunday, January 13, 2019 at 2:15:31 AM UTC-8, 799 wrote:
> Hello Dave,
> 
> 
> 
> On Fri, 28 Dec 2018 at 19:28, Dave C  wrote:
> I've written a qrexec script which, among other things, attempts to place 
> something into the clipboard, using `xsel`.
> 
> xsel fails, with error: "xsel: Conversion refused"
> 
> 
> 
> I don't know what xsel is doing. I have written a script which uses xclip 
> (which needs to be installed as an additional package).
> 
> Maybe you can get some info from there:
> 
> 
> 
> Copy content from the dom0clipboard to an AppVMs clipboard including a 
> notification
> 
> https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-xclip-to-vm
> 
> 
> 
> --- --- ---
> #!/bin/bash
> # name : qvm-xclip-to-vm
> # purpose: Copy the clipboard of dom0 to the clipboard of an appvm
> # Usage : qvm-xclip-to-vm 
> 
> 
> AppVM=$1
> xclip -o | qvm-run --pass-io $AppVM 'cat | xclip -selection clipboard 
> &>/dev/null'
> notify-send --urgency low --icon image --expire-time=5000 "$0" "Clipboard 
> pasted from dom0 to $AppVM"
> 
> --- 8< --- --- ---
> 
> 
> The other way around:
> 
> https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-xclip-from-vm
> 
> 
> Additionaly there's a script to do the same for screenshots:
> https://github.com/one7two99/my-qubes/blob/master/home/bin/qvm-screenshot-to-clipboard.sh
> 
> 
> O.

Hey, good idea.  Not sure why I hadn't thought to try `xclip` earlier.  While 
I'd still like to know what xsel is complaining about, I'm able to get it 
working with xclip.

I've started making a qubes-specific version of `go-hash`, a tool for managing 
passwords.  I like one feature in particular: open a URL while copying a 
password to the clipboard.  I renamed my version `qpass`, and created command 
"appvm" which opens a URL in an appvm while copying the password to that 
appvm's clipboard.  The "dispvm" command is similar, but opens a disposable vm.

Work (still a bit in progress) is here: 
https://github.com/dncohen/qpass/tree/qpass

The idea is to run `qpass` in a vault, and use it to launch URLs in app vms 
that have network access.  While qubes copy/paste is pretty good, I find that I 
can get sloppy with it, sometimes manually pasting to the wrong vm.  I'm hoping 
this approach is a little more idiot-proof.

-Dave

-- 
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/119a7217-6184-48b2-8a05-eb85da6c641d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] xsel via qrexec fails to set clipboard, "conversion refused"

2019-01-12 Thread Dave C
On Sunday, December 30, 2018 at 5:32:58 AM UTC-8, unman wrote:
> On Fri, Dec 28, 2018 at 10:28:12AM -0800, Dave C wrote:
> > I've written a qrexec script which, among other things, attempts to place 
> > something into the clipboard, using `xsel`.
> > 
> > xsel fails, with error: "xsel: Conversion refused"
> > 
> > Attempting to troubleshoot, I've learned that `xsel -o` can show the 
> > contents of the clipboard, but `xsel` fails to set the clipboard.  Both 
> > `xsel -v` and `xsel -b -v` fail with the "conversion refused" messages.  
> > `xsel` works fine when I run it from a terminal.  The error occurs only 
> > when running via qrexec.
> > 
> > For some context, if you're interested... I recently became aware of a 
> > password manager with some interesting features: 
> > https://github.com/renatoathaydes/go-hash.  I'd like to modify it, so that 
> > it both opens a URL in a VM, and places a password in that VM's clipboard.  
> > I've got most of that working, except that I can't get the password into 
> > the clipboard, because xsel fails with "conversion refused".
> > 
> 
> It would help if you provided a copy of your script and some detail on
> where you are calling xsel, how you are handling it on the receiving
> side, and what templates you are using.
> Are you using the normal Qubes clipboard paste mechanism or are you
> rolling your own?


I'll attach a file, which is a version of the script I'm working on.  It's 
based on /etc/qubes-rpc/qubes.OpenURL.  In addition to opening URLs, it takes 
the first line of stdin and uses `xsel` to put that line into the clipboard.  
It doesn't work.  If you change `xsel -v`, you'll see it gets the error I've 
described in the first post.

-- 
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/01fcad0f-c818-448f-91cc-2a28310ae332%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


qpass.ClipOpenURL
Description: Binary data


[qubes-users] Re: screen brightness

2019-01-12 Thread Dave C
On Friday, December 21, 2018 at 2:44:36 PM UTC-8, haaber wrote:
> I run Q4 on a dell notebook.The "screen brightness" key-combination 
> leans qubes to show a screen brightness icon, but I cannot change 
> brightness at all.Is this maybe a setting somewhere? Especially in 
> evening hours this is really a pain in the eye ...  Bernhard

The key combination fn-f5 lowers brightness on my laptop.  (fn-f5 raises it)

But the lowest brightness available through the keyboard shortcut is still too 
bright at night.  I find that brightness can be further lowered with the 
following, in dom0:

xrandr --output eDP1 --brightness .75

Use `xrandr-q` to figure out what to replace "eDP1" with.  And try .5 or lower 
to fine tune your brightness.

-- 
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/33af20b4-b665-4f7e-ba08-66bab0190dce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] xsel via qrexec fails to set clipboard, "conversion refused"

2018-12-28 Thread Dave C
I've written a qrexec script which, among other things, attempts to place 
something into the clipboard, using `xsel`.

xsel fails, with error: "xsel: Conversion refused"

Attempting to troubleshoot, I've learned that `xsel -o` can show the contents 
of the clipboard, but `xsel` fails to set the clipboard.  Both `xsel -v` and 
`xsel -b -v` fail with the "conversion refused" messages.  `xsel` works fine 
when I run it from a terminal.  The error occurs only when running via qrexec.

For some context, if you're interested... I recently became aware of a password 
manager with some interesting features: 
https://github.com/renatoathaydes/go-hash.  I'd like to modify it, so that it 
both opens a URL in a VM, and places a password in that VM's clipboard.  I've 
got most of that working, except that I can't get the password into the 
clipboard, because xsel fails with "conversion refused".

-- 
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/d916f1f7-b108-4976-b6b8-0e381c34904b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] ClipboardPaste "ask" vs "allow" (qrexec question)

2018-12-16 Thread Dave C
There's a comment in /etc/qubes-rpc/policy/qubes.ClipboardPaste:

## Clipboard paste (Ctrl-Shift-V) will treat "ask" as "allow" but only when
## called by this keyboard shortcut. "deny" always deny the operation

This begs the question: how can I paste into a VMs clipboard *not* via the 
keyboard shortcut?

Can qubes.ClipboardPaste be invoked via a qrexec call?  If so, I'd love to see 
an example.  Thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f557a7c0-8127-4c2b-807c-67d298d330a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-12-11 Thread Dave C
On Thursday, October 18, 2018 at 5:52:31 AM UTC-7, Vít Šesták wrote:
> Marmarek has identified the issue and fixed it: 
> https://github.com/QubesOS/qubes-issues/issues/4351
> 

I haven't been vocal on this thread in a while... but I appreciate the comments 
from v6ak and the bugfix from Marmarek.

I had a moment to update my blog post about screensharing in Qubes: 
https://www.dave-cohen.com/blog/qubes-vnc-screenshare/, please check it out if 
interested.  I welcome any constructive feedback.

Cheers, -Dave

-- 
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/56a60b96-eb1d-4134-9673-708ee694af03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: laptop fails to sleep, becomes very hot

2018-08-27 Thread Dave C
On Tuesday, March 13, 2018 at 3:46:03 PM UTC-7, Yuraeitha wrote:
> On Tuesday, March 13, 2018 at 10:13:45 PM UTC+1, Dave C wrote:
> > Many times in recent days, I've closed my Qubes laptop, expecting it to 
> > sleep, and put it into my backpack.  Normally it sleeps as expected.
> > 
> > Two of those times, once today and once several days ago, I reach into the 
> > backpack and find the laptop extremely hot to the touch.  I'd expect the 
> > fan to be on at these temperatures, but it isn't.
> > 
> > When I open the laptop, theres no response and similarly no response to 
> > pressing keys.  I press and hold the power button for a long time.  There's 
> > still no feedback from the computer, but it does turn off and cool down.
> > 
> > So far, I haven't noticed permanent damage, but I worry about that.  It's 
> > an unpleasant surprise to find that the battery is totally drained and I'm 
> > not sure what the computer has been trying to do.
> > 
> > Any thoughts?  Or suggestions how to troubleshoot this?
> > 
> > -Dave
> 
> I can confirm two similar cases in recent weeks, though there's been quite 
> some time between them, weeks? and I typically use suspend multiple times a 
> day, except sometimes weekends.
> 
> There are other cases, where sys-net stops responding, or the internet isn't 
> working when it's brought back from suspend, though these cases are just as 
> rare as the above no suspend issue (I'm using the wi-fi module blacklisting 
> in sys-net btw).
> 
> To me it seems like a semi-rare bug that is triggered by something yet 
> unknown, though maybe it's known on github tracking issues? 
> 
> Either way, I think this might be related to the sys-net, but I can't really 
> be sure here. Perhaps you can write a script that disables the networking, 
> shutsdown sys-net, and then starts sys-net again and re-connects networking 
> as it wakes up. 
> 
> This isn't a pretty solution, but it might work? Does your issue happen 
> frequent enough so that you can test if sys-net is shutdown, that suspend 
> then works properly? Would be ideal to know if that is indeed it before 
> spending some time on such a script.

The problem of a sleeping laptop getting *very* hot happened again today.  That 
gives you some idea how frequently: not enough to make troubleshooting easy.

I wonder if part of the cause is taking the laptop while sleeping and plugged 
in, unplugging and putting in backpack.  That is I wonder whether unplugging 
disturbs its sleep.

On reboot, my system clock is 1 hour early.  Meaning it shows 2:21 when it's 
actually 3:21.  I mention in case it's relevant.

After restarting, I used `journalctl -o short-precise -k -b -1` to get logs 
from the prior boot.  Note: this works on dom0, but on sys-net it looks like 
the "prior boot" comes from the template, so its not useful.

There are some messages in the log related to CPUs sleeping and waking.  So I 
include it here.  Maybe something will jump out to an expert here.  I'm really 
not sure what these messages mean.

Attached log shows this morning around 9am.  That's when I closed the lid.  The 
laptop was plugged in.  Around 1pm I unplugged it, put it in my backpack.  
Around 3pm, I took it out.  Noticed it was hot to the touch.  No fans blowing, 
just a really hot laptop.  Completely unresponsive to any input.  I pressed the 
power button for a while...a couple times...until it powered on (I wanted to 
get the fan running).  The battery was about 50% drained.

-- 
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/94db4dee-087b-4c24-adda-a1084246834b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Aug 27 09:06:10.441594 dom0 kernel: Freezing user space processes ... (elapsed 
0.086 seconds) done.
Aug 27 09:06:10.441802 dom0 kernel: OOM killer disabled.
Aug 27 09:06:10.441915 dom0 kernel: Freezing remaining freezable tasks ... 
(elapsed 0.102 seconds) done.
Aug 27 09:06:10.442038 dom0 kernel: Suspending console(s) (use 
no_console_suspend to debug)
Aug 27 09:06:10.442252 dom0 kernel: PM: suspend devices took 0.596 seconds
Aug 27 09:06:10.74 dom0 kernel: ACPI: EC: interrupt blocked
Aug 27 09:06:10.444624 dom0 kernel: ACPI: Preparing to enter system sleep state 
S3
Aug 27 09:06:10.444750 dom0 kernel: ACPI: EC: event blocked
Aug 27 09:06:10.444873 dom0 kernel: ACPI: EC: EC stopped
Aug 27 09:06:10.444975 dom0 kernel: PM: Saving platform NVS memory
Aug 27 09:06:10.445094 dom0 kernel: Disabling non

[qubes-users] Re: Ledger Nano S

2018-05-04 Thread Dave C
On Wednesday, May 2, 2018 at 8:44:35 AM UTC-7, bojan...@gmail.com wrote:
> In Qubes 4 I can connect all kinds of USB devices via the device selector in 
> the upper right corner of the window. The Ledger Nano S is a hardware wallet 
> for cryptocurrencies. Ledger Manager is an extension for Chrome/Chromium 
> webbrowser. When I connect Ledger Nano S to a USB-port it is recognized by 
> Qubes and I can select to which VM it shoud be assigned to but it is not 
> recognized by the Ledger Manager. The Ledger Nano is recognized by Ledger 
> Manager in other OP's like Windows 10 and different Linux. Any ideas about 
> what the cause could be?
> 
> I have tested sys-net, sys-firewall and sys-whonix. No difference.
> Also tested StandaloneVM based on Fedora26, Debian9 and Windows7. No 
> differences.

I've been able to connect a Nano S, via a sys-usb, to an appvm based on fedora 
26.  A couple things to look out for:

When you switch into or out of apps on the Nano (and maybe when you enter your 
PIN, I don't recall), it will be detached from the appvm.  So you'll find 
yourself often re-attaching the Nano.  Use `qvm-usb` on dom0 to check whether 
it is still attached to appvm.

Ledger's software gets flakey when you're running more than one of it's apps or 
browser plugins.  Make sure you don't have bitcoin wallet (or any others) open 
while the Ledger Manager app is open.

Hope that helps, -Dave

-- 
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/dc9c39f1-6fbc-4281-b56b-9b146c440718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Well supported laptops with 64GB system memory?

2018-05-04 Thread Dave C
On Wednesday, April 25, 2018 at 2:42:12 AM UTC-7, Uni Gaia wrote:
> Good day everyone!
> 
> Saw a thread on reddit recently where someone was asking about a qubes 
> supported laptop capable of employing 64GB of system memory. That got me 
> thinking and doing some research, and actually nothing concrete comes up.
> 
> Is anyone running such a system?

I'm attaching the HCL report from a Lenovo P51.

I struggled to install an early 4.x release candidate.  I imagine those 
problems with the installers are fixed in 4.0.  (I'm not sure because I haven't 
needed to reinstall.)

Qubes 4 runs great on this machine. Audio, video, power management, etc.  I've 
only noticed minor things:

* See the HCL report, it says "TPM: device not found"  I don't know why that is 
not found. (I'm actually not sure this is minor!)

* Some software fails to detect the mic or the camera, once they have been 
allocated to an appvm.  I blame the software because Google's Meet is able to 
use both.  Some conferencing software find the camera but not the mic, or vice 
versa.

* USB 3 external drives don't work.  Workaround is to use an external hub that 
supports only USB 2.

That's all I can think of.  Really great job by all the Qubes contributors on 
4.0!!!

-- 
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/d1e0793a-49b2-4225-8224-2f4443404397%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HHCTO1WW-20180504-214433.yml
Description: Binary data


[qubes-users] Port forwarding to a qube from the outside world, not working for me (4.x)

2018-05-04 Thread Dave C
I'm struggling to follow the instructions on 
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world

Whatever my mistake is, I hope it's easy for someone to spot.  I can't seem to 
spot it myself, despite a lot of trying.

The good news is that `iptables` shows forwarding through sys-net.  The trouble 
is that sys-firewall shows no signs of receiving that traffic.  In the output 
that follows, `MY-SLIM` is the label I'm working on, port 9000.

Here's evidence on `sys-net` that packets are forwarded:

```
[user@sys-net ~]$ sudo iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT tcp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 tcp dpt:8082
0 0 DROP   udp  --  vif+   *   0.0.0.0/00.0.0.0/0   
 udp dpt:68
   28 18042 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp --  vif+   *   0.0.0.0/00.0.0.0/0   

0 0 ACCEPT all  --  lo *   0.0.0.0/00.0.0.0/0   

0 0 REJECT all  --  vif+   *   0.0.0.0/00.0.0.0/0   
 reject-with icmp-host-prohibited
  768 32256 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

60282   56M ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 ctstate RELATED,ESTABLISHED
   26  1344 MY-SLIMtcp  --  ens5   *   0.0.0.0/010.137.0.6  
 tcp dpt:9000 ctstate NEW
  837 46024 QBS-FORWARD  all  --  *  *   0.0.0.0/00.0.0.0/0 
  
0 0 DROP   all  --  vif+   vif+0.0.0.0/00.0.0.0/0   

  811 44680 ACCEPT all  --  vif+   *   0.0.0.0/00.0.0.0/0   

   26  1344 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain OUTPUT (policy ACCEPT 26 packets, 1929 bytes)
 pkts bytes target prot opt in out source   destination 


Chain MY-SLIM (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   192.168.1.0/24   0.0.0.0/0   


Chain QBS-FORWARD (1 references)
 pkts bytes target prot opt in out source   destination 
   

```

(I'm looking at the MY-SLIM row under "Chain FORWARD" above.  Should I be 
concerned the counts are 0 under "Chain "MY-SLIM"?)

Meanwhile on `sys-firewall`, I get no count for MY-SLIM:

```
[user@sys-firewall ~]$ sudo iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 84 packets,  bytes)
 pkts bytes target prot opt in out source   destination 

  152  8823 PR-QBS all  --  *  *   0.0.0.0/00.0.0.0/0   

   84   PR-QBS-SERVICES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 MY-SLIMtcp  --  eth0   *   0.0.0.0/010.137.0.6  
 tcp dpt:9000

[snip, for brevity]
```

Here are the `/rw/config/qubes-firewall-user-script` that I'm using on both VMs 
(note: I originally had this code in `rc.local` on sys-net, as per the 
documentation, but I find the `nft add ...` call doesn't "stick" unless I move 
it to `qubes-firewall-user-script`.  Also, you'll note I have commented lines 
that forward port 3483 - my goal is to uncomment those lines, after I have port 
9000 working.)

First on `sys-net`:

```
#!/bin/sh

# This script is called in AppVMs after every firewall update (configuration
# change, starting some VM etc). This is good place to write own custom
# firewall rules, in addition to autogenerated ones. Remember that in most cases
# you'll need to insert the rules at the beginning (iptables -I) for it to be
# efective.

# debug
touch /rw/config/QUBES-FIREWALL-USER-SCRIPT


# Slim server
# 
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
# 10.137.0.6 is sys-firewall

if iptables -t nat -N MY-SLIM; then
iptables -t nat -A MY-SLIM -j DNAT --to-destination 10.137.0.6
fi

if ! iptables -t nat -n -L PREROUTING | grep --quiet MY-SLIM; then
iptables -t nat -A PREROUTING -i ens5 -p tcp --dport 9000 -d 
192.168.1.101 -j MY-SLIM
#   iptables -t nat -A PREROUTING -i ens5 -p tcp --dport 3483 -d 
192.168.1.101 -j MY-SLIM
#   iptables -t nat -A PREROUTING -i ens5 -p udp --dport 3483 -d 
192.168.1.101 -j MY-SLIM
fi

if iptables -N MY-SLIM; then
iptables -A MY-SLIM -s 192.168.1.0/24 -j ACCEPT
fi

if ! iptables -n -L FORWARD | grep --quiet MY-SLIM; then
iptables -I FORWARD 2 -i ens5 -d 10.137.0.6 -p tcp --dport 9000 -m 

Re: [qubes-users] Best pratice for crypto-currency wallets?

2018-04-07 Thread Dave C
On Monday, August 21, 2017 at 8:33:32 PM UTC-7, Francesco wrote:
> Anguilla
> 
> 
> 
> 
> On Mon, Aug 21, 2017 at 8:14 PM,   wrote:
> I'd like to use Qubes for my crypto-currency wallets.
> 

I scratched my own itch and made a qubes-friendly tool for XRP transactions.  
I'd like to build the same for BTC, etc... but I don't yet know those as well.

Details on https://www.dave-cohen.com/blog/rcl-tool/

-Dave

 

-- 
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/bc48c2bc-60ca-4777-bffd-5825f6cbe4c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] laptop fails to sleep, becomes very hot

2018-03-13 Thread Dave C
Many times in recent days, I've closed my Qubes laptop, expecting it to sleep, 
and put it into my backpack.  Normally it sleeps as expected.

Two of those times, once today and once several days ago, I reach into the 
backpack and find the laptop extremely hot to the touch.  I'd expect the fan to 
be on at these temperatures, but it isn't.

When I open the laptop, theres no response and similarly no response to 
pressing keys.  I press and hold the power button for a long time.  There's 
still no feedback from the computer, but it does turn off and cool down.

So far, I haven't noticed permanent damage, but I worry about that.  It's an 
unpleasant surprise to find that the battery is totally drained and I'm not 
sure what the computer has been trying to do.

Any thoughts?  Or suggestions how to troubleshoot this?

-Dave

-- 
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/3ff8de22-02f5-4218-81ea-5ecf75df61f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HHCTO1WW-20180313-131259.yml
Description: Binary data


[qubes-users] Re: sys-net unresponsive after wake from sleep

2018-02-07 Thread Dave C
On Wednesday, February 7, 2018 at 4:02:38 PM UTC-8, Yuraeitha wrote:
> On Wednesday, February 7, 2018 at 8:58:13 PM UTC+1, Dave C wrote:
> > I've upgraded a laptop from 3.2 to 4.0rc4.  I didn't have the problem 
> > described here in 3.2...
> > 
> > When I sleep the laptop (by closing lid), I find that every time I wake it, 
> > sys-net is unresponsive.  
> > 
> > I cannot bring up a terminal in sys-net.  Terminals already open are 
> > unresponsive to input.
> > 
> > Calling `qvm-shutdown sys-net` does nothing.  `qvm-kill sys-net` does kill 
> > it.
> > 
> > I can restart sys-net and call `qvm-prefs -s sys-firewall netvm sys-net`, 
> > in order to be connected to internet again.
> > 
> > How can I troubleshoot sys-net, given the description above?  Which logs 
> > should I be looking at?
> > 
> > I have tried putting iwlmvm and iwlwifi in 
> > /rw/config/suspend-module-blacklist, but that has not changed the behavior. 
> >  I'm just not sure what else to try.  Thanks!
> 
> There is another Qubes users discussion going on atm about how to get around 
> this bug, over here 
> https://groups.google.com/forum/#!topic/qubes-users/1vijiBx0ftU 
> 
> For the record, I have this new bug too, and it seems quite a few others also 
> have it, so it may perhaps just be a question of little time before its 
> fixed. I don't have much time atm to look my self, nor do I have much 
> experience. But here is what I'd suggest. 
> 
> My guess is that you can use "sudo journalctl" in sys-net after restarting 
> from a crash. You can also do a "man journalctl" or "journalctl --help" to 
> find out how to list the system/kernel state history, or further google it 
> for how to use journalctl. The --boot attribute will give you everything 
> since last boot till you type that command, though its also possible look at 
> the second last boot, or any other saved time-stamps as well. 
> 
> Also if you use something like "-n 100" to journalctl, then it should only 
> list the last 100 lines, instead of thousands upon thousands of lines, which 
> can take a while to move through with a slow scrolling down by holding the 
> enter key down... tick clock, goes the clock. Better limit that huge log, and 
> you're only interested in the last few lines before it freezes anyhow :-)
> 
> For example, if you use journalctl on the second last boot, and put it to 
> something like last 100 lines, then my guess is it could quite likely give 
> you some useful information as to what happened. 
> 
> I don't think this is a bug outside the sys-net, but is a bug involved inside 
> the sys-net VM. Whatever happens, it should probably show up in the 
> journalctl before it freezes. But I'm not an expert though.

Thanks for all the advice, and for the pointer to other thread.

For the record, the problem does not happen for me with every sleep/wake.  
Although for a while earlier today I thought it was.  The last several wakes 
have not had the problem.  When it happens again, I'll take your advice here.

Cheers, -Dave

-- 
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/b1bbf66e-fe4d-401d-a0a2-9fb59041d42e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] sys-net unresponsive after wake from sleep

2018-02-07 Thread Dave C
I've upgraded a laptop from 3.2 to 4.0rc4.  I didn't have the problem described 
here in 3.2...

When I sleep the laptop (by closing lid), I find that every time I wake it, 
sys-net is unresponsive.  

I cannot bring up a terminal in sys-net.  Terminals already open are 
unresponsive to input.

Calling `qvm-shutdown sys-net` does nothing.  `qvm-kill sys-net` does kill it.

I can restart sys-net and call `qvm-prefs -s sys-firewall netvm sys-net`, in 
order to be connected to internet again.

How can I troubleshoot sys-net, given the description above?  Which logs should 
I be looking at?

I have tried putting iwlmvm and iwlwifi in /rw/config/suspend-module-blacklist, 
but that has not changed the behavior.  I'm just not sure what else to try.  
Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/00dd019d-8692-4df9-b032-b3286f0cb85b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: templates update fail over sys-usb (but work using sys-net, on Qubes 4.x rc4)

2018-02-03 Thread Dave C
On Saturday, February 3, 2018 at 1:56:14 PM UTC-8, Yuraeitha wrote:
[ ... snip ... ]

> It might be a good idea to put this on github, chances are that they might 
> fix it soon if the problem is general issue for all USB tethering's, which 
> could affect many people, thus possibly given higher priority in the limited 
> resources available. They can also better keep track of the issue on github. 
> Try report it on github if possible.

I'll try to reproduce when time permits, and write this up better in a github 
issue.

> 
> btw, just to be sure, are you using it in this order? 
> sys-net --> sys-usb --> sys-firewall, and tying your Qubes-Global-Settings 
> for NetVM updates to sys-usb?

No, I'm switching between

1. sys-net --> sys-firewall --> appvms  (the out of the box default)
2. sys-usb --> sys-firewall --> appvms  (sys-net disconnected)

And the behavior I see is...

setting #1, `dnf install ...` *succeeds* in appvms, *succeeds* in templates
setting #2, `dnf install ...` *succeeds* in appvms, *fails* in templates

The way the templates fail has switched from the error in my first post, to the 
error in my later post.



-- 
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/287302af-1d08-4f1f-82ad-885a247ae093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] templates update fail over sys-usb (but work using sys-net, on Qubes 4.x rc4)

2018-02-03 Thread Dave C
I've noticed that in templates, `dnf` fails, i.e.

```
user@f26-devel ~]$ sudo dnf install tmux
Error: Failed to synchronize cache for repo 'updates'
```

While in an appvm, the same command works fine.

The failure above occurs when I have sys-firewall using *sys-usb* (that is, 
 tethering over usb).

When I switch sys-firewall to use *sys-net*, then `dnf` works!

I've checked my settings in "Qubes Global Settings" and they show "UpdateVM" is 
sys-firewall.  But I have to wonder is it actually using sys-net? Or does it 
only work when sys-firewall uses sys-net?



-- 
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/2b1a723d-a3fb-4809-8377-269af1c6f6c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] TPM: Device not found (Lenovo P51, Qubes 4.x)

2018-02-03 Thread Dave C
I'm having trouble finding TPM troubleshooting tips.  Any pointers?

I've installed 4.x RC4 on a Lenovo thinkpad P51.  The HCL (attached) shows

TPM: Device not found

In the bios, TPM 2.0 is enabled.

Thanks in advance. -Dave

-- 
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/afc13b69-4650-4084-99da-92514ba440d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HHCTO1WW-20180203-093935.yml
Description: Binary data


[qubes-users] upgrade 3.x -> 4.x, "firewall has been modified manually - please use qvm-firewall"

2018-02-03 Thread Dave C
My question comes after restoring a backup of a 3.x appvm into a 4.x Qubes.

When I pull up the "Qube Settings" GUI, and navigate to "Firewall Rules", I see 
red text instructing me to please use qvm-firewall.  The form is grayed out.

If I run `qvm-firewall VMNAME list`, I see the one rule that I had added via 
the Qubes 3.x GIU.

I prefer to use the GUI rather than `qvm-firewall`.  Is there anything I can do 
to make Qubes think the firewall hasn't been modified manually?

(I tried deleting `/var/lib/qubes/appvms/VMNAME/firewall.xml`. That alone was 
not enough.)

Thanks for any help!

Since this is my first post with Qubes 4.x on a Lenovo P51, I'm attaching hcl 
report.  The installation worked very well.  And I love the changes in 4.x.  
Excellent 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/92a8e565-4d69-4b58-b113-3ef5d347747e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HHCTO1WW-20180203-093935.yml
Description: Binary data


Re: [qubes-users] Re: Qubes OS screensharing

2018-02-01 Thread Dave C
On Sunday, January 28, 2018 at 12:24:08 PM UTC-8, Vít Šesták wrote:
> On January 27, 2018 7:57:02 AM GMT+01:00, Dave C wrote:
> >* VMs that can't access the conference site (i.e. bluejeans.com) or
> >can't access the net at all
> 
> How can a VM without network access open a window in the X11 accessible from 
> network?

Indeed, I stand corrected.  This point could apply to a restrictive firewall, 
but the VM would need to network with the local VM running vncserver.

[snip]
> 
> >My approach lowers security while screensharing.  But the rest of the
> >time, not screensharing, the VMs are running with normal firewall
> >settings.
> 
> It is likely that a VM can infect any other of the VMs (or the screensharing 
> VM). There are multiple potential ways to do so:
> 
> a. Exploit some vulnerability in X11 protocol implementation.
> b. Open a terminal (if not already opened) and type a command. This is 
> possible, because any client can inject any input events to other client.

I can imagine opening a terminal in the VM running vncserver and the window 
manager.  Could attacker open a terminal in other vm that has opened some 
application in that display?  (Application that is not a terminal, I mean.  I 
do see how an attacker could use any application shown in the display.)

> c. Download some file using webbrowser and run/install it (e.g., using some 
> packaging system).
> d. I remember I have read that X11 effectively provides no isolation between 
> apps and I had an impression that any app can by design even run some code in 
> another client. However, don't take this point as verified unless you verify 
> it from some other source.

You make some great points.  Thanks.  I'm re-thinking my approach.

-Dave

> 
> Regards,
> Vít Šesták 'v6ak'
> 
> General note: Maybe top-posting is bad. However, quoting whole message 
> (including quotes of quotes and quotes of quotes of quotes etc.) before your 
> message is even worse. Please don't let others scroll extensively.

-- 
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/777001bc-545b-419f-ab74-c1b160e1b48a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS screensharing

2018-01-26 Thread Dave C
On Thursday, January 25, 2018 at 1:34:03 AM UTC-8, Vít Šesták wrote:
> Dave, why you start a new VM and not just use a loopback? Is the reason 
> sharing apps from multiple VMs? If si, you are at least significantly 
> weakening isolation. Maybe you are not keeping any, not sure. X11 was not 
> designed for isolation at all.

I run the vncserver in a new VM so that I can screenshare from...

* multiple app VMs
* VMs that can't access the conference site (i.e. bluejeans.com) or can't 
access the net at all
* VMs that don't have vncserver installed, or don't have a plugin needed to 
screenshare

My approach lowers security while screensharing.  But the rest of the time, not 
screensharing, the VMs are running with normal firewall settings.

I realize X11 is a weak link in what might be an otherwise secure desktop.  One 
of the reasons I am a fan of Qubes!

-- 
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/b9567fb7-af2f-4e12-8421-21a9ef6168c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS screensharing

2018-01-23 Thread Dave C
I hope no one minds reviving an old thread...

I recently needed to screenshare in Qubes (4.x, but 3.2 should work the same).  
I wrote up my notes:

https://www.dave-cohen.com/blog/qubes-vnc-screenshare/

Feedback welcome, especially if the method can be improved.  Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7c9de595-73db-4251-a5c8-e317cab6cc30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-usb starts, but custom-usb vm fails with "Unable to reset PCI device..." (4.x-rc3)

2018-01-03 Thread Dave C
On Wednesday, January 3, 2018 at 12:48:49 PM UTC-8, Ilpo Järvinen wrote:
> On Wed, 3 Jan 2018, Dave C wrote:
> 
> > I've tried the -o no-string-reset=True option, that had no effect.
> 
> Is this just a typo in the email or was there one also in the command?
> It should be "strict", not "string".
> 
> -- 
>  i.

I'm embarrassed!  Nice catch, that typo was it.

I set it correctly `no-strict-reset=True`, then rebooted.  And thanks to you 
I'm typing this on a more comfortable keyboard.

Cheers, -Dave

-- 
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/971ac524-5dcf-4255-b0df-7f219f5a229f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] sys-usb starts, but custom-usb vm fails with "Unable to reset PCI device..." (4.x-rc3)

2018-01-03 Thread Dave C
I'd like to leave sys-usb as is, but create another usb vm for attaching a 
keyboard (without networking).

My problem is that my new "usb-keyboard" vm fails to start.  With "Start 
failed: internal error: Unable to reset PCI device :00:14.0: no FLR, PM 
reset or bus reset available"

I've tried the -o no-string-reset=True option, that had no effect.

I tried cloning sys-usb.  Still sys-usb has no problem starting up, but the 
clone gives the error.

I've rebooted the machine, with neither usb vm auto-starting, and even when I 
start usb-keyboard as the first vm to attach 00:14.0, it gives the error.  
After usb-keyboard gives that error, sys-usb has no problem starting.

I've compared the output of `qvm-prefs sys-usb` vs `qvm-prefs usb-keyboard` and 
I don't see any significant difference.

So, what sort of hidden difference is there between sys-usb and my custom usb 
vm that allows sys-usb to start?

Appreciate any help, thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/237b9755-32b9-4932-b90b-289e838bca9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] template /home/user is not copied when creating appvm

2017-12-19 Thread Dave C
According to https://www.qubes-os.org/doc/templates/ ,

Whenever a TemplateBasedVM is created, the contents of the /home directory 
of its parent TemplateVM are copied to the child TemplateBasedVM’s /home...

Is this true in Qubes 4.0 rc3?

In my experience, changes made to /home/user in the template are not copied to 
the appvm when it is created.

Thanks for any help.  -Dave

-- 
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/66505f5d-68bf-4208-aeb9-4c74714e39e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: off topic - invite codes to 'riseup'

2017-10-15 Thread Dave C
On Friday, July 28, 2017 at 7:16:36 AM UTC-7, little help wrote:
[snip...]
> 
> This also might also work: 
> 1.Go here: https://user.riseup.net/
> 
> 2.Make a "help ticket", and write "I need an invitation code because I 
> want to use(write your messages!!)".
> ^ Don't copy & paste my sentence! Use your words!
> 
> 3.Then, someone(Riseup user) will assist you.



Just FYI, I tried this and was declined with:

```
The following message has been posted in response to your question:

"Red Accounts" are needed for email, chat, VPN and the help desk. In order to 
create a Red Account you will need an invite: Find a friend that already has a 
riseup email account. After logging in to account.riseup.net your friend can 
create an invite code. You can use this invite on account.riseup.net to create 
your own account. 
Some remarks: 
- You only need one invite. 
- Newly created accounts can not be used to create invite codes. 
Due to the numerous requests by spammers and scammers that tried to get a 
riseup account we have to insist on invites for new accounts. We know that this 
sucks. We are sorry about it but it is the only thing that makes sense right 
now.
```


-- 
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/9e9d9e67-3809-47e4-b829-5fee2695f384%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Ledger Nano S on Qubes OS R3.2

2017-07-18 Thread Dave C
On Sunday, April 30, 2017 at 3:02:23 AM UTC-7, 0x...@secure.mailbox.org wrote:
> Hi, 
> Does anyone actually make Qubes OS R 3.2 working with Ledger Nano S hardware 
> wallet? 

Yes.

Follow the Qubes instructions: 
https://www.qubes-os.org/doc/usb/#attaching-a-single-usb-device-to-a-qube-usb-passthrough

In your AppVM, follow these extra instructions from ledger: 
http://support.ledgerwallet.com/knowledge_base/topics/ledger-wallet-is-not-recognized-on-linux

What's working for me is these lines appended to `/rw/config/rc.local` in AppVM:

# 
http://support.ledgerwallet.com/knowledge_base/topics/ledger-wallet-is-not-recognized-on-linux

```
#!/bin/bash
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1b7c\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"2b7c\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"3b7c\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"4b7c\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1807\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2581\", 
ATTRS{idProduct}==\"1808\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2c97\", 
ATTRS{idProduct}==\"\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
echo "SUBSYSTEMS==\"usb\", ATTRS{idVendor}==\"2c97\", 
ATTRS{idProduct}==\"0001\", MODE=\"0660\", OWNER=\"user\", GROUP=\"plugdev\"" 
>>/etc/udev/rules.d/20-hw1.rules
udevadm trigger
udevadm control --reload-rules
```

Note: every time you switch into or out of an "app" on the ledger, the USB 
connection reset.  So you have to run, in dom0, `qvm-block -a ...` much more 
frequently than you might expect.

The Ledger Nano is brand new, so I haven't tested much beyond just getting the 
desktop apps to recognize it.

-- 
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/674fe279-1c17-495c-ba67-6dbf34467f63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Installation Problems; Qubes 3.2

2017-07-04 Thread Dave C
On Monday, July 3, 2017 at 6:30:34 PM UTC-7, guess...@gmail.com wrote:
> Were you able to get into the grub menu? 
> I am lost in trying so myself.

I had success, after much trouble, getting Qubes 3.2 to install on a recent 
lenovo and UEFI.  I described how here: 
https://groups.google.com/forum/#!searchin/qubes-users/uefi%7Csort:relevance/qubes-users/4VsKdxnKHBk/mEb1VIImBAAJ

-- 
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/1436dbc1-72a3-44cf-9f93-ec5ff6566706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: install Qubes 3.2 Stucked at "Starting Switch Root..."

2017-06-26 Thread Dave C
On Thursday, June 1, 2017 at 8:33:07 PM UTC-7, Paulo Marques wrote:
> Hi There,
> 
> I hope you guys can help me, I'm new to Qubes Os and i was trying to install 
> Qubes 3.2 but i'm stacked at "Starting to switch root..." and it just won't 
> proceed the installation. I've tried do enabled/disabled Uefi mode on the 
> bios, changed it to Uefi with legacy OPROM, but the result is always the 
> same, i'm stalled there. Can someone help me please! I really would like to 
> make a change in my system and i'd love to change to Qubes Os.
> 
> I'm running on a core I5 6500 With a Z270-P Asus Motherboard, 275GB SSD 
> Crucial disk and 16GB of Ram.


I'm curious whether the approach I posted to 
https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk works for you.

-- 
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/0af6af8d-c676-4641-b52a-be878db165e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: trouble with Lenovo P51 (nvidia quadro m1200)

2017-06-26 Thread Dave C
I'm happy to report that I have Qubes running on the P51 now.  I had 
considerable trouble getting it installed on the NVME drive.  What finally 
worked for me, I've shared in a separate post:

https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk

I did not end up needing nvidia drivers.  Maybe in the future I'll mess around 
with that again.  But for the time being I'm content with the display, and 
appreciate the kernel without nvidia's proprietary "taint".

One problem that does bother me... the laptop occasionally does not wake from 
suspend.  More often than not, it resumes just fine.  But from time to time it 
does not and I have to power off then reboot.

HCL report attached!

-- 
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/9ebc9af6-238b-46fd-b648-7e695a477542%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HHCTO1WW-20170625-233603.yml
Description: Binary data


[qubes-users] Qubes 3.2 UEFI install media

2017-06-26 Thread Dave C
I recently had some success install Qubes 3.2 on a lenovo p51, booting UEFI.  I 
went through a lot of a trial and error in the process.  I'm hoping this post 
can save others some time.  I've seen in other threads some struggling to get 
Qubes working with UEFI firmware.

I intended to save my command history to disk so that I could post step-by-step 
exactly what to do.  But I must have been in a dispvm at the time, because now 
I can't find that history.  So the following is from memory and not precise.

I tried every trick I could find related to Qubes UEFI installation, and 
thinkpad troubleshooting.  What finally worked does not appear to be documented 
in any of the Qubes documentation.  Qubes uses Fedora's installer, Anaconda, 
and the following approach is documented on Fedora's wiki.

1. Follow Qubes install guide up to the `dd` command.  Don't write to usb with 
`dd`.
https://www.qubes-os.org/doc/installation-guide/

2. Instead, use Fedora's `livecd-iso-to-disk` tool.  You'll need the 
`livecd-tools` package.  See 
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29

I don't recall for certain exactly what I passed to `livecd-iso-to-disk`.  Try 
this:

sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso /dev/xvdi

The media as written will not quite boot, yet.  Qubes EFI boot is configured to 
find a label "Qubes-R3.2-x86_64", but the media written by the livecd tool is 
labelled "BOOT" (and the filesystem does not support the longer label, so the 
--label option would not help).

3. Mount the usb media (/dev/xvdi in the example above)

4. Edit xen.cfg.  If I recall correctly, `/EFI/BOOT/xen.cfg`.

In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64` with 
`LABEL=BOOT`

You should now have install media that work on UEFI firmware!


After install, I recommend upgrading kernel version for recent hardware.  I.e. 
with

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel 
kernel-qubes-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/54565916-4ae7-4029-8349-3c0afc59bb24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: trouble with Lenovo P51 (nvidia quadro m1200)

2017-06-04 Thread Dave C
On Wednesday, May 31, 2017 at 7:59:07 AM UTC-7, Dave C wrote:
> On Wednesday, May 31, 2017 at 7:44:49 AM UTC-7, Dave C wrote:
> > Trying to install Qubes on a laptop with graphics card 
> > NVIDIA Quadro M1200 4GB GDDR5
> > 
> > The 3.2 installer fails to start X, and falls back to text mode.  (Which 
> > complains something about disk entryption and fails to complete the 
> > install.)
> > 
> > I have Qubes 3.2 installed on a portable SSD, so I tried booting the P51 to 
> > that.  It made it as far as prompting for the disk password, again in text 
> > mode.  After typing the password the boot stopped with only a flashing 
> > cursor (underbar) in the upper left corner of the display.  No errors, just 
> > stopped there.
> > 
> > I've read some troubleshooting tips...
> > 
> > Tried disabling VT-d in bios - no difference.
> > 
> > Tried `iommu=no-igfx`on the boot line - again no difference.
> > 
> > And I've found https://www.qubes-os.org/doc/install-nvidia-driver/ and 
> > reading that now.  Is this page up to date?  (It mentions "fedora 18").
> > 
> > I thought this machine would be great for Qubes, as it has tons of RAM 
> > among other things.  But maybe not so much!
> > 
> > Appreciate any suggestions.  Thanks,
> > -Dave
> 
> Since posting this, I've found quite a lot of nvidia threads in this group.
> 
> i.e. 
> https://groups.google.com/forum/#!topic/qubes-users/v26zXkiNElg/discussion
> ...and others.
> 
> I'll share here if I make any progress with those suggestions.

tl;dr - Unable to boot this machine to Qubes.  Install completes, but cannot 
boot from the nvme drive where I've installed Qubes.  Can't boot installer 
media to UEFI.

I got past the graphical UI and Xorg problem.  The trick was a setting in BIOS. 
 Changed from "hybrid graphics" to "discrete" (can't recall the exact wording). 
 While the system is not doing anything fancy with the graphics card, the 
basics are working.

Unfortunately, after installing completes without errors, the system will not 
boot.  Now, I believe the problem has to do with UEFI boot from nvme drive.

I've tried to troubleshoot following 
https://www.qubes-os.org/doc/uefi-troubleshooting/.  The "Installation finished 
but “Qubes” boot option is missing and xen.cfg is empty" section sounded 
perfect, because that describes my problem.

When I get to the step of running `efibootmgr`, I get error "EFI variables are 
not supported on this system".

Some searching has turned up that the system must have been booted via UEFI and 
not legacy in order to use `efibootmgr`.  

But here I am stuck! My qubes installer USB stick will only start up in legacy 
boot mode!

I've tried other settings in my bios (UEFI only, or UEFI first) and then I get 
a grub menu when booting the qubes installer.  But each selection on that menu 
fails to boot!  The xen EFI loader says something like "failed to boot both 
default and fallback entries."

Worth noting, I've seen https://www.qubes-os.org/doc/thinkpad-troubleshooting/ 
and I've left the `USB UEFI BIOS SUPPORT` enabled, while disabling other secure 
boot and eufi options.  I feel like I've tried almost every combination of 
options by now.  I've also tried appending `/mapbs /noexitboot` and/or `-- 
efi=attr=uc` to the chainloader line.  This also does not change the behavior.  
An error flashes too briefly for me to read what it says.

Any suggestions appreciated!  Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2c163a73-47ba-4220-9122-0c325a05e181%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] kernel-devel and kernel-header version mismatch

2017-06-03 Thread Dave C
On Friday, June 2, 2017 at 4:51:01 PM UTC-7, Unman wrote:
> On Thu, Jun 01, 2017 at 09:37:31PM -0700, Dave C wrote:
> > On Thursday, June 1, 2017 at 9:17:46 AM UTC-7, Unman wrote:
> > > On Thu, Jun 01, 2017 at 08:16:32AM -0700, Dave C wrote:
> > > > I'm trying to build nvidia module in dom0.  Following steps found in 
> > > > https://groups.google.com/forum/#!topic/qubes-users/v26zXkiNElg/discussion
> > > > 
> > > > At the step where kernel-headers and kernel-devel are installed into 
> > > > dom0, I'm getting a version mismatch between the kernel I'm running 
> > > > versus those packages.
> > > > 
> > > > I've also read https://www.qubes-os.org/doc/managing-vm-kernel/ but 
> > > > doesn't seem to address what I'm asking here.
> > > > 
> > > > 
> > > > on dom0, `uname -r` returns:
> > > > 
> > > > 4.4.67-12.pvops.qubes.x86_64
> > > > 
> > > > 
> > > > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > > > "kernel-qubes-vm` returns:
> > > > 
> > > > Last metadata expiration check: 0:42:31 ago on Thu Jun  1 07:23:06 2017.
> > > > Installed Packages
> > > > kernel-qubes-vm.x86_64  1000:4.4.38-11.pvops.qubes   @System
> > > > 
> > > > kernel-qubes-vm.x86_64  1000:4.4.55-11.pvops.qubes   @System
> > > > 
> > > > kernel-qubes-vm.x86_64  1000:4.4.67-12.pvops.qubes   @System
> > > > 
> > > > Available Packages
> > > > kernel-qubes-vm.x86_64  1000:4.8.12-12.pvops.qubes   
> > > > qubes-dom0-unstable
> > > > Installed Packages
> > > > kernel-qubes-vm.x86_64   1000:4.4.38-11.pvops.qubes   
> > > > @qubes-dom0-cached
> > > > kernel-qubes-vm.x86_64   1000:4.4.55-11.pvops.qubes   
> > > > @qubes-dom0-cached
> > > > kernel-qubes-vm.x86_64   1000:4.4.67-12.pvops.qubes   
> > > > @qubes-dom0-cached
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > > > "kernel-devel` returns:
> > > > 
> > > > Last metadata expiration check: 0:44:38 ago on Thu Jun  1 07:23:06 2017.
> > > > Installed Packages
> > > > kernel-devel.x86_64  1000:4.8.12-12.pvops.qubes 
> > > >  @System
> > > > Installed Packages
> > > > kernel-devel.x86_641000:4.8.12-12.pvops.qubes 
> > > > @qubes-dom0-cached
> > > > 
> > > > 
> > > > 
> > > > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > > > "kernel-headers` returns:
> > > > 
> > > > Installed Packages
> > > > kernel-headers.x86_64  4.8.13-100.fc23  
> > > >  @System
> > > > Installed Packages
> > > > kernel-headers.x86_64 4.8.13-100.fc23 
> > > > @qubes-dom0-cached
> > > > 
> > > > 
> > > > 
> > > > Notice that even if I install kernel 4.8.12-12 from 
> > > > qubes-dom0-unstable, there is a mismatch between kernel-devel 
> > > > (4.8.12-12) and kernel-headers (4.8.13-100).
> > > > 
> > > > I welcome any advice about how to manage kernel modules built in dom0.  
> > > > How do I resolve the version mismatch described here?  And also how do 
> > > > I keep a functioning module when kernel versions update in the future?
> > > > 
> > > > Thanks, -Dave
> > > > 
> > > 
> > > You can find rpms for the headers at yum.qubes-os.org
> > > Look at (e.g) r3.2/current/dom0/fc23/rpm and you'll see kernel-devel
> > > packages to suit. Poke about and you'll find most everything you need.
> > > 
> > > The obvious way to keep current is to use dkms which will automatically
> > > rebuild modules with a kernel upgrade. You will, of course, need to
> > > ensure that you upgrade the kernel devel package too.
> > > Otherwise you need to manually rebuild the module on an upgrade.
> > > 
> > > unman
> > 
> > Hi Unman,
> > 
> > Thanks for that suggestion.  I was able to download the matching 
> > kernel-devel.  And with it, complete the instructions to compile the n

Re: [qubes-users] kernel-devel and kernel-header version mismatch

2017-06-01 Thread Dave C
On Thursday, June 1, 2017 at 9:17:46 AM UTC-7, Unman wrote:
> On Thu, Jun 01, 2017 at 08:16:32AM -0700, Dave C wrote:
> > I'm trying to build nvidia module in dom0.  Following steps found in 
> > https://groups.google.com/forum/#!topic/qubes-users/v26zXkiNElg/discussion
> > 
> > At the step where kernel-headers and kernel-devel are installed into dom0, 
> > I'm getting a version mismatch between the kernel I'm running versus those 
> > packages.
> > 
> > I've also read https://www.qubes-os.org/doc/managing-vm-kernel/ but doesn't 
> > seem to address what I'm asking here.
> > 
> > 
> > on dom0, `uname -r` returns:
> > 
> > 4.4.67-12.pvops.qubes.x86_64
> > 
> > 
> > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > "kernel-qubes-vm` returns:
> > 
> > Last metadata expiration check: 0:42:31 ago on Thu Jun  1 07:23:06 2017.
> > Installed Packages
> > kernel-qubes-vm.x86_64  1000:4.4.38-11.pvops.qubes   @System
> > 
> > kernel-qubes-vm.x86_64  1000:4.4.55-11.pvops.qubes   @System
> > 
> > kernel-qubes-vm.x86_64  1000:4.4.67-12.pvops.qubes   @System
> > 
> > Available Packages
> > kernel-qubes-vm.x86_64  1000:4.8.12-12.pvops.qubes   
> > qubes-dom0-unstable
> > Installed Packages
> > kernel-qubes-vm.x86_64   1000:4.4.38-11.pvops.qubes   
> > @qubes-dom0-cached
> > kernel-qubes-vm.x86_64   1000:4.4.55-11.pvops.qubes   
> > @qubes-dom0-cached
> > kernel-qubes-vm.x86_64   1000:4.4.67-12.pvops.qubes   
> > @qubes-dom0-cached
> > 
> > 
> > 
> > 
> > 
> > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > "kernel-devel` returns:
> > 
> > Last metadata expiration check: 0:44:38 ago on Thu Jun  1 07:23:06 2017.
> > Installed Packages
> > kernel-devel.x86_64  1000:4.8.12-12.pvops.qubes  
> > @System
> > Installed Packages
> > kernel-devel.x86_641000:4.8.12-12.pvops.qubes 
> > @qubes-dom0-cached
> > 
> > 
> > 
> > `qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
> > "kernel-headers` returns:
> > 
> > Installed Packages
> > kernel-headers.x86_64  4.8.13-100.fc23   
> > @System
> > Installed Packages
> > kernel-headers.x86_64 4.8.13-100.fc23 
> > @qubes-dom0-cached
> > 
> > 
> > 
> > Notice that even if I install kernel 4.8.12-12 from qubes-dom0-unstable, 
> > there is a mismatch between kernel-devel (4.8.12-12) and kernel-headers 
> > (4.8.13-100).
> > 
> > I welcome any advice about how to manage kernel modules built in dom0.  How 
> > do I resolve the version mismatch described here?  And also how do I keep a 
> > functioning module when kernel versions update in the future?
> > 
> > Thanks, -Dave
> > 
> 
> You can find rpms for the headers at yum.qubes-os.org
> Look at (e.g) r3.2/current/dom0/fc23/rpm and you'll see kernel-devel
> packages to suit. Poke about and you'll find most everything you need.
> 
> The obvious way to keep current is to use dkms which will automatically
> rebuild modules with a kernel upgrade. You will, of course, need to
> ensure that you upgrade the kernel devel package too.
> Otherwise you need to manually rebuild the module on an upgrade.
> 
> unman

Hi Unman,

Thanks for that suggestion.  I was able to download the matching kernel-devel.  
And with it, complete the instructions to compile the nvidia module.

(Unfortunately, didn't make a difference for the system I'm trying to run qubes 
on. So I still have something to figure out.)

Do you happen to know why `qubes-dom0-update` doesn't find the repo you refered 
to automatically?  It's enabled in /etc/yum.repos.d/qubes-dom0.repo.

-- 
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/47124307-47f9-44b1-801c-2538a5ee4f4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] kernel-devel and kernel-header version mismatch

2017-06-01 Thread Dave C
I'm trying to build nvidia module in dom0.  Following steps found in 
https://groups.google.com/forum/#!topic/qubes-users/v26zXkiNElg/discussion

At the step where kernel-headers and kernel-devel are installed into dom0, I'm 
getting a version mismatch between the kernel I'm running versus those packages.

I've also read https://www.qubes-os.org/doc/managing-vm-kernel/ but doesn't 
seem to address what I'm asking here.


on dom0, `uname -r` returns:

4.4.67-12.pvops.qubes.x86_64


`qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
"kernel-qubes-vm` returns:

Last metadata expiration check: 0:42:31 ago on Thu Jun  1 07:23:06 2017.
Installed Packages
kernel-qubes-vm.x86_64  1000:4.4.38-11.pvops.qubes   @System
kernel-qubes-vm.x86_64  1000:4.4.55-11.pvops.qubes   @System
kernel-qubes-vm.x86_64  1000:4.4.67-12.pvops.qubes   @System
Available Packages
kernel-qubes-vm.x86_64  1000:4.8.12-12.pvops.qubes   qubes-dom0-unstable
Installed Packages
kernel-qubes-vm.x86_64   1000:4.4.38-11.pvops.qubes   @qubes-dom0-cached
kernel-qubes-vm.x86_64   1000:4.4.55-11.pvops.qubes   @qubes-dom0-cached
kernel-qubes-vm.x86_64   1000:4.4.67-12.pvops.qubes   @qubes-dom0-cached





`qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
"kernel-devel` returns:

Last metadata expiration check: 0:44:38 ago on Thu Jun  1 07:23:06 2017.
Installed Packages
kernel-devel.x86_64  1000:4.8.12-12.pvops.qubes  @System
Installed Packages
kernel-devel.x86_641000:4.8.12-12.pvops.qubes @qubes-dom0-cached



`qubes-dom0-update --action=list --enablerepo=qubes-dom0-unstable 
"kernel-headers` returns:

Installed Packages
kernel-headers.x86_64  4.8.13-100.fc23   @System
Installed Packages
kernel-headers.x86_64 4.8.13-100.fc23 @qubes-dom0-cached



Notice that even if I install kernel 4.8.12-12 from qubes-dom0-unstable, there 
is a mismatch between kernel-devel (4.8.12-12) and kernel-headers (4.8.13-100).

I welcome any advice about how to manage kernel modules built in dom0.  How do 
I resolve the version mismatch described here?  And also how do I keep a 
functioning module when kernel versions update in the future?

Thanks, -Dave

-- 
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/e931afcd-9fc2-406a-8d32-5daf2d71cc9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] trouble with Lenovo P51 (nvidia quadro m1200)

2017-05-31 Thread Dave C
Trying to install Qubes on a laptop with graphics card 
NVIDIA Quadro M1200 4GB GDDR5

The 3.2 installer fails to start X, and falls back to text mode.  (Which 
complains something about disk entryption and fails to complete the install.)

I have Qubes 3.2 installed on a portable SSD, so I tried booting the P51 to 
that.  It made it as far as prompting for the disk password, again in text 
mode.  After typing the password the boot stopped with only a flashing cursor 
(underbar) in the upper left corner of the display.  No errors, just stopped 
there.

I've read some troubleshooting tips...

Tried disabling VT-d in bios - no difference.

Tried `iommu=no-igfx`on the boot line - again no difference.

And I've found https://www.qubes-os.org/doc/install-nvidia-driver/ and reading 
that now.  Is this page up to date?  (It mentions "fedora 18").

I thought this machine would be great for Qubes, as it has tons of RAM among 
other things.  But maybe not so much!

Appreciate any suggestions.  Thanks,
-Dave

-- 
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/a3c5fe57-2d36-49de-84b6-b9f5f6cdeafd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting USB Quebes across multiple machines?

2017-05-30 Thread Dave C
On Monday, May 29, 2017 at 3:13:32 PM UTC-7, Eric Duncan wrote:
> Thanks Vit and Dave C!
> 
> @Dave:
> 
> Yep, USB sticks get too hot - and the USB2 sticks I tried were far too slow 
> for my taste.
> 
> I have a couple of these laying around from previous laptop builds:
> 
> https://www.amazon.com/Transcend-128GB-MSA370-mSATA-TS128GMSA370/dp/B00K64HXAA/?tag=eduncan911-20
> 
> Was going to use one and the smallest msata usb3 adapter I could find, like 
> this:
> 
> https://www.newegg.com/Product/Product.aspx?Item=9SIA6V83ZJ7496
> 
> But didn't want to buy that, and go through the trouble of setting things up 
> and migrating over if it was going to have problems.
> 
> Hearing that you have a multi-machine setup, with just a tweak it seems, 
> assures me.  
> 
> Ordering today!
> 
> Thank you guys!
> Eric
> 
> On Monday, May 29, 2017 at 8:59:16 AM UTC-4, Dave C wrote:
> > On Saturday, May 27, 2017 at 12:23:37 AM UTC-7, Vít Šesták wrote:
> > > I've asked some slightly similar question like a month ago. I was told I 
> > > should run dracut without hostonly mode in order to have all the modules 
> > > I need.
> > > 
> > > Your case is a bit harder. You would need to either run dracut after any 
> > > kernel update (without this, it might make Qubes unbootable on other 
> > > machines than the one you have updated it from) or reconfigure dracut 
> > > (like edit something in /etc) if possible.
> > > 
> > > Regards,
> > > Vít Šesták 'v6ak'
> > 
> > To always run dracut without hostonly, make a file 
> > /etc/dracut.conf.d/no-hostonly.conf, and in there put:
> > 
> > hostonly="no"
> > 
> > 
> > I do the above to have a portable Qubes that I can boot on multiple 
> > machines.  Mostly this works fine, but occasional issues:
> > 
> > * If you ever assign PCI devices, those will of course change from machine 
> > to machine.
> > * I find USB sticks get hot, and slow.  I recommend installing on a 
> > portable SSD instead (which can plug into USB port).
> > * I have a laptop which boots incredibly slowly.  There is a roughly 2 
> > minute delay in the boot process.  I suspect it is waiting for PS/2, but 
> > the machine has none. Although I'm not sure, and not sure how to 
> > troubleshoot.
> > 
> > -Dave

I'm using an SSD similar to this, which is easily portable: 
https://www.google.com/url?q=https%3A%2F%2Fwww.newegg.com%2FProduct%2FProduct.aspx%3FItem%3D9SIA6V83ZJ7496=D=1=AFQjCNEhmEmGAIBVz5A7wE34AkTjUr60zw

(I don't see the brand I have featured on Amazon anymore.)

One nuisance is when moving that from one machine to another, I typically have 
to make a netvm per computer I boot, because they use different hardware.  
After moving the drive to a new machine, I have to stop the firewall and netvm, 
switch which netvm the firewall users, then start an appvm.

-Dave

-- 
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/e2ccdacb-c619-4e6b-bd39-0706d726ad61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting USB Quebes across multiple machines?

2017-05-29 Thread Dave C
On Saturday, May 27, 2017 at 12:23:37 AM UTC-7, Vít Šesták wrote:
> I've asked some slightly similar question like a month ago. I was told I 
> should run dracut without hostonly mode in order to have all the modules I 
> need.
> 
> Your case is a bit harder. You would need to either run dracut after any 
> kernel update (without this, it might make Qubes unbootable on other machines 
> than the one you have updated it from) or reconfigure dracut (like edit 
> something in /etc) if possible.
> 
> Regards,
> Vít Šesták 'v6ak'

To always run dracut without hostonly, make a file 
/etc/dracut.conf.d/no-hostonly.conf, and in there put:

hostonly="no"


I do the above to have a portable Qubes that I can boot on multiple machines.  
Mostly this works fine, but occasional issues:

* If you ever assign PCI devices, those will of course change from machine to 
machine.
* I find USB sticks get hot, and slow.  I recommend installing on a portable 
SSD instead (which can plug into USB port).
* I have a laptop which boots incredibly slowly.  There is a roughly 2 minute 
delay in the boot process.  I suspect it is waiting for PS/2, but the machine 
has none. Although I'm not sure, and not sure how to troubleshoot.

-Dave

-- 
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/501be4fc-3fc0-4513-be32-44b1814724e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Macbook Pro USB keyboard

2016-12-22 Thread Dave C
On Thursday, December 22, 2016 at 3:39:23 AM UTC-8, dumbcyber wrote:
> I'm very sorry to revive this thread. I've been trying to build another Qubes 
> environment on an SSD drive and have run into the same problem. I'm building 
> R3.2 for a Macbook Pro. I know Macbook's are not very well supported but I've 
> had my original Qubes environment running really well now for some time on 
> the Macbook Pro and want to move away from the USB stick to something more 
> long term.

My experience with Qubes on USB stick: I've had the USB become unresponsive, 
and hot to the touch.  I've had much better luck on a portable SSD.

I sometimes boot a mac to that SSD drive.  I find that holding the `option` key 
at boot time it is detected (labeled "Windows").  And I've had the same problem 
with the USB keyboard being unusable at boot time.

I work around that problem by preventing the hostonly optimizations in the 
initramfs.  In dom0, create a file /etc/dracut.conf.d/no-hostonly.conf, with 
this line:

hostonly="no"

Run `dracut -f` to build initramfs with the new configuration.  Then try 
booting on the mac.

This is what I stumbled upon.  While it works for the USB keyboard, it might 
have other consequences.  One that I know of is the booting on the mac includes 
a *really* long pause that I haven't figured out how to get rid of.  I read 
something once that made me believe it might be waiting for a PS/2 connection 
that doesn't exist.  Not sure, but would love help with that if anyone reading 
has any ideas.

The next hurdle you'll have with the macbook pro is getting broadcom wireless 
to work.  I've posted my experience there to 
https://groups.google.com/forum/#!msg/qubes-users/VVwWqvz5dX4/4byUgfp3EgAJ;context-place=forum/qubes-users

-- 
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/eb9bb588-3045-496d-b9af-2071728a2405%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes and Broadcom BCM4360 - A Success Story

2016-12-21 Thread Dave C
On Wednesday, December 21, 2016 at 8:47:49 AM UTC-8, Kent Davis wrote:
> My solution involves directly modifying the sys-net VM and I handle
> all the modules in sys-net:/rw/config/rc.local.
> 
> Is your rc.local executable?
> 

It is:

[user@net-powerbook24 ~]$ ls -l /rw/config/rc.local
-rwxr-xr-x 1 root root 523 Dec 18 15:57 /rw/config/rc.local

And I had a simple rc.local working for earlier version of fedora.  But with 
24, there are conflicting modules and I haven't managed to get it right.

I'm wondering when rc.local is executed during startup, and whether I need to 
explicitly wait for other startup to complete.  As I mentioned, my script works 
only after startup, when I manually run in a terminal.

-Dave

-- 
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/ee19bba7-99dc-4b65-ba66-8f09d9ef588f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes and Broadcom BCM4360 - A Success Story

2016-12-21 Thread Dave C
Since starting this thread, I've (belatedly) upgraded to Qubes 3.2.  In doing 
so, I never figured out how to get the old kernel for which I compiled the wl 
module to migrate over to the new install.  Unfortunately a VM's kernel is not 
included when backing it up.

Anyway, I thought of that as an excuse to upgrade my net vm for broadcom to the 
latest version of fedora.  Unfortunately things are not working 100%.  So while 
I've made progress, this is actually a call for help to get things working on 
fedora 24.

# Give the PCI Device Permissive Passthrough (on dom0)

https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues

My /etc/systemd/system/qubes-pre-netvm.service ended up like this:

```
[Unit]
Description=permission pci netvm fixup
Before=qubes-netvm.servce

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'echo ":03:00.0" > 
/sys/bus/pci/drivers/pciback/permissive'

[Install]
WantedBy=multi-user.target
```

# Preparation to compile modules

Start a VM running same template and kernel version that your netvm
will use.  This can be a dispvm.

>From 
>https://www.broadcom.com/support/download-search/?pf=Wireless+LAN+Infrastructure

Move tarball to that vm (if not there already) and extract with

```
tar xvzf hybrid-v25_64-nodebug-nopcoem-6_30_223_271.tar.gz
```

Conveniently the README is not included.  You might find it at
https://docs.broadcom.com/docs/1211168561592, a link which will soon
be just as broken as all its predecessors scattered all over the
internet.


## Compile the modules


```
# Install kernel-devel that matches running kernel!
sudo yum install "kernel-devel-uname-r == $(uname -r)"

# I think necessary (?)
sudo modprobe cfg80211

# possibly necessary (?)
sudo yum install gcc

# Finally
make
```

## Install

I compiled in a dvm, so my install procedure was...

First, on the dvm where I compiled:

```
# Copy the built module
qvm-copy-to-vm net-powerbook24 wl.ko

# Find out what the install command will be.  Note -n will not actually install.
make -n install
```

Now we can use the command shown by `make -n install` earlier, in the new net 
vm (net-powerbook24 in my case).

```
install -D -m 755 QubesIncoming/disp2/wl.ko /lib/modules/`uname 
-r`/kernel/drivers/net/wireless

# This is documented in the readme, but not done by the install command.
depmod -a
```

But we want the module to be loaded automatically when the netvm starts.  This 
is the part I'm having trouble with!  If anyone can suggest a better way, 
please let me know.

Start by using Marek's technique for custom modules.  
(https://groups.google.com/forum/#!msg/qubes-users/Wt9Nm7posho/msTN_v2oa_oJ)

I've been experimenting with what to put in /rw/config/rc.local.  What I have 
at the moment is shown below.  But here's the problem...

When first starting the netvm, it does not successfully use the wifi.  However, 
if I manually open a terminal and run `sudo /rw/config/rc.local` then it will 
be able to connect to wifi.  So, something about this script is working, but 
not working on initial vm startup!

I have the following in /rw/config/rc.local:

```
# Unload conflicting modules.
rmmod ssb
rmmod bcma
rmmod b43
rmmod brcmsmac
rmmod wl

# blacklist modules that may interfere with wl (broadcom)
# (Not convinced these actually prevent the modules from loading!)
echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf
echo "blacklist bcma" >> /etc/modprobe.d/blacklist.conf
echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf
echo "blacklist brcmsmac" >> /etc/modprobe.d/blacklist.conf

mount --bind /rw/modules /lib/modules
systemctl restart systemd-udevd

modprobe wl
```

...and make that rc.local executable.

I've tried various experiments. I've changed the order in that script of when I 
remove conflicting modules.  Nothing I've tried makes that script work 
successfully on startup.  I suspect that conflicting modules are loaded despite 
my attempt to blacklist them.  But when I run the script manually in a 
terminal, it works as hoped, and I can connect to wifi.  As I said earlier, I'd 
appreciate any help!

-- 
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/f191cec7-3514-427f-9e78-3ec066b9cec8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Node.js global modules

2016-08-27 Thread Dave C
On Wednesday, August 24, 2016 at 6:17:39 PM UTC-7, angelo "angico" costa wrote:
> Hi, all!
> 
> I'm using Qubes 3.1 and I'm new with all this compartimented system idea.
> 
> I use Node.js for my work and study, and several of its modules should to be 
> installed globally. My question is: Should I install those modules in the VM 
> where I'll use them, or should I install them from the template VM?
> 
> TIA and regards,
> 
> Angico.

I use node.js at times.  I'm often told to install something or other via `npm 
install -g ...`, which to me sounds like a bad idea.  I think if you find 
yourself typing `sudo npm ...` you might as well point a loaded gun at your 
operating system.

Instead, I install those packages locally.  I.e. if build instructions call for 
`grunt`, try

npm install grunt
./node_modules/.bin/grunt


That said, thank goodness for qubes!  If I must let `npm` litter my disk with 
rat's nest of dependencies, I can limit the damage to a VM where nothing of 
consequence happens.

-Dave

Snarky opinions expressed are my own and unfortunately not those of most 
people. :)


-- 
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/a4ad9eb9-b27c-43a3-a036-4ec597e41a8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.