[qubes-users] disposible vm shuts down after qvm-copy

[Dave C]

When I start a dvm, for example right click a file and "view in disposable 
vm", if I later open a terminal in that dvm and run "qvm-copy something", I 
find that the qvm-copy succeeds but the disposible vm shuts down (or 
crashes?) immediately.

Any idea what causes that?

-- 
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/8a5c9799-4bbb-4f91-8276-661958915e13o%40googlegroups.com.

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

[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?

[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.

Re: [qubes-users] Re: HCL - Latitude E6230

[Kaleb C Tilley]

rkd777,

I'm beginning to think that the embedded NIC for the system I purchased
doesn't match the embedded link used to verify this architecture as valid
for the QubesOS.  I feel as if I've wasted my money on this one .. oh well
.. :-(

Kaleb

--
Age doesn't always bring Wisdom...
... Sometimes Age comes alone.


On Wed, May 6, 2020 at 7:56 PM  wrote:

>
> I am hanging at network as well...any advice appreciated
>
>
> On Sunday, November 17, 2019 at 9:29:35 PM UTC, cany...@gmail.com wrote:
>>
>> Mike,
>>
>> I'm just starting to attempt loading Qubes4.8 onto a Dell Latitude
>> E6230.  It installs up to the point where it reboots onto the disk install,
>> and continues building the qube VMs.  At that point, it eventually hangs ..
>> apparently while configuring the network.  I think there may be an issue in
>> detecting the network device.  Did you have any difficulties during your
>> install?
>>
>> Thanks for any assistance you can provide.
>>
>> Kaleb
>>
>> On Saturday, June 2, 2018 at 1:47:26 AM UTC-4, Michael McShane wrote:
>>>
>>> AEM was a difficult only because I had a 128gb SSD but it configured
>>> anyway. Everything just works.
>>> Mike
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/7ktqAG6Up3U/unsubscribe.
> To unsubscribe from this group and all its topics, 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/2017f159-6696-456d-923f-d424fc3c08af%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CA%2BNeVCkSFEjpPLRAhcv3EhBPtnvGNDDB4EKNNmXH-x_3U-HmeA%40mail.gmail.com.

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

[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] Salt Questions

[Brian C. Duggan]

On 10/8/19 6:45 AM, Johannes Graumann wrote:
> 2) I'm unclear about whether the fedora-/debian-X-minimal template VMs 
> require additional packages to be managed through salt.
> https://www.qubes-os.org/doc/templates/minimal/ appears to indicate so:
>> Also, there are packages to provide additional services:
>> ...
>> qubes-mgmt-\*: If you want to use salt management on the template and 
>> qubes.
> 
> If that's indeed the case, it's actually not possible to manage minimal 
> template installation/customization entirely through salt, which I 
> consider suboptimal.
> 

Qubes does not require that these packages be installed on target VMs to
manage them.

The disposable management VM applies states through salt-ssh over
qrexec. So target VMs only need the qrexec agent installed:

https://www.qubes-os.org/doc/salt/#configuring-a-vms-system-from-dom0

I believe qubes-mgmt-salt packages will let a user-controlled management
VM use the AdminAPI through Salt. But I'm not sure whether the AdminAPI
is mature enough for that to work fully, yet. Folks on this list have
only talked about using Salt from dom0.

> 3) I so far have managed to setup `*.sls` files for updating all 
> templates as well as dom0 (THANKS unman for the example repo posted a 
> while ago). Now I'm trying to get a defined package installed in a 
> minimal template and fail:
> 
> flatpak.sls:
> install_flatpak:
>pkg.installed:
>  - pkgs:
>   - flatpak
> 

I was able to apply this state to a clone of fedora-30-minimal like this:

# qubesctl --show-output --skip-dom0 \
# --target=fedora-30-minimal-flatpak state.sls flatpak

Try getting the state to work by itself before using it in a top file.
What do you get when you try that command?

Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/470854bd-c9d0-6568-8607-8afb3bc839e5%40dugga.net.

Re: [qubes-users] "Root File out of memory warning"?

[V C]

Thanks Awokd...

I ran the commands, the changes were very small but a reduction did occur. 
The pop-up did come from the top right near the disk monitor widget. My 
"Total disc usage" states it is only at 31%...

It seems to have settled down as my new templates are finalized and old 
ones deleted...I'll grab a screen shot with more details if it happens 
again.

As always...thank 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cf1db89c-07dd-44c8-8467-e08fb993b77c%40googlegroups.com.

[qubes-users] "Root File out of memory warning"?

[V C]

Sorry for the noob question but I am getting a pop-up warning that my "Root 
File is almost out of memory"? Its kinda scary...

The error pops up more regularly now...is there any maintenance I can do? I 
have had this set up for over a year, working well...not sure the reason, 
possibly:

The way I am deleting old templates (I recently upgraded whonix and made a 
few clones, deleted a few, etc)
I haven't added to many files or photos but I have added. I am not sure of 
the exact language in the pop-up but it stated "Root", "Low-memory" and 
"File"

Any guidance would be appreciated...

Thanks,
VC

-- 
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/3d614c33-1a3f-41c0-bbdf-f39d8c5041f4%40googlegroups.com.

Re: [qubes-users] Using Salt to update TemplateVMs

[Brian C. Duggan]

On 7/18/19 10:40 AM, unman wrote:
> I cant post my files, but I've put up an example which shows how to
> create a qube for building Qubes.
> Here: - https://github.com/unman/notes/tree/master/config/build
> 
> There are some notes I used in training which are a very basic
> hands on intro to salt in Qubes:
> https://github.com/unman/notes/tree/master/salt
> 
> In the build example,you'll see:
> 1. Create.sls - Create a new qube: installing fedora-30-minimal if not already
> there, cloning to new template, using new template to create qube,
> configure the new qube, and configure dom0.
> 2. install.sls - installs required software in template.
> 3. config.sls - Configures new qube as needed.
> 
> I've broken this down to make it as clear as possible, and kept it
> simple.
> You could run each section like:
> qubesctl state.sls build.create
> qubesctl --skip-dom0 --targets=template-builder state.sls build.install
> qubesctl --skip-dom0 --targets=builder state.sls build.config
> 
> Of course, you can do everything here using scripting. But for some
> things, (like targeting packages and configuration at distro and version),
> salt is somewhat easier.
> 
> unman
> 

Thanks for these great resources, unman.

I would like to synchronize Salt formulas or entire Salt configurations
between Qubes machines.

What does that process look like? Should users edit and sign Salt
configurations in dom0? Where should users keep those configurations
under version control? How should they import them in to another dom0
and verify their integrity?

In an earlier thread on the topic, Marek mentioned that he synchronizes
Salt configurations by transferring signed tarballs. But it's unclear to
me where those tarballs are created and signed.

Brian

-- 
Brian C. Duggan
he/him/his


-- 
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/f147edf6-ed9d-a0cd-4195-cf313506c31b%40dugga.net.

Re: [qubes-users] Using Salt to update TemplateVMs

[Brian C. Duggan]

On 7/18/19 10:40 AM, unman wrote:
> I cant post my files, but I've put up an example which shows how to
> create a qube for building Qubes.
> Here: - https://github.com/unman/notes/tree/master/config/build
> 
> There are some notes I used in training which are a very basic
> hands on intro to salt in Qubes:
> https://github.com/unman/notes/tree/master/salt
> 
> In the build example,you'll see:
> 1. Create.sls - Create a new qube: installing fedora-30-minimal if not already
> there, cloning to new template, using new template to create qube,
> configure the new qube, and configure dom0.
> 2. install.sls - installs required software in template.
> 3. config.sls - Configures new qube as needed.
> 
> I've broken this down to make it as clear as possible, and kept it
> simple.
> You could run each section like:
> qubesctl state.sls build.create
> qubesctl --skip-dom0 --targets=template-builder state.sls build.install
> qubesctl --skip-dom0 --targets=builder state.sls build.config
> 
> Of course, you can do everything here using scripting. But for some
> things, (like targeting packages and configuration at distro and version),
> salt is somewhat easier.
> 
> unman
> 

Thanks for these great resources, unman. Wish I had known about them when I got 
started.

Where do you edit the salt files and how do you keep them under version 
control? Earlier, Marek said he synchronized his configuration using
signed tarballs, manually:

https://groups.google.com/d/msg/qubes-users/PtzhBZ8pT4w/8hyG1KWiCAAJ

But it's unclear to me whether he edits, signs, and tars in dom0 and transfers 
those *out* of dom0, or does those things in a VM and transfers
them *in* to dom0.

I ask because it's obviously much more convenient to edit, sign, and version 
control those files in a VM with the latest editors, gnupg, and
git. But copying data in to dom0 is generally undesirable and slows salt config 
iteration.

Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/29603147-9e53-fbb2-7740-f260ee0a7272%40dugga.net.

Re: [qubes-users] Whonix 14 to whonix 15 upgrade: Protonmail Bridge (gnome-keyring or pass nneded?) issues

[V C]

Most excellent...worked like a charm.

If anybody is doing something similar, here were my steps:


   1. Download the latest Protonmail Debian bridge (1.2.2-1 at the time of 
   this post) in a DispVM
   2. Move to dedicated template
   3. Install Protonmail bridge in template (Commands: sudo apt-get install 
   "then drag and drop the downloaded file into the terminal")
   4. Install Gnome-keyring in template (Commands: sudo apt install 
   gnome-keyring)
   5. Close dedicated template
   6. Create new AppVM with dedicated template containing Gnome-keyring and 
   Protonmail Bridge
   7. Launch new Appvm (provide password for keyring and configure 
   Thunderbird)

Thanks Awokd...good stuff!

VC

-- 
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/8bb29669-4968-4655-89f5-3e739770dd6d%40googlegroups.com.

[qubes-users] Whonix 14 to whonix 15 upgrade: Protonmail Bridge (gnome-keyring or pass nneded?) issues

[V C]

Hey all...thank you again for making and supporting an awesome OS! Thank 
you Qubes...

Just upgraded to Whonix 15, using these instructions: 
https://www.whonix.org/wiki/Qubes/Install

...seemed to go smooth. A couple of notes and a question:

1) Adjust Whonix Version Number

In dom0.

Open file whonix.jinja with root rights. [3]

sudo nano /srv/formulas/base/virtual-machines-formula/qvm/whonix.jinja

Change 14 to 15.

Save.

*Please report if this step was necessary or unnecessary for you! *

**I didn't have to do this step! It appeared already set to "15"


2) I had changed the name of sys-firewall and sys-net, however when I 
upgraded to Whonix 15, it seemed to add these Appvms during the upgrade? I 
kept my old sys-firewall and sys-net. Not sure this was expected but didn't 
seem to be an issue.


Question:
I suspect this is something new with Whonix-15 or maybe something else. I 
am trying to set up Protonmail bridge in my new Whonix-15 set up(used in 
conjunction with Thunderbird) but it appears as if a "key-ring" is missing? 
I had this working in Whonix-14 by downloading and installing the bridge 
into a dedicated template, however when I try to do this in Whonix-15 I 
notice during the Appvm set up that I am NOT asked to create a "Key-ring", 
I also get an error in the "Protonmail bridge" that states: "ProtonMail 
Bridge is not able to detect s supported password manager (pass, 
gnome-keyring). Please install and setup supported password manager and 
restart the application".

Was this removed from Whonix-15? Is it possible to add "pass" or 
"gnome-keyring" into Whonix-15?

I consider myself still very basic in terms of a Qubes user so any specific 
instructions and commands to enter would be greatly appreciated.

Thank you again...
VC

-- 
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/31506297-a3e1-4625-929f-134a6bb3c065%40googlegroups.com.

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

[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

[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

[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] Re: Receive-only email VM

[V C]

Couldn't you just use a dedicated VM and thunderbird, don't set up outbound 
in thunderbird?

On Tuesday, August 6, 2019 at 1:11:32 AM UTC-5, alex@gmail.com wrote:
>
> Some time ago there was a post on reddit (
> https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/) that 
> described setting up an offline mail vm. Just kill the "send" part there 
> and you'll get a mail black hole that receivs but never sends. Seems like 
> this is more or less what you want.
>
> On Tuesday, August 6, 2019 at 5:06:54 AM UTC+3, redd...@vfemail.net wrote:
>>
>> In Qubes, is it possible to set up a VM that can receive email, but not 
>> send information out, via email or otherwise?
>>
>> The motivation is: Many online accounts rely on an email address to reset 
>> passwords. However, the VM that handles inbound emails, processes a lot of 
>> untrusted input. If the VM gets compromised by an attacker, the attacker 
>> can then send password reset emails and read them. So to defend against 
>> this, I want to prevent the compromised VM from communicating out the 
>> contents of these password reset emails.
>>
>> Specifically:
>> 1. Assume the VM is compromised (can't rely on in-VM enforcement 
>> mechanisms).
>> 2. Assume the email provider is not compromised
>>
>> To further illustrate the problem, here are example setups and why they 
>> don't work:
>>
>> Setup 1: Use qubes firewall to restrict to the email provider's server 
>> and IMAP port. Block UDP requests using qvm-firewall.
>> Why it doesn't work: Attacker can create an account on the same email 
>> provider and connect to their account (the firewall rules will not prevent 
>> this). They can then sync emails containing any data, to their account.
>>
>> Setup 2: Like Setup 1, but use POP3.
>> Why it doesn't work: Attacker creates account at provider, transmits data 
>> via POP3 delete operations.
>>
>> Does anyone have a email setup with this inbound-only property, ideally 
>> that does not require running their own email server?
>>
>> Thank you.
>>
>>
>> -
>> This free account was provided by VFEmail.net - report spam to 
>> ab...@vfemail.net
>>  
>> *ONLY AT VFEmail!* - Use our *Metadata Mitigator*™ to keep your email 
>> out of the NSA's hands! 
>> $24.95 ONETIME Lifetime accounts with Privacy Features!
>> No Bandwidth Quotas!   15GB disk space! 
>> Commercial and Bulk Mail Options! 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9973f5d0-72a8-494f-bb6b-65124b247392%40googlegroups.com.

[qubes-users] Re: Runing qubes on macbook air (11 ince) mid 2012

[V C]

Never seen any body do it...would be cool to see!

On Saturday, August 3, 2019 at 1:20:00 PM UTC-5, 27casa...@gmail.com wrote:
>
> will it work to run qubes on this macbook?
>
> After all it has a i5 processor 4 gigs of ram.
>
> In my opinion this is by far the best ultrabook around in this price range.
>
> Would be grate if some one could tell me.
>
> Thanks for youre time and support 
>
>

-- 
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/ff0b99ee-5b2d-4a31-977f-5dcbf8150a0b%40googlegroups.com.

Re: [qubes-users] Is there a Step-by-step?

[V C]

I am a layman that gets Qubes to work...the only thing different I do 
different then awokd, is I use a Mac and terminal to create a bootable 
thumb with .iso. Tons of articles and tutorials...likely not as secure. 
Default to awokd he/she is smarter...

Other tips:
1) I had to play with my bios to install (F1 and ctrl/shift to enter?)
2) Get a Lenovo or well documented , compatible laptop. Start with that 
then upgrade if you can/want...Lenovo T450 and 420 has worked for me.

Qubes is the only way to go for me...thanks Qubes devs and others! Don't 
give up...

On Tuesday, August 6, 2019 at 1:35:09 AM UTC-5, awokd wrote:
>
> Ryan Michael: 
> > 
> > More details below, but they're irrelevant to my question: is there a 
> > clear, step-by-step how-to guide for installing qubes? Like, without all 
> > the jargon and knowledge.. assumptions, I guess? If so, could you please 
> > link me or help me find it?  I'm struggling so much (see below). If one 
> > doesn't exist, I really think one is crucial to qubes being accessible. 
> > Despite my research and determination, i'm about to give up, aha. 
>
> https://www.qubes-os.org/doc/installation-guide/ is probably the closest 
> there is. I gently suggest considering learning a bit of GNU/Linux 
> first. I went from Windows 7 to a year or two on Debian desktop before 
> Qubes, but you could also set up an Ubuntu VM in Virtualbox on Windows 
> to get some practice with it. 
>
> If you want to dive in to Qubes, the abbreviated steps are 
> -do a full system backup 
> -download ISO 
> -copy to USB drive per Rufus screenshot in above link 
> -boot from USB drive 
> -follow prompts, noting you can erase your entire hard drive so be sure 
> to do a full backup first 
>

-- 
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/73b32ddc-f33e-4012-ba92-aade50f78dcb%40googlegroups.com.

[qubes-users] Re: qubes updater broken? just had to re-install qubes

[V C]

Thanks for the note...I saw this just before my recent Dom0 and other updates. 
I too had similar symptoms including: " I noticed that several qubes didn't 
shutdown quite right, click on the right Q button, they were still there, but 
showed zero memory usage."

I did a back up before shutting down...very good advice and reminder!

Everything booted up fine for me...little sketchy for a while but I had no 
problem with the update.

-- 
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/ac4b9403-1993-494c-9df6-3ffe30c5e6a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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?

[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?

[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"

[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

[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] Salt orchestration

[Brian C. Duggan]

On 1/11/19 7:41 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 07, 2019 at 12:20:31PM -0500, Brian C. Duggan wrote:
>> On 1/4/19 3:08 PM, Brian C. Duggan wrote:
>>> 2. Salt should ensure that service VMs are running before Salt applies
>>> states to their client VMs. For example, I have a service VM that
>>> exports gpg-agent's SSH socket through Qrexec. This VM needs to be
>>> running so that the client VM can clone git repos using keys on the
>>> serivce VM.
>>>
> 
>> I did some more testing. Of course, Qubes starts halted VMs when another
>> VM makes a Qrexec RPC call to it. The calling process on the client VM
>> will block until the service VM starts and the RPC call returns. So this
>> isn't really a valid use case for orchestration.
> 
>> At first, I thought the SSH authentication attempts failed because the
>> service VM wasn't started yet. After more testing, I can see that the
>> systemd socket service just doesn't work at the stage during initial
>> boot that Salt runs. The socket file exists at this stage, though. SSH
>> authentication succeeds during subsequent Salt runs after the VM is booted.
> 
>> But I've also noticed that sometimes a new app VM's grain ID is still
>> the template's ID when Salt processes templates. 
> 
> That shouldn't happen in theory... Can you give more details, especially
> which templates, and qubes* packages version?
> 

Sure, I was able to reproduce it and I created an issue for it with the
templates and qubes* packages versions:

https://github.com/QubesOS/qubes-issues/issues/4709

Briefly, app VMs get their templates' grains['id'] for about five
minutes after applying a state to the template and shutting down the
template.

> Additionally, even if grain['id'] doesn't match, target VM will get
> access to other's VM pillar data - it's enforced when copying pillar
> data out of dom0.
> 

Hm, my target VMs only get access to pillar data that is applied to them
through the top file or through templating. They don't see other VM's
pillar data. Did I understand you right?

> 
>> This can be a problem
>> when both dom0 and app VMs need the same pillar data:
> 
>> pillar/app/client-vm-1.sls:
>> app:
>>   client-vm-1:
>> server-name: server-vm-1
> 
>> pillar/app/client-vm-2.sls:
>> app:
>>   client-vm-2:
>> server-name: server-vm-1
> 
>> pillar/top.sls:
>> base:
>>   dom0,client-vm-1:
>> - match: list
>> - app.client-vm-1
>>   dom0,client-vm-2:
>> - match: list
>> - app.client-vm-2
> 
>> dom0 needs the combined app data to set RPC policies between the clients
>> and their servers. The clients need their own data to configure which
>> service VM to send their RPC to. It's convenient for clients to find it
>> through pillar['app'][grains['id']]. Maybe there's a better way of
>> constructing this pillar data?
> 
> The fact that you'll see only the right pillar data, regardless of
> grains['id'] may help you. You can iterate over 'app' dict and use
> whatever you find there, regardless of the first key name level.
> It will complicate your configuration, but until proper solution is
> found, it should work.
> 

That's what I ended up doing, I think. In my formula I select the
first key in the app dict in the Jinja template. Since there's only one
key available to each client VM, it doesn't matter that the grains['id']
doesn't match the key name.

>> Is there a way to delay Salt execution on VMs until they are fully booted?
> 
> By default it's delayed until qrexec-agent is started, which should be
> after essential services. If you want, you may:
> 
> 1. Add a state waiting for user session and order other things after it.
> This won't help with grains and such things, as salt load them before
> considering states, but may help with some states, if are dependent on
> running X server for example. For this, add this:
> 
> /etc/qubes-rpc/qubes.WaitForSession:
> cmd.run:
> - runas: user
> 
> 2. Configure qubes.VMRootShell qrexec service in a VM (used by salt) to
> wait for user session. This will affect the whole salt call for that VM.
> But also means it will wait indefinitely if no user session is started
> at all (for example you're logged out of dom0).
> For this create /etc/qubes/rpc-config/qubes.VMRootShell in the template
> with "wait-for-session=1" inside.
> 

These are great ideas! I'll try them out.

>> 

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

[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"

[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

[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.

Re: [qubes-users] Salt orchestration

[Brian C. Duggan]

On 1/4/19 3:08 PM, Brian C. Duggan wrote:
> 2. Salt should ensure that service VMs are running before Salt applies
> states to their client VMs. For example, I have a service VM that
> exports gpg-agent's SSH socket through Qrexec. This VM needs to be
> running so that the client VM can clone git repos using keys on the
> serivce VM.
> 

I did some more testing. Of course, Qubes starts halted VMs when another
VM makes a Qrexec RPC call to it. The calling process on the client VM
will block until the service VM starts and the RPC call returns. So this
isn't really a valid use case for orchestration.

At first, I thought the SSH authentication attempts failed because the
service VM wasn't started yet. After more testing, I can see that the
systemd socket service just doesn't work at the stage during initial
boot that Salt runs. The socket file exists at this stage, though. SSH
authentication succeeds during subsequent Salt runs after the VM is booted.

But I've also noticed that sometimes a new app VM's grain ID is still
the template's ID when Salt processes templates. This can be a problem
when both dom0 and app VMs need the same pillar data:

pillar/app/client-vm-1.sls:
app:
  client-vm-1:
server-name: server-vm-1

pillar/app/client-vm-2.sls:
app:
  client-vm-2:
server-name: server-vm-1

pillar/top.sls:
base:
  dom0,client-vm-1:
- match: list
- app.client-vm-1
  dom0,client-vm-2:
- match: list
- app.client-vm-2

dom0 needs the combined app data to set RPC policies between the clients
and their servers. The clients need their own data to configure which
service VM to send their RPC to. It's convenient for clients to find it
through pillar['app'][grains['id']]. Maybe there's a better way of
constructing this pillar data?

Is there a way to delay Salt execution on VMs until they are fully booted?

For the curious, I'm using a Salt formula to set up access to gpg-agent
on a service VM from client VMs through Qrexec:

https://gitlab.com/bcduggan/qrexec-gpg-agent-formula

Thanks,
Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/d3f8ee12-8498-d0b5-4537-abc2f8e3e8ee%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Salt orchestration

[Brian C. Duggan]

Hi,

I need to orchestrate Salt states so that VMs are started, stopped and
configured in stages. I tried using the Salt Orchestrate Runner, but it
couldn't find states that I can use with 'qubesctl state.sls '
and 'qubesctl state.highstate'.

I have two use cases:

1. Salt should start, configure, and halt template VMs before it starts
app VMs that use them. For example, the Salt GPG state requires the
python-gnupg package. This package needs to be installed in the template
VM so that the Salt GPG state can import keys in the app VM.

The current sequence of my states appears to let template VMs halt
before Salt starts app VMs. But I would like to strictly enforce this
ordering between admin VM states and regular VM states.

2. Salt should ensure that service VMs are running before Salt applies
states to their client VMs. For example, I have a service VM that
exports gpg-agent's SSH socket through Qrexec. This VM needs to be
running so that the client VM can clone git repos using keys on the
serivce VM.

This second case is more difficult to enforce without orchestration.

I can approximate this functionality with a series of commands:

qubesctl --target template-vm state.highstate
qvm-shutdown template-vm
qubesctl --target service-vm state.highstate
qvm-start service-vm
qubesctl --target client-vm state.highstate

But I would like to be able to describe this orchestration in Salt.

Does the Salt Orchestrate Runner work on Qubes? If not, is there a way
to orchestrate Salt on Qubes?

Thanks,
Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/53a38760-fd3e-31f8-d06b-b821a809fc23%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

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

[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.

Re: [qubes-users] Correct place for salt-ssh configuration

[Brian C. Duggan]

On 12/17/18 8:08 PM, unman wrote:
> On Mon, Dec 17, 2018 at 07:18:14PM -0500, Brian C. Duggan wrote:
>> On 12/17/18 6:27 PM, unman wrote:
>>> From this comment I dont think it can be done (as yet) through salt-ssh:
>>> https://github.com/saltstack/salt/issues/42148#issuecomment-441955777
>>>
>>
>> I see. Thanks for finding that, unman.
> 
> There are limitations to salt-ssh (including targeting) which I have
> been exploring
> 

There are several, huh? Before I asked about this, I ran in to this:

https://github.com/saltstack-formulas/salt-formula/issues/140

I followed the suggestion in that thread and created
/root/.salt/Saltfile with the extra_filerefs setting on the DispVM. That
worked around this issue with salt-ssh.

>>
>>> Also, remember that Qubes uses salt as a masterless minion, so that
>>> configuration in salt/master wont be read.
>>>
>>
>> I think I understand, now. So, on dom0, should configurations go in
>> salt/minion? Will those settings only apply to dom0?
> 
> I believe this is true.
>

Nod.

>>
>> Will salt-ssh on the management DispVM read salt/master on the DispVM?
>>
> 
> /srv on the DispVM is copied from /srv in dom0.
> /etc/salt/master on the DispVM is copied from /srv/master in dom0.
> 

Great, this helps immensely.

> It would help if I understood what configuration you want to apply.
> 

Well, now that my original use case - using the latest module.run format
- is moot, I don't really have one :) I was asking for my own clarity
and future reference. Thanks again, unman, this really clears things up.

Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/4b04c2ba-81a6-f0db-bc5f-e4b21ac22fbd%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Correct place for salt-ssh configuration

[Brian C. Duggan]

On 12/17/18 6:27 PM, unman wrote:
> From this comment I dont think it can be done (as yet) through salt-ssh:
> https://github.com/saltstack/salt/issues/42148#issuecomment-441955777
> 

I see. Thanks for finding that, unman.

> Also, remember that Qubes uses salt as a masterless minion, so that
> configuration in salt/master wont be read.
> 

I think I understand, now. So, on dom0, should configurations go in
salt/minion? Will those settings only apply to dom0?

Will salt-ssh on the management DispVM read salt/master on the DispVM?

-- 
Brian C. Duggan
he/him/his

-- 
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/efd8af38-6416-dd79-d6d5-eb0e9b6a9aed%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Updated HCL report - Dell Precision 5520

[Brian C. Duggan]

On 12/17/18 11:43 AM, smvice...@invisson.com wrote:
> So I have a Precision 5530, and after some similar tweaks to those
> described here, I managed to install Qubes 4.0. Everything seem to be
> working perfectly fine (Including Wi-Fi) except for the Ethernet
> adapter that I need to connect to the USB-C (Thunderbolt) port. The
> adapter is detected and I can use other connectors (DP, USBs) but the
> ethernet adapter is not listed. I've tried assigning devices,
> connecting it to sys-net, etc but no luck...
> 
> Asking this here because in the Precision 5520 you also need a
> similar adapter if you want to use Ethernet... so hopefully you have
> figured it out already?
> 
> Thank you in advance.
> 

I have a Precision 5520 and the USB-C Ethernet adapter that came with
it. I'm running Qubes R4.0.

I've been able to use the adapter once per boot before I unplug it. If I
unplug it and plug it back in, then it doesn't show up as an Ethernet
device in the NetVM, and I have to reboot to use it again.

If I boot the laptop with the adapter plugged in, dom0 sees four PCI
bridge devices and one USB 3.1 controller associated with the adapter:

[user@dom0 ~]$ lspci
...
05:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
06:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
06:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
06:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
3d:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Controller
[Alpine Ridge]

I can create a NetVM and assign the last PCI device listed here to it.
NetworkManager recognizes the USB device as an Ethernet device in the
NetVM.  

However, if I plug the adapter in after I boot, then I have to rescan
the PCI bus to see those devices:

[root@dom0 ~]# echo 1 > /sys/bus/pci/rescan

Then, lspci will show the USB 3.1 controller. This works the first time
I plug the adapter in after boot. But the NetVM still won't see an
Ethernet adapter if I've already unplugged it.

Adding and removing a PCI device creates other issues. If I unplug the
adapter, the NetVM that I attached the device to will hang on shutdown.
And the same VM will fail to boot if the adapter isn't plugged in:

[user@dom0 ~]$ qvm-start sys-dongle
  Logical Volume "vm-sys-dongle-root-snap" already exists in volume
group "qubes_dom0"

I haven't investigated further since I use WiFi almost exclusively on
that laptop. But maybe you'll have better luck with plugging and
unplugging the adapter on the 5530.

Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/0d8541a8-e1a4-2a4c-4853-b31f6144dbc1%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Correct place for salt-ssh configuration

[Brian C. Duggan]

Hi,

What's the correct place to configure salt-ssh? The SaltStack
documentation says salt-ssh configuration goes in /etc/salt/master. I
tried adding configuration for salt-ssh to /etc/salt/master on dom0 and
also on the template VM for the default disposable VM. But I didn't see
any effect from the configuration.

I'm using Qubes R4.0. I'm not using the packages in the testing repo
that provide a dedicated management DispVM and template.

My use case is that I want to use the new format (as of Salt 2017.7.0)
for running execution modules in state files:

https://docs.saltstack.com/en/latest/topics/releases/2017.7.0.html#state-module-changes

salt-call on dom0 is 2017.7.1
salt-ssh on the default DispVM template is 2018.3.2

The legacy format for module.run works fine. Using the new format
requires setting this on minions:

```
use_superseded:
  - module.run
```

In order to pass that setting to minions, I added this to
/etc/salt/master on both dom0 and on the default DispVM template:

```
ssh_minion_opts:
  use_superseded:
- module.run
```

But the comment in the state output said that the module was not
available when I used the new format.

Is that right way to use `use_superseded` through salt-ssh?

Where should salt-ssh configurations go in Qubes R4.0?

Thanks!
Brian

-- 
Brian C. Duggan
he/him/his

-- 
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/28d9fbe8-d47a-10ad-3c1c-3f1862617490%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

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

[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

[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] UnicodeDecodeError during Qubes 4.0 installation

[C.]

Hello!

I have a strange problem when trying to install Qubes 4.0 through USB. I get to 
the first installer screen (language selection), but then I get an "undefined 
error" and I can not move forward with the installation. The error:

UnicodeDecodeError: 'utf-8' codec can not decode byte 0xed in position 5: 
invalid continuation byte

I have tried to install in 2 different USB, always with dd and as indicated in 
the installation guide, but without luck:

sudo dd if=Qubes-R4.0-x86_64.iso of=/dev/disk3 bs=1048576 && sync

Looking for information I see that the error is from Python3, but I do not know 
how to fix it in the installer or in the USB itself. If anyone has any 
suggestions or can indicate the correct path I would be more than grateful.

Many thanks!

C.

-- 
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/be3aa550-ea35-451a-9731-911e1bba68b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] compatibility question; qubes 4.0 on intel i3-4360T ?

[C R]

Also, assuming that Qubes 4.0 is not feasible on my system, what would the
second-best recommendation be?  Linux on top of Xen?

On Wed, Sep 5, 2018, 22:04  wrote:

> Hello all,
>
> I am trying to get Qubes 4.0 running on an Intel i3-4360T chipset with
> ASROCK E3C226D2I motherboard.  The architecture apparently supports VT-x
> according to the tests I did in accordance with the Qubes docs, so I hoped
> I was set.
>
> However, Qubes' installer tells me that my system apparently lacks
> IOMMU/VT-d/AMD-VI, and Interrupt Remapping.  I was running the installer
> from a 8GB USB stick formatted with dd in Linux.
>
> Is that the end of my Qubes journey right there (short of getting new
> hardware), or are there BIOS settings I could check, etc?  Advice would be
> greatly appreciated.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/nSrk6LGc7PM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/c5da5441-f803-4d5b-a445-d17a24d84e41%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[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 dom

[qubes-users] HCL - Alienware 17 R3

[C J du Preez]

Networking works well, so does video / audio streaming. I have not
tested sleep functionality.

-- 
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/00b09c67-28e2-046c-4384-be2e9c92a46c%40cjdpenterprises.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Alienware-Alienware_17_R3-20180507-171630.yml
Description: application/yaml

[qubes-users] Re: Ledger Nano S

[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?

[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)

[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 
c

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

[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] ERROR

[c . rrapaj19]

how can i fix this 
ERROR:invalid argument : could not find capabilities for arch=x86_64

-- 
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/9a34ea8c-c729-4f2b-8da5-cbbb0f4c0cdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Macbook Pro - Broadcom WLAN adapter BCM43602 causing freezing under Qubes OS 4.0 rc5

[c...]

пятница, 16 марта 2018 г., 5:19:41 UTC+3 пользователь Greg написал:
> Hi,
> 
> Please assist if possible - I'm trying to get the Broadcom WLAN adapter 
> BCM43602 working on my Macbook Pro under Qubes OS 4.0 rc5. 
> 
> "03:00.0 Network controller: Broadcom Limited BCM43602 802.11ac Wireless LAN 
> SoC (rev 01)"
> 
> I've managed to install Qubes OS successfully (during the second part of 
> setup, just before sys-net creation I switched to a console and started a 
> short bash script that just loops over and over trying to remove the BCM43602 
> from sys-net, then I went back and completed the setup. The script 
> successfully removed the BCM43602 from sys-net before sys-net was started by 
> the setup wizard, meaning that I managed to avoid the system freeze that 
> would have otherwise occurred during setup).
>  
> Now I'm trying to actually get the BCM43602 working, i.e. attach the adapter 
> to a qube (e.g. sys-net, standalone hvm or anything at all without freezing). 
> However it seems that the system freezes the moment I start the qube it is 
> attached to and it doesn't matter which kernel the associated qube is 
> actually running (e.g. it freezes even when I attach it to a qube that is a 
> fresh Ubuntu 17.10 install with hvm and no kernel seleced). I've tried 
> different combinations of permissive mode and no-strict-reset and pv/hvm but 
> every combination results in freezing. 
> 
> I'm not sure how to proceed? Does anyone have the BCM43602 working under 4.0 
> rc5?
> 
> Any pointers would be appreciated.
> 
> Thanks,
> Greg

Try to start sys-net without attached devices, after that attach adapter 
directly:
sudo xl pci-attach sys-net '03:00.0,permissive=1'
That helped for me.
qvm-pci for some reason freezes my macbook

cheers

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/29ecf6b2-4d7a-44f1-aafc-16b7e475f1ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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

[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

[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)

[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] Re: templates update fail over sys-usb (but work using sys-net, on Qubes 4.x rc4)

[Dave C]

On Saturday, February 3, 2018 at 12:52:21 PM UTC-8, Dave C wrote:
> On Saturday, February 3, 2018 at 12:34:18 PM UTC-8, Yuraeitha wrote:
> > On Saturday, February 3, 2018 at 9:18:45 PM UTC+1, Dave C wrote:
> > > 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 made your sys-firewall handle USB devices? 
> 
> No, I configured sys-firewall to use sys-usb for networking, instead of the 
> default setting sys-net. Same as you describe, I think.
> 
> BTW, the problem seems have gone away after I clicked the OK button in the 
> "Qubes Global Settings" dialog.

Actually, shortly after, a similar problem appeared.  When sys-firewall uses 
sys-usb, `dnf install ...` fails later than I reported earlier.  It errors out 
this way:

```
Transaction Summary

Install  12 Packages

Total download size: 3.9 M
Installed size: 7.1 M
Is this ok [y/N]: y
Downloading Packages:

The downloaded packages were saved in cache until the next successful 
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  Curl error (56): Failure when receiving data from the peer for 
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26&arch=x86_64
 [Received HTTP code 500 from proxy after CONNECT]
[user@f26-devel ~]$ sudo dnf install openssl-devel
Last metadata expiration check: -1 day, 17:20:05 ago on Sat Feb  3 20:14:15 
2018.
```

But again, if I configure sys-firewall to use sys-net, and use wifi instead of 
usb tether, `dnf install ...` succeeds.

Odd! and still a mystery.

-- 
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/7bb5b85c-5bf5-4b9b-9548-16310cb5beb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Dave C]

On Saturday, February 3, 2018 at 12:34:18 PM UTC-8, Yuraeitha wrote:
> On Saturday, February 3, 2018 at 9:18:45 PM UTC+1, Dave C wrote:
> > 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 made your sys-firewall handle USB devices? 

No, I configured sys-firewall to use sys-usb for networking, instead of the 
default setting sys-net. Same as you describe, I think.

BTW, the problem seems have gone away after I clicked the OK button in the 
"Qubes Global Settings" dialog.

I'm not sure the problem, but it behaves as if sys-net is used to update 
templates, even while Qubes Global Settings *shows* sys-firewall.  But clicking 
OK on that dialog seems to have made the setting actually be sys-firewall.

As I said I'm not sure, but if that's the case it is a minor bug in the 4.x rc4.


-- 
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/b426e6bc-4677-4da3-91ef-065d97823648%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)

[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)

[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"

[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

[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

[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

[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)

[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)

[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

[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.

Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[genevieve . c . gauthier]

On Wed, 2017-11-29 at 15:59 +, Unman wrote:
> In the Fedora documentation there ARE methods described for getting
> bug
> reports out of the install process, but they require active
> intervention
> from the user (copy to another drive or scp across network). There's
> no
> suggestion that these reports would be automatically submitted.
> 
> I've had a quick look through the code and i dont see any mechanism
> for
> passing on bug reports - but it was a very quick look.

Interesting & very good to know this but that would have surprise me a
lot from a Qubes OS installation. Have you learned if it is specific to
Qubes 4.0 rc3 (perhaps the installation part has been there for a long
time before this release) ?

3-4 questions remains for me.  If you can learn those answer in the
future, I believe this issue would have been truly investigated for me.

With an "active" intervention from the user (or if I had connected to
the internet and submitted my report from my computer to the computer
receiving those reports) 

1.1 : Does my passphrase would have been transmitted ?  YES/NO ?
1.2 encrypted along the way ? YES/NO ?
2.1 : If YES 1.1, where/who does the passphrase would have been
transmitted/ transmitted to
2.2 : Who would have had access to this information ?


I am not looking for an immediate answer. However, I am still curious
about all this.  Such a strange 'Bug Report' to see it like this..
Seems complicated to use those information to comprise the whole system
via dom0 (that's good)  

P-S & It means, I can continue my own little project of giving Qubes
usb stick to people around me so they can access their bank account
online without having to worry about being on their "vulnerable" (or
even worst compromised win10 OS) windows OS.  Futhermore, I feel you
have made a great job at Qubes OS so it would be simple for me to teach
people how to open a disposable-vm for this purpose and this purpose
only (without really having to learn about Dom0 or about this
fascinating architecture if they are not interessed).  Love the Qubes
"color code" BTW.  It will make my life very easy when I'll explain to
people which color they must see on their browser to feel more secure
without having to teach to any grandparents about VM, Xen Hypervisor
and Dom0 interaction lol)  Just using a linux distro would be superior
I think.. but Qubes and a disposable-vm seems perfect to be just to "go
to the bank online" if you are old and know little about computers. The
cost of this is idea is minimal too (really just having a 32gb usb
media lying around).  I do not think those would have been targeted
Qubes user.  Qubes does not even need any modification for this
project.  I will be able to teach to many people in less than <30
minutes I think with one demonstration during the holidays.  Better
safe than sorry and with no money ! Agree ? :-)

Take Care & Thank 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/1511989413.14418.54.camel%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[genevieve . c . gauthier]

Sorry but I almost fainted ! (I even took a picture ! I could not believe this 
MEGA-HUGE security flaw right in front of my eyes ) 

An installation error prompt this screen : 

An unknown error has occurred
This program has encountered an unknown error. You may report the bug below or 
quit the program.  (2 buttons:1st 'Report Bug' 2nd 'Quit')

More info ...
The output below may help determine the cause of the error :
[...]
#System timezone
timezone America/New_York --isUtc
#System bootloader configuration
bootloader --location=mbr
autopart --encrypted --passphrase=X!! 
type=lvm
#Root password
rootpw --lock
#Partition clearing information
[...]

//
WHAT IS THIS ! I could SEE with my own little EYES my OWN "SECURE" PASSPHRASE 
as a STRING!!! (translated to you as XXX!) 

Do I need to repeat this?? (sorry but I even took the picture with my finger in 
front of it so I would not to store my OWN SECURE PASSPHRASE in a picture!!!

I am a dummy but not that dumb... what is this ? Is it a mistake ? Is it 
supposed to be Qubes OS Untrustable OS or ?? ... Sorry, you are supposed to be 
good and security expert but you are asking me (THE dumb USER) to report MY OWN 
PASSPHRASE AS A STRING to help you??   (Such any easy way to get access to my 
drive! & perhaps use my passphrase to guess other passwords as well...)

I believe, without being on the "receiving" side of this report bug 
process(would need this to be 100% sure) that your OWN reporting bug system is 
giving you Qubes Users PASSPHRASE as (clear)STRING in the report ... 

Your Report bug => The needed stuff &&& MY DRIVE SECURE PASSPHRASE so everyone 
can see it!?

This does not look very "secure" too me ... (sorry but lmao)

P-S there is also 'Debug' may take you to tty1 & Button "Debug" (lower right 
corner of my screen)

Have a nice day 
N.B. I will not report this bug "computer" to "computer" as my own Qubes OS 
drive would not be encrypted at all if everyone at "Qubes OS" has MY own drive 
password to (de)crypt it.  I am very glad your are an opensource software ... 
If this would have been "Windows" I might not have fainted but I might have an 
heart attack after reviewing this truly UNSECURED "Report" 

 

-- 
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/d18652f0-d300-4b92-99c0-a0ecedd93d11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes for "dummies"

[genevieve . c . gauthier]

Hi, I did not know about your OS.  I think this project is awesome.  I do not 
have the computer knowledge some of you specialist of your field have.  I am 
writing this message to try to contribute in my own way.

First, I have also watched "Youtube :Golem and Friends: Data, Security, Scaling 
and More..." (very interesting too and I am learning more...)

The first part the presenter (I understand she is a major contributor to Qubes) 
says "I would not recommended using a windows OS - internet browsing" this 
person as superior knowledge... 

My point of view is this : This lady (and probably all of you even reading my 
post) are (would be) one of the most secure windows user(s) on this planet ! 

Regarding to your future project, I am writing this to also tell you about my 
concerns that people who would NEED you the most, logically, would be the user 
with LESSER/ALMOST NO computer skills ...!  

I have a MintLinux server at home (force to use this because of my limited 
knowledge and the "obnoxious" graphic card chipset of the old laptop that I 
transformed for my project.  (Home network : I have windows clients (for 
gamers), macOS client & now a new fedora-based client that I wanted to be a 
Qubes client but ...(2nd topic)) So, if I were to install Qubes on many system, 
my first choice would be to install it on my friends and family members who do 
not have a clue what goes on at anything lower "than runlevel 5" (to be more 
accurate they know what they are seeing and that's almost it and nothing about 
what goes on "beyond the scene" as far as computers go)

2nd topic : My experience 48h experience with Qubes 3 + another 48h on Qubes 
4.0 rc2 on my personal laptop. First, I notice the Qubes manager went away. Not 
a problem because I was able to master the command-line qvm-backup easily 
(without knowing everything)) (but using a terminal is now consider "above 
average" skills by definition)  In fact, I had chosen Qubes for this laptop 
(the hardware had the capacity to handle the OS as far as virtualisation is 
concerned) and it seems perfect to read online and work on it. I felt my data 
(my own little projects) would be more secured.

Logic for dummies .. 
=> Logic : new laptop have touchscreen ...
=> Logic : Qubes designer chose not to support gnome => I understand it 
perfectly*.   However, considering, in the future most user will have 
touchscreen, they will want the OS/software to be able use the hardware 
capacity they paid for (I think this is logical).  The user who would need your 
work the most will not be able to add touchscreen support to xfce-based Qubes 
(if it's not included) I know that I was not able to do this myself at first. 
(is it possible?)  I loved your fedora-based system (dnf as opposed to apt-get 
is not too difficult to adapt too) Therefore I decided to switch my client to 
the new fedora workstation gnome-shell.  I do not think supporting gnome (with 
all the implication that this have about reviewing internal security/reviewing 
codes => major hrs and, perhaps, many coffees for everyone is "The Must Way to 
go" (I do not even think myself there should be any Must Way/One Way. Users 
should be as free as they can)

However, from a user (human) perspective, I needed to read about Qubes.  I 
wanted to read about your project.  I used to be a able to use my touchscreen 
to read faster... and gosh I have needed to read a lot the past for days! Now, 
I am reading your documentation on fedora (with touchscreen support) and this 
is much easier for me.  I which I could reinstall Qubes (xfce /w touchscreen 
support like my fedora 27 workstation) in 2018 :-)  At this point, I have 
switched to federa also because Qubes 4 had a nasty bug(s) involving not only 
the nm-applet but the whole sys-firewall vm /sys-net vm... Dummy perspective : 
One time, the nm-applet went away I could not start the sys-firewall either 
(&sys-net , Error starting VM: Cannot exeCute qrexec-daemon! in terminal :S ) 
Then after rebooting two times, my sys-net & sys-firewall were "fine" ..  Those 
problems are completely beyond my current skills .. I switched to fedora 27 but 
I will continue to closely follow your project/Qubes OS on facebook and read 
more about this project.

If this help someone ... I think you are doing great work (users and 
developers) and please keep in mind those who would need you (your skills) the 
most are not even people like myself but users far more vulnerable (even less 
knowledge)... I understand this from my own field that sometime people with 
superior skills take for granted (as do I) some of "our" knowledge and tend to 
forget "obvious" is not the same "obvious" for all users.  

P-S I have seen Qubes 4.0 rc3 today (I stop with Qubes 4.0 rc2) it will be 
tempting for me in the future to see if you have solved those strange 
networking problems (rc2) occurring on my laptop ... Furthermore, I am thinking 
to create usb keys with Qubes for my family members for xm

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

[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

[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

[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..."

[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)

[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

[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)

[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

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

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

[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

[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] Re: trouble with Lenovo P51 (nvidia quadro m1200)

[Dave C]

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.

-- 
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/1f7f27da-5f97-4559-977e-1f4b3fffaebf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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?

[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&sa=D&sntz=1&usg=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?

[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.

[qubes-users] How to install kernel headers in debian 9?

[c...@company.com]

Hello,

I've upgraded my debian-8 template to debian-9 (stretch). Now I want to
install vmware player and it asks me where the kernel headers are located.
I could not find them in /usr/src and I also can't find them via apt-cache
search. Is there a way to install the kernel headers for Linux debian-9
4.8.12-12.pvops.qubes.x86_64?

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

[qubes-users] Lenovo T460: Troubles with intel graphics and network interfaces

[c...@company.com]

Hello,

I have Qubes 3.2 running on a Lenovo T460 and I am encountering 2 problems:

1.) I have a docking station with 2 monitors connected to it. When I put
the notebook in the dock and enable the second screen, sometimes everything
freezes a few seconds after enabling the second screen. After that I have
to reboot the whole device. I found out that when i delete
/home/username/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml, then
reboot and then turn on the second and third screen it works
sometimes...but I cant really find out why it works or fails from time to
time. I found a few tipps regarding configuration of the intel i915, but it
seems nothing really works (or maybe I am just too stupid for it) :)

2.) When Qubes goes into sleeping mode I loose my network devices in
sys-net. This means that I dont see any Ethernet or wifi card anymore in
network-manager. I have to reboot sys-net or the whole machine to see the
devices again. The only workaround I can imagine is deactivating
hibernation.


I would be really happy for any tipps how I can troubleshoot or fix this.

Thanks!

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

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

[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

[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

[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.

Re: [qubes-users] How do I get Qubes 4.0 pre-release/dev build?

[C. L. Martinez]

On Thu  1.Dec'16 at 15:19:16 +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 01, 2016 at 02:06:16PM +, C. L. Martinez wrote:
> > On Thu  1.Dec'16 at 14:50:59 +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
> > > > On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
> > > > 
> > > > > > R4 Will be fedora-23 based for dom0 right?
> > > > > 
> > > > > This is the plan right now.
> > > > > 
> > > > 
> > > > Why plans always point to old fedora release? Fedora 25 already 
> > > > available.
> > > > Why Qubes dom0 planed to be at fedora-23? (two versions delay)
> > > 
> > > To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
> > > release requires some work. And as Andrew pointed out, it isn't a
> > > problem for security. If anything at all, some hardware compatibility,
> > > but we will provide newer kernel at least.
> > > 
> > 
> > To avoid this type of situations, why not use an LTS distro (CentOS, 
> > Unbuntu ...) for dom0??
> 
> In most cases LTS distro does not solve hardware compatibility problem
> at all - you still get old drivers even if the release is still
> supported. The only difference is how long bug fixes (for this outdated
> software) are released.
> 
> So, generally it is good idea, but it will not solve this particular
> problem. This is why we have this ticket:
> https://github.com/QubesOS/qubes-issues/issues/1919
> See discussion there for details.
> 
Ok, understood ... But, IMO, CentOS (or any RHEL derived distro and RHEL) has a 
really good compatibility with old and new laptops (specially with thinkpads, 
acer aspire, etc.) and there is no problems with graphics drivers, nics, 
storage controllers, etc... I am using RHEL/CentOS/OL in all my laptops from 7 
years ago without problems (yes, all of them they was/are thinkpads T).

Anyway, we can wait to Qubes 4.0 to see how it goes ..

Many thanks for your answer Marek.

-- 
Greetings,
C. L. Martinez

-- 
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/20161201144227.GB4688%40scotland.uxdom.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How do I get Qubes 4.0 pre-release/dev build?

[C. L. Martinez]

On Thu  1.Dec'16 at 14:50:59 +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
> > On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
> > 
> > > > R4 Will be fedora-23 based for dom0 right?
> > > 
> > > This is the plan right now.
> > > 
> > 
> > Why plans always point to old fedora release? Fedora 25 already available.
> > Why Qubes dom0 planed to be at fedora-23? (two versions delay)
> 
> To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
> release requires some work. And as Andrew pointed out, it isn't a
> problem for security. If anything at all, some hardware compatibility,
> but we will provide newer kernel at least.
> 

To avoid this type of situations, why not use an LTS distro (CentOS, Unbuntu 
...) for dom0??

-- 
Greetings,
C. L. Martinez

-- 
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/20161201140616.GA4688%40scotland.uxdom.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] (is Eluktronnics a) Good choice laptop for Qubes?

[Dave C]

I'm looking to upgrade my laptop and get something suitable for Qubes 4.  A 
search for laptops with large RAM led me to Eluktronics brand.  It gets good 
ratings on amazon, but I have not seen it mentioned here.

Here is (I believe) their smallest model, and if I understand correctly it 
meets the reqs of Qubes 4:

https://www.amazon.com/dp/B01E3Q0K24/ref=psdc_13896615011_t3_B01G1JT7QG?th=1

The CPU: 
http://ark.intel.com/products/88967/Intel-Core-i7-6700HQ-Processor-6M-Cache-up-to-3_50-GHz
Qubes 4.x reqs: 
https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/

I thought it wise to ask here before ordering... Am I missing something that 
makes it not a good choice?

I've read elsewhere 
(http://www.onebigfluke.com/2016/10/alternatives-to-apple-computers.html) about 
the importance of Thunderbolt 3, which I believe the model I link to does not 
have.  But honestly I don't know the ins and outs of what hardware makes a 
laptop the best choice.  I'm looking for a lightweight laptop that offers high 
bang for buck.  And of course will work perfectly with Qubes.

Any strong opinions here about the Eluktronics brand specifically?  Or Qubes 
laptop advice in general?  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/4f081471-ec97-4c1a-8ecd-589d28d2421d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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.

[qubes-users] Any info about this presentation ?

[C. L. Martinez]

Hi all,

 Any additional info about this BlackHat's presentation?

 
https://www.blackhat.com/us-16/briefings/schedule/#xenpwn-breaking-paravirtualized-devices-4061

-- 
Greetings,
C. L. Martinez

-- 
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/20160619181904.GA21318%40beagle.bcn.sia.es.
For more options, visit https://groups.google.com/d/optout.