[qubes-users] netwrok problem

[Kevin Holden]

Hi, just installed Qubes 4.0 on an HP 8460p and it seems that networking is
not enabled.

 

When I start sys-net, and in the basic tab, try to add networking
(default(sys-firewall)) I get an error message saying ERROR: Basic tab:
Loops in network are not supported.

 

Any ideas?

 

Thanks, Kevin

-- 
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/000b01d3e29c%241850%24599988f0%24%40holden.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora 28 just released

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-05-02 07:42, ro...@mullvad.net wrote:
> Will the fedora 27 template also work on/be ported to Qubes 3.2, or
> will fedora 26 be the last supported template for that Qubes
> version? If so, I guess that means you'll have to upgrade to Qubes
> 4/4.1 if you want to use fedora templates and get security
> updates?
> 
> Kind regards, Robin
> 

Since Qubes 3.2.1 will be supported until 2019-03-28 [1], newer Fedora
templates will continue to be made available for 3.2.1.

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlrqe+YACgkQ203TvDlQ
MDAi0hAAjh0Hhpa+nnM5FNX5PBbE6En09fcoTE9h839vrh2WgcZPe5OeYNeN042n
KjBL/4VUziy03S8TfDOnk2pcTf9Hy3q9ipAeLJfHovjsy8xlP9qjE7WQiXzWnh9w
f1kzXOC08kgzZpOxH6Gs6CJz6E8hOxRoZKEFDiHp6AHYREuMv6Uv5XPc2+eDSDTF
pjLo4mitgyf01X4sykfgRX/OVeJQ0Jt5PqjUWhcsXTcnrW7RCJ6MldqoIhGur0ex
IgeIMJc4+XXrQy7j7Hmoi6KOWhFXTOsSOWR0ecdpa/vJhxkGEndgW5Qk4WexVrHJ
cjfLWHpGtHu8WYyj8Z5mmpUD3AsQ5haNtUijgAoyCCmudMcECbhXzDbluREm3AyL
KmUXpkgKo8jA4MIBdRK9+DWTt7M1q9qO5ZnzfKzwT0lRQVFIJJIsAZn1tQsvFr0a
rx8ChmSLjsMPx716kmOY3VjkOCF/zUv1jt8e3M4PhRBbT9psraVQDX4ruca7H3fE
j+GWNyPEBlhuPoiSH5KzCB2s4qWlEzUkwJ+AyHBtcQjH23eB0KMNCxxopISrPLNG
ShdM3VHHhVC+IiC63dId3JJ3D/+64NcGl/vmaj9H1yXQ3ziRMC0FEnY0EnkLnVwT
c1CZ0kD+tCLloe4PgkbuwRCf9qBUBxJnluv0B3XyfAk0SqmSvFM=
=3GlM
-END PGP SIGNATURE-

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

[qubes-users] Re: Qubes 4 boot ISO

[Drew White]

Is there no one that has had this issue and resolved 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/c1378cfd-e9e5-472c-b845-845bf9aca9b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Cannot install Qubes OS 4.0 on ASUS ZenBook UX501VW-FY102T

['awokd' via qubes-users]

On Wed, May 2, 2018 12:49 pm, Astro Naute wrote:
> Hi,
>
>
> I'm installing Qubes OS 4.0 from USB burned with rufus-2.18p (dd).
>
>
> Laptop is ASUS ZenBook UX501VW-FY102T:
> - i7-6700HQ
> - SSD M.2 PCIe x4 512 Gb
> - NVIDIA GeForce GTX 960M
>
>
> I'm getting the message at the end:
> "X startup failed, aborting installation"

Check out https://www.qubes-os.org/doc/nvidia-troubleshooting/ - you
probably need to add "nouveau.modeset=0" described towards the bottom. If
it's an option, disabling the nvidia GPU in your UEFI settings might also
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/9faeaa6420c017d78c92f5a059a1fde5.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q 4.0 updates took my sys-net off line

[Franz]

On Wed, May 2, 2018 at 4:03 PM, Coleman, Steve L. 
wrote:

>
> --
> *From:* Franz <169...@gmail.com>
> *Sent:* Wednesday, May 2, 2018 2:58 PM
> *To:* Coleman, Steve L.
> *Cc:* qubes-users@googlegroups.com
> *Subject:* Re: [qubes-users] Q 4.0 updates took my sys-net off line
>
> Have you tried using a different template to generate sys-net?
>
> Yes, I have tried my fedora-26-net, fedora-26-minimal, and generic
> fedora-26 templates with both the old sys-net and the one I re-created.
> None of that helped.
>
>
>
It is always Fedora, perhaps Debian...



> On Wed, May 2, 2018 at 3:46 PM, Coleman, Steve L. <
> steve.cole...@jhuapl.edu> wrote:
>
>> Yesterday I pulled some Dom0 updates and rebooted to complete the
>> install, and since then had no luck at getting it back online. My sys-net
>> is not properly configuring the network card so that eth0 never gets
>> configured properly and assigned an address.
>>
>>
>> I have tried switching between HVM/PV modes with no luck. I created a new
>> sys-net and assigned the controller over with no joy either. Any advice on
>> what to look at next would be very much appreciated.
>>
>>
>> [user@sys-net ~]$ ifconfig -a
>> enp0s0: flags=4163  mtu 1500
>> ether 18:03:73:be:70:17  txqueuelen 1000  (Ethernet)
>> RX packets 2033  bytes 193536 (189.0 KiB)
>> RX errors 132  dropped 0  overruns 0  frame 132
>> TX packets 7797  bytes 1484630 (1.4 MiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>> device interrupt 26  memory 0xe160-e162
>>
>> lo: flags=73  mtu 65536
>> inet 127.0.0.1  netmask 255.0.0.0
>> inet6 ::1  prefixlen 128  scopeid 0x10
>> loop  txqueuelen 1000  (Local Loopback)
>> RX packets 645  bytes 31721 (30.9 KiB)
>> RX errors 0  dropped 0  overruns 0  frame 0
>> TX packets 645  bytes 31721 (30.9 KiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> vif6.0: flags=4163  mtu 1500
>> inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
>> inet6 fe80::fcff::feff:  prefixlen 64  scopeid 0x20
>> ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
>> RX packets 16375  bytes 1014366 (990.5 KiB)
>> RX errors 0  dropped 0  overruns 0  frame 0
>> TX packets 14967  bytes 1473500 (1.4 MiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>>
>>
>> [user@sys-net ~]$ sudo dmesg | grep -i e1000e
>> [8.488338] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
>> [8.488350] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
>> [8.488565] e1000e :00:00.0: Xen PCI mapped GSI20 to IRQ26
>> [8.489625] e1000e :00:00.0: Interrupt Throttling Rate (ints/sec)
>> set to dynamic conservative mode
>> [8.589599] e1000e :00:00.0 :00:00.0 (uninitialized):
>> registered PHC clock
>> [8.684606] e1000e :00:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
>> 18:03:73:be:70:17
>> [8.684638] e1000e :00:00.0 eth0: Intel(R) PRO/1000 Network
>> Connection
>> [8.684690] e1000e :00:00.0 eth0: MAC: 10, PHY: 11, PBA No:
>> E041FF-0FF
>> [8.747515] e1000e :00:00.0 enp0s0: renamed from eth0
>> [   18.923186] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: None
>> [44053.103546] e1000e: enp0s0 NIC Link is Down
>> [44062.829234] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: None
>> [44103.730522] e1000e: enp0s0 NIC Link is Down
>> [44106.646419] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: None
>> [44119.384485] e1000e: enp0s0 NIC Link is Down
>> [44122.317273] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: None
>>
>> [@dom0 ~] lspci | grep Ethernet
>> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
>> Connection (Lewisville) (rev 04)
>>
>>
>> --
>> 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/ms
>> gid/qubes-users/1525286811400.68924%40jhuapl.edu
>> 
>> .
>> 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 

Re: [qubes-users] Difference between Whonix Workstation and Debian/Fedora?

[jsnow]

Daniil .Travnikov:
>> It's possible to use a debian/fedora based appVM with firefox, connected
>> to sys-whonix, and all connections will go through tor.
>>
>> But whonix recommends to use a whonix-ws based appVM with tor browser
>> instead to reduce fingerprintability. Most tor users are using tor
>> browser, so if you're using tor with firefox and not tor browser it's
>> easier to fingerprint you.
> 
> 
> Whonix recommends this, but nothing to tell about Qubes Whonix. Qubes 
> contains the basis of Whonix Workstation logic in all OS.

I'm not sure what you mean here?

> When we use Whonix-Gateway we have one TOR connection (3 onion connections), 
> but when we use TOR browser (in any OS) we have second TOR connection (which 
> means that now we have already 6 onions). And in some reason it is not a safe 
> way.

Whonix already prevents tor over tor connections. When you use tor
browser in a whonix-ws based VM connected to sys-whonix it won't be tor
over tor (there will only be 3 relays not 6).

At least when you use tor browser in a whonix-ws based vm anyways. From
looking at the whonix documentation it looks like if you download tor
browser in a regular debian/fedora based vm and connect to sys-whonix
that would result in tor over tor. Whonix modifies tor browser in
whonix-ws so it works with whonix-gw/sys-whonix to prevent tor over tor.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Tor_Browser#Whonix_Tor_Browser_Differences

https://www.whonix.org/wiki/Tor_Browser#Whonix_Tor_Browser_Differences

But anyways, using tor browser in whonix-ws based appVM connected to
sys-whonix doesn't result in tor over tor.

So it looks like there are basically 4 ways to browse the internet using
tor with qubes:

1. Use tor browser in a whonix-ws based appVM connected to sys-whonix
(this is recommended, whonix prevents tor over tor scenarios, and all
other traffic from the vm outside of tor browser is also routed through tor)

2. Use tor browser in a regular debian/fedora based appVM connected to
sys-firewall (just like using tor browser outside of whonix, you'd miss
out on any other whonix features, and other traffic from that vm outside
of tor browser would not be routed through tor)

3. Use regular firefox in a debian/fedora based appVM connected to
sys-whonix (no tor over tor, and all traffic from the VM is routed
through tor, but it would be easier for adversaries to fingerprint you
because most tor users use tor browser, not firefox, so you're more
unique this way)

4. Use tor browser in a regular debian/fedora based appVM connected to
sys-whonix (this would result in tor over tor, which is bad)

At least this is my understanding based in what i've read in the whonix
docs, but someone may know better than me!

-- 
Jackie

-- 
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/ee03caeb-fb5f-3b3e-44d5-63bd3c360271%40bitmessage.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q 4.0 updates took my sys-net off line

[Coleman, Steve L.]

From: Franz <169...@gmail.com>
Sent: Wednesday, May 2, 2018 2:58 PM
To: Coleman, Steve L.
Cc: qubes-users@googlegroups.com
Subject: Re: [qubes-users] Q 4.0 updates took my sys-net off line

Have you tried using a different template to generate sys-net?

Yes, I have tried my fedora-26-net, fedora-26-minimal, and generic fedora-26 
templates with both the old sys-net and the one I re-created.  None of that 
helped.


On Wed, May 2, 2018 at 3:46 PM, Coleman, Steve L. 
> wrote:

Yesterday I pulled some Dom0 updates and rebooted to complete the install, and 
since then had no luck at getting it back online. My sys-net is not properly 
configuring the network card so that eth0 never gets configured properly and 
assigned an address.


I have tried switching between HVM/PV modes with no luck. I created a new 
sys-net and assigned the controller over with no joy either. Any advice on what 
to look at next would be very much appreciated.


[user@sys-net ~]$ ifconfig -a
enp0s0: flags=4163  mtu 1500
ether 18:03:73:be:70:17  txqueuelen 1000  (Ethernet)
RX packets 2033  bytes 193536 (189.0 KiB)
RX errors 132  dropped 0  overruns 0  frame 132
TX packets 7797  bytes 1484630 (1.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 26  memory 0xe160-e162

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 645  bytes 31721 (30.9 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 645  bytes 31721 (30.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vif6.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
inet6 fe80::fcff::feff:  prefixlen 64  scopeid 0x20
ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
RX packets 16375  bytes 1014366 (990.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 14967  bytes 1473500 (1.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


[user@sys-net ~]$ sudo dmesg | grep -i e1000e
[8.488338] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[8.488350] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[8.488565] e1000e :00:00.0: Xen PCI mapped GSI20 to IRQ26
[8.489625] e1000e :00:00.0: Interrupt Throttling Rate (ints/sec) set to 
dynamic conservative mode
[8.589599] e1000e :00:00.0 :00:00.0 (uninitialized): registered PHC 
clock
[8.684606] e1000e :00:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 
18:03:73:be:70:17
[8.684638] e1000e :00:00.0 eth0: Intel(R) PRO/1000 Network Connection
[8.684690] e1000e :00:00.0 eth0: MAC: 10, PHY: 11, PBA No: E041FF-0FF
[8.747515] e1000e :00:00.0 enp0s0: renamed from eth0
[   18.923186] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44053.103546] e1000e: enp0s0 NIC Link is Down
[44062.829234] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44103.730522] e1000e: enp0s0 NIC Link is Down
[44106.646419] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44119.384485] e1000e: enp0s0 NIC Link is Down
[44122.317273] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None

[@dom0 ~] lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network 
Connection (Lewisville) (rev 04)


--
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/1525286811400.68924%40jhuapl.edu.
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/1525287841118.78183%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q 4.0 updates took my sys-net off line

[Franz]

Have you tried using a different template to generate sys-net?

On Wed, May 2, 2018 at 3:46 PM, Coleman, Steve L. 
wrote:

> Yesterday I pulled some Dom0 updates and rebooted to complete the install,
> and since then had no luck at getting it back online. My sys-net is not
> properly configuring the network card so that eth0 never gets configured
> properly and assigned an address.
>
>
> I have tried switching between HVM/PV modes with no luck. I created a new
> sys-net and assigned the controller over with no joy either. Any advice on
> what to look at next would be very much appreciated.
>
>
> [user@sys-net ~]$ ifconfig -a
> enp0s0: flags=4163  mtu 1500
> ether 18:03:73:be:70:17  txqueuelen 1000  (Ethernet)
> RX packets 2033  bytes 193536 (189.0 KiB)
> RX errors 132  dropped 0  overruns 0  frame 132
> TX packets 7797  bytes 1484630 (1.4 MiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> device interrupt 26  memory 0xe160-e162
>
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 645  bytes 31721 (30.9 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 645  bytes 31721 (30.9 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> vif6.0: flags=4163  mtu 1500
> inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
> inet6 fe80::fcff::feff:  prefixlen 64  scopeid 0x20
> ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
> RX packets 16375  bytes 1014366 (990.5 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 14967  bytes 1473500 (1.4 MiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
>
>
> [user@sys-net ~]$ sudo dmesg | grep -i e1000e
> [8.488338] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
> [8.488350] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> [8.488565] e1000e :00:00.0: Xen PCI mapped GSI20 to IRQ26
> [8.489625] e1000e :00:00.0: Interrupt Throttling Rate (ints/sec)
> set to dynamic conservative mode
> [8.589599] e1000e :00:00.0 :00:00.0 (uninitialized):
> registered PHC clock
> [8.684606] e1000e :00:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
> 18:03:73:be:70:17
> [8.684638] e1000e :00:00.0 eth0: Intel(R) PRO/1000 Network
> Connection
> [8.684690] e1000e :00:00.0 eth0: MAC: 10, PHY: 11, PBA No:
> E041FF-0FF
> [8.747515] e1000e :00:00.0 enp0s0: renamed from eth0
> [   18.923186] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: None
> [44053.103546] e1000e: enp0s0 NIC Link is Down
> [44062.829234] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: None
> [44103.730522] e1000e: enp0s0 NIC Link is Down
> [44106.646419] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: None
> [44119.384485] e1000e: enp0s0 NIC Link is Down
> [44122.317273] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: None
>
> [@dom0 ~] lspci | grep Ethernet
> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
> Connection (Lewisville) (rev 04)
>
>
> --
> 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/1525286811400.68924%40jhuapl.edu
> 
> .
> 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/CAPzH-qDzj0nM%3DeT66Dnryg%3DDT%2BtefXGxNziOB-YcuQDeWOXg7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Q 4.0 updates took my sys-net off line

[Coleman, Steve L.]

Yesterday I pulled some Dom0 updates and rebooted to complete the install, and 
since then had no luck at getting it back online. My sys-net is not properly 
configuring the network card so that eth0 never gets configured properly and 
assigned an address.


I have tried switching between HVM/PV modes with no luck. I created a new 
sys-net and assigned the controller over with no joy either. Any advice on what 
to look at next would be very much appreciated.


[user@sys-net ~]$ ifconfig -a
enp0s0: flags=4163  mtu 1500
ether 18:03:73:be:70:17  txqueuelen 1000  (Ethernet)
RX packets 2033  bytes 193536 (189.0 KiB)
RX errors 132  dropped 0  overruns 0  frame 132
TX packets 7797  bytes 1484630 (1.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 26  memory 0xe160-e162

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 645  bytes 31721 (30.9 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 645  bytes 31721 (30.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vif6.0: flags=4163  mtu 1500
inet 10.137.0.5  netmask 255.255.255.255  broadcast 0.0.0.0
inet6 fe80::fcff::feff:  prefixlen 64  scopeid 0x20
ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
RX packets 16375  bytes 1014366 (990.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 14967  bytes 1473500 (1.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


[user@sys-net ~]$ sudo dmesg | grep -i e1000e
[8.488338] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[8.488350] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[8.488565] e1000e :00:00.0: Xen PCI mapped GSI20 to IRQ26
[8.489625] e1000e :00:00.0: Interrupt Throttling Rate (ints/sec) set to 
dynamic conservative mode
[8.589599] e1000e :00:00.0 :00:00.0 (uninitialized): registered PHC 
clock
[8.684606] e1000e :00:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 
18:03:73:be:70:17
[8.684638] e1000e :00:00.0 eth0: Intel(R) PRO/1000 Network Connection
[8.684690] e1000e :00:00.0 eth0: MAC: 10, PHY: 11, PBA No: E041FF-0FF
[8.747515] e1000e :00:00.0 enp0s0: renamed from eth0
[   18.923186] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44053.103546] e1000e: enp0s0 NIC Link is Down
[44062.829234] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44103.730522] e1000e: enp0s0 NIC Link is Down
[44106.646419] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None
[44119.384485] e1000e: enp0s0 NIC Link is Down
[44122.317273] e1000e: enp0s0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: None

[@dom0 ~] lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network 
Connection (Lewisville) (rev 04)

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

Re: [qubes-users] Ledger Nano S

[qubenix]

bojanso...@gmail.com:
> 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.
> 

It might have something to do with udev rules in your target VM. See
here:
https://support.ledgerwallet.com/hc/en-us/articles/115005165269-What-to-do-if-my-Ledger-Nano-S-is-not-recognized-on-Windows-and-or-Linux-

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/25e4c33c-f47c-e074-1633-863d151dffd1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Ledger Nano S

[bojansoren]

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.

-- 
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/4ccf3953-bd15-4ced-9f41-8bca8647b9c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Ledger Nano S

[bojansoren]

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?

-- 
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/5679a551-0915-49bd-b3a0-afb8be720303%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Cannot install Qubes OS 4.0 on ASUS ZenBook UX501VW-FY102T

[Astro Naute]

Hi,

I'm installing Qubes OS 4.0 from USB burned with rufus-2.18p (dd).

Laptop is ASUS ZenBook UX501VW-FY102T:
- i7-6700HQ
- SSD M.2 PCIe x4 512 Gb
- NVIDIA GeForce GTX 960M

I'm getting the message at the end:
"X startup failed, aborting installation"

Full installation video:
https://photos.app.goo.gl/ROBPszV8uw3bUHq72

What can I do please?

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/026dfed2-3f66-4719-86fe-d2da879f4521%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora 28 just released

[robin]

On Wednesday, May 2, 2018 at 5:05:14 AM UTC+2, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-05-01 16:00, Frédéric Pierret (fepitre) wrote:
> > Le mardi 1 mai 2018 21:28:03 UTC+2, steve.coleman a écrit :
> >> Needless to say that means an EOL for 25 is going to be announced
> >> fairly soon.
> >> 
> 
> Correct. In one month, to be precise.
> 
> For reference, here are our issues for Fedora 27 and 28 TemplateVMs:
> 
> 27 - https://github.com/QubesOS/qubes-issues/issues/3783
> 28 - https://github.com/QubesOS/qubes-issues/issues/3791
> 
> Ideally, we would announce today that our Fedora 26 TemplateVMs will
> reach EOL in one month in order to give users plenty of time to
> upgrade or migrate to a new template (just as we do when Qubes
> versions reach EOL). However, since we do not have a new template to
> offer yet, I'm going to postpone that announcement until the
> information is actionable for users. We will also make an announcement
> on 2018-06-01 stating that Fedora 26 has reached EOL, as a final
> reminder to anyone who hasn't migrated yet that they should do so
> immediately.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlrpKtcACgkQ203TvDlQ
> MDAmMhAAzZvlN6qOH6ph8QQmM6uFvdDIzB30jh/H1k/TJo9VadvqbSBiay5kRoCn
> GuX0gVE/9r2b7ck5vPjiy59MXdJs4cygdDG3+SsB4JrLMu+NI7EwB1p9HmLKuBJc
> zUP1bSiW05DHXgdUWbxoSg0G77UGyoAVs+6zUxajv04mPR1otJNWaJMyEhPak//g
> zzb8gqYx5EZLB5w5vcAvSmGQHJujcEEbvEndPleSr6+XOqYLVD8AfjCCISG9L0sy
> xjn2LHM5uO+1WKZStBnNbYBBSMDmW1DDQ/2M4zbVHPBDCx80cJx0lT78CqrzJ7d9
> dMk2MCH8NY7Dqr2Bl7ckS+O7JyLI5KFXIlH+90XxkeKo/dRVAQ0+JlfEzGxXPicv
> 56FsSGJ42MKrJ8uPAgZ5KiKqEGtJmolQONkNCTvwyplBWixwqpSmZEEYL1i8f91c
> f0akf67yLUjbxzVIbA7PYvMv4MYAJEwVciPMRyjjTxt/dT9X2pyMEoIHJu9LZFnv
> 7aXppwaR2POnqOIUznW311d3+kik4rlDHKURxxji7V0kF5DrGoVMeFrPDLCUmWxf
> WGKf7fLbvS/1Uc57i/MzaHsyZjBiKuiVInvIevG+LFO6nQDJsRGxaI/EHQpsxqlG
> /FcU0HiRlHiNzJRChGSSq6SS0AHm/lBA4U8mTJXYzjkpbjoUXVY=
> =iG/S
> -END PGP SIGNATURE-

Will the fedora 27 template also work on/be ported to Qubes 3.2, or will fedora 
26 be the last supported template for that Qubes version? If so, I guess that 
means you'll have to upgrade to Qubes 4/4.1 if you want to use fedora templates 
and get security updates?

Kind regards,
Robin

-- 
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/b9c836e3-0668-4d5a-8605-fbc6027a287b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] how do I / Can I propagate language settings to all VMs?

[trueriver]

hi everyone

When installing, I set UK Engish and the keyboard works as expected in all VMs 
(no surprise as the hci i/o is done by dom0)

However, packages that would usually pick up locale info on a more traditional 
Linux all seem to think I am in the US. 

I find I am having to tell libreoffice separately in eqach AppVM that I want 
British pounds and European format dates (so 2/5 is second May not Feb fifth)

Can I force all templates to pick up my locale and pass it on to any software 
that asks for it? If so, how?

Other questions

I wonder if this is worth a UX issue, to get the install locale propagated? 
What do people think?

Or a checkbox in create qubes VM to propagate dom0 locale?

I think it has to be optional, because there is a security advantage for some 
use-cases in masking the user's actual locale.


I realise now I could have run libreoffice in a single appVM, made the changes, 
then cloned that appVM. But now that I have got each appVM tweaked in other 
ways, I am reluctant to go back and do that. So is there some other way I can 
propagate the language/locale around my appVMs?


Finally, just to note that libreoffice is locked into thinking the user 
interface is English USA - this does not seem to cause problems (presumably 
because the AppVM is not using its user interface).

-- 
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/e36e87bb-59aa-4114-9196-80df9b6facbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: sys-net self starts about 40min after boot

[trueriver]

THanks for the responses
Chris Laprise said
> See this issue:
> https://github.com/QubesOS/qubes-issues/issues/3588



Yes my observations are consistent with sys-net being triggered by an 
on-the-hour cron. I have commented on that issue and mark this thread as 
complete



-- 
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/f83106e9-11f4-41f8-a0a1-8a3ab11850c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Difference between Whonix Workstation and Debian/Fedora?

[Daniil .Travnikov]

Thank you for your involvement!


> It's possible to use a debian/fedora based appVM with firefox, connected
> to sys-whonix, and all connections will go through tor.
> 
> But whonix recommends to use a whonix-ws based appVM with tor browser
> instead to reduce fingerprintability. Most tor users are using tor
> browser, so if you're using tor with firefox and not tor browser it's
> easier to fingerprint you.


Whonix recommends this, but nothing to tell about Qubes Whonix. Qubes contains 
the basis of Whonix Workstation logic in all OS.



When we use Whonix-Gateway we have one TOR connection (3 onion connections), 
but when we use TOR browser (in any OS) we have second TOR connection (which 
means that now we have already 6 onions). And in some reason it is not a safe 
way. This is what I found:

"Please note that a Tor-over-Tor connection will always, without exception, be 
less safe than a normal Tor connection. There is always a possibility that your 
Tor connection would use the initial Tor connections guard as an exit, 
introduction point, rendezvous point, or in some other way interact with your 
own guard in such a way that it would be using a single relay for ingress and 
egress.
Never, ever use Tor-over-Tor. It is always less safe."
*** https://tor.stackexchange.com/questions/10071/running-tor-over-tor



On official site of Tor project I found a mention only in this way:

"* Simplified custom user installation of TorChat, thanks to dummytor.
(Protecting from Tor over Tor.)"
*** https://lists.torproject.org/pipermail/tor-talk/2014-February/032227.html

>From which one can draw a conclusion that official position on this issue that 
>Tor over Tor is not safe.



As I understand Whonix-Workstation is on a completely isolated network, it 
means that only connections through Tor are possible. But for Qubes users it 
does not make any sense because any OS (isolated) could work through TOR 
connection with Whonix-Gateway without Whonix-Workstation.

Actually you can download and install TOR browser but disconnect it from TOR 
network in Firefox options. It means that you will use Tor Browser with the 
same security level, but without direct TOR connection from Firefox. Of course 
it would be better only if you use this browser through Whonix-Gateway.

 
> I don't know if there are any other reasons why you would need to use
> whonix-ws instead of debian/fedora or if there's any reason not to use
> tor browser in a debian/fedora VM. But i like to use whonix-ws as a
> template for any VM that's going to connect to tor, and debian for other
> VMs.

That's why I am interested in this question. Maybe somebody use 
Whonix-Workstation for other reasons?

-- 
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/b68a1e15-4368-4bd6-b5ec-bc1e77152994%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

[Ivan Mitev]

Hey,

On 05/02/2018 12:13 PM, NaBaCo wrote:
> On 05/02/18 12:03, Ivan Mitev wrote:
>>
>>
>> On 05/02/2018 11:25 AM, NaBaCo wrote:
>>> On 05/02/18 09:52, 'awokd' via qubes-users wrote:
 On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
> Hello,
> I have a simple command in /rw/config/rc.local the sets the keyboard
> layout and shortcuts. I have made the script executable, and after
> searching the internet found there's a timing problem (the system runs the
> script too early), so I've added "sleep 5" to the beginning of the script.
>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
> manually from command line, yet when I start the VMs, there's no effect.
> This affects both debian-9 and fedora-26 AppVMs.
> Increasing the "sleep" time didn't help.

 Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
 /home/user/1", chmod 755 it, and it worked first try. Might want to add
 something similar to yours to make sure it's firing, then troubleshoot
 accordingly. Also check out
 https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.

>>>
>>> Hey,
>>> I rebooted the VM after adding your line to rc.local, and indeed it
>>> fires up. I'm assuming that rc.local runs before X server starts up.
>>> The command I want to run is 'setxkbmap'.
>>
>> As awokd pointed, rc.local starts before the X server is active.
>>
>> A workaround is to use .desktop files, which would autostart after X.
>>
>> See this doc (which by the way should help you with what you're trying
>> to achieve with keyb layouts).
>>
>> https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md
>>
> 
> Thanks Ivan, this is going to be the doc I'll change :)
> The .desktop work-around is somewhat inelegant in my opinion - why not
> use an already integrated feature rather then working around?

IIRC I first tried to put stuff in rc.local, then found out it was
started before X. I then tried with /etc/profile.d but it worked only if
you had opened a terminal. I then settled on .desktop files in
/etc/xdg/autostart, which is also the mechanism chosen by Qubes to
autostart various things.

I'd be happy to update the doc with a "cleaner", integrated solution -
feel free to send comments. Or even better - if you can - please submit
a push request with your changes (one of the ideas behind the Qubes
Community project is to be a "staging" ground for documentation, which
could then find its way to the official Qubes documentation after enough
testing). You're most likely the first user to follow this community
doc, so feel free to send any comments - not only related to the
autostart problem.

> Either way, thank you very much!

No problem :)

> --
> NaBaCo.
> 
> 
> 

-- 
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/1a353790-c7d6-7ff9-3abd-1320ec6aaa71%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

[NaBaCo]

On 05/02/18 12:03, Ivan Mitev wrote:
> 
> 
> On 05/02/2018 11:25 AM, NaBaCo wrote:
>> On 05/02/18 09:52, 'awokd' via qubes-users wrote:
>>> On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
 Hello,
 I have a simple command in /rw/config/rc.local the sets the keyboard
 layout and shortcuts. I have made the script executable, and after
 searching the internet found there's a timing problem (the system runs the
 script too early), so I've added "sleep 5" to the beginning of the script.
  The script worked well in Q3.2, and runs well even now in Q4.0 when run
 manually from command line, yet when I start the VMs, there's no effect.
 This affects both debian-9 and fedora-26 AppVMs.
 Increasing the "sleep" time didn't help.
>>>
>>> Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
>>> /home/user/1", chmod 755 it, and it worked first try. Might want to add
>>> something similar to yours to make sure it's firing, then troubleshoot
>>> accordingly. Also check out
>>> https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.
>>>
>>
>> Hey,
>> I rebooted the VM after adding your line to rc.local, and indeed it
>> fires up. I'm assuming that rc.local runs before X server starts up.
>> The command I want to run is 'setxkbmap'.
> 
> As awokd pointed, rc.local starts before the X server is active.
> 
> A workaround is to use .desktop files, which would autostart after X.
> 
> See this doc (which by the way should help you with what you're trying
> to achieve with keyb layouts).
> 
> https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md
> 

Thanks Ivan, this is going to be the doc I'll change :)
The .desktop work-around is somewhat inelegant in my opinion - why not
use an already integrated feature rather then working around?

Either way, thank you very much!
--
NaBaCo.



-- 
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/pcbvc7%24iu4%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

[Ivan Mitev]

On 05/02/2018 11:25 AM, NaBaCo wrote:
> On 05/02/18 09:52, 'awokd' via qubes-users wrote:
>> On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
>>> Hello,
>>> I have a simple command in /rw/config/rc.local the sets the keyboard
>>> layout and shortcuts. I have made the script executable, and after
>>> searching the internet found there's a timing problem (the system runs the
>>> script too early), so I've added "sleep 5" to the beginning of the script.
>>>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
>>> manually from command line, yet when I start the VMs, there's no effect.
>>> This affects both debian-9 and fedora-26 AppVMs.
>>> Increasing the "sleep" time didn't help.
>>
>> Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
>> /home/user/1", chmod 755 it, and it worked first try. Might want to add
>> something similar to yours to make sure it's firing, then troubleshoot
>> accordingly. Also check out
>> https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.
>>
> 
> Hey,
> I rebooted the VM after adding your line to rc.local, and indeed it
> fires up. I'm assuming that rc.local runs before X server starts up.
> The command I want to run is 'setxkbmap'.

As awokd pointed, rc.local starts before the X server is active.

A workaround is to use .desktop files, which would autostart after X.

See this doc (which by the way should help you with what you're trying
to achieve with keyb layouts).

https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md



> 
> Either way, I looked at the link you've posted and it made me think to
> look inside /etc, where I found:
> 
> (fedora-26) /etc/X11/xinit/xinitrc.d/qubes-keymap.sh
> (debian-9) /etc/X11/Xsession.d/90qubes-keyboard
> 
> From my understanding it is a script that runs automatically at X server
> start up, which parses the user's keyboard settings in
> ~/.config/qubes-keyboard-layout.rc.
> 
> The only problem was that it parses only -layout and -variant but not
> -option, so I've added that capability to the script (attached), thus
> allowing it to add custom key combinations for layout switching.
> Then I added the necessary options in
> ~/.config/qubes-keyboard-layout.rc, each separated by a + sign:
> 
> us,il,ru + ,,phonetic + grp:alt_shift_toggle
> 
> And that worked perfectly for me.
> 
> Then, after another thought, since I want the same layout configuration
> to propagate to all the VMs, I just commented out the entire script, and
> added the command I wanted in the end (last line in the attached file).
> That worked perfectly well too.
> 
> Solved!
> Thank you for your help.
> 
> --
> NaBaCo.
> 
> PS: If relevant, I'll be glad to make a PR for the script and to add
> this into the official documentation.
> 

-- 
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/027b1942-2f9b-563a-19d7-7c56bb2e11bc%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

['awokd' via qubes-users]

On Wed, May 2, 2018 8:25 am, NaBaCo wrote:

> I rebooted the VM after adding your line to rc.local, and indeed it
> fires up. I'm assuming that rc.local runs before X server starts up. The
> command I want to run is 'setxkbmap'.

I think rc.local runs in a different session than X, so it doesn't pick up
X-specific options/commands set within.

> Either way, I looked at the link you've posted and it made me think to
> look inside /etc, where I found:
>
> (fedora-26) /etc/X11/xinit/xinitrc.d/qubes-keymap.sh
> (debian-9) /etc/X11/Xsession.d/90qubes-keyboard
>
>
> From my understanding it is a script that runs automatically at X server
> start up, which parses the user's keyboard settings in
> ~/.config/qubes-keyboard-layout.rc.
>
>
> The only problem was that it parses only -layout and -variant but not
> -option, so I've added that capability to the script (attached), thus
> allowing it to add custom key combinations for layout switching. Then I
> added the necessary options in ~/.config/qubes-keyboard-layout.rc, each
> separated by a + sign:
>
> us,il,ru + ,,phonetic + grp:alt_shift_toggle
>
> And that worked perfectly for me.

> PS: If relevant, I'll be glad to make a PR for the script and to add
> this into the official documentation.

Sounds like that -option parsing could be helpful to other users too. I
think the developers are stretched pretty thin so you might want to ask
over on qubes-devel or just go ahead and submit the PR directly on the
Fedora & Debian scripts to see if they like the idea, then update the docs
accordingly. Glad you got it working!


-- 
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/d3a58ffcd39527753784d2aedb335078.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL - Clevo N850

[bruno ais]

On Wednesday, May 2, 2018 at 7:35:11 AM UTC+1, awokd wrote:
> On Tue, May 1, 2018 3:14 pm, Brunoais wrote:
> 
> >
> > GPU (GTX1050TiM) passthrough: Unfortunately, I was completely unable to
> > setup a passthrough for this GPU. I've tried many other success stories.
> > According to my research, I'd need nouveau working on DOM0 and qubes
> > allowing OpenGL (or equivalent) because the contents of the qube would be
> > shown on a window instead of a different screen and then I'd need to get
> > bumblebee (or equivalent) to work on DOM0. (E.g. guide:
> > https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28)
> 
> That's an interesting link. Looks like he is using QEMU and passing
> through the discrete GPU to his VM, then getting output back over
> RDP/RemoteFX. You should be able to pass the GPU through to a Qube by
> attaching it, but I'm not sure anyone has been able to get it to work like
> you describe.

No matter what I try, I keep getting crashes from the OS in the VM when I do a 
GPU passthrough. I'm still investigating if I'm missing something by using more 
permissive OSs (ubuntu MATE, for now).
I did notice that, with ubuntu, I'd have to set "nomodeset" for the booting 
parameters, otherwise, it would exponentially get slower up to a complete 
unresponsiveness.

-- 
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/7298a082-f6c6-42da-ac4f-523f1d0b29e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

[NaBaCo]

On 05/02/18 09:52, 'awokd' via qubes-users wrote:
> On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
>> Hello,
>> I have a simple command in /rw/config/rc.local the sets the keyboard
>> layout and shortcuts. I have made the script executable, and after
>> searching the internet found there's a timing problem (the system runs the
>> script too early), so I've added "sleep 5" to the beginning of the script.
>>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
>> manually from command line, yet when I start the VMs, there's no effect.
>> This affects both debian-9 and fedora-26 AppVMs.
>> Increasing the "sleep" time didn't help.
> 
> Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
> /home/user/1", chmod 755 it, and it worked first try. Might want to add
> something similar to yours to make sure it's firing, then troubleshoot
> accordingly. Also check out
> https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.
> 

Hey,
I rebooted the VM after adding your line to rc.local, and indeed it
fires up. I'm assuming that rc.local runs before X server starts up.
The command I want to run is 'setxkbmap'.

Either way, I looked at the link you've posted and it made me think to
look inside /etc, where I found:

(fedora-26) /etc/X11/xinit/xinitrc.d/qubes-keymap.sh
(debian-9) /etc/X11/Xsession.d/90qubes-keyboard

>From my understanding it is a script that runs automatically at X server
start up, which parses the user's keyboard settings in
~/.config/qubes-keyboard-layout.rc.

The only problem was that it parses only -layout and -variant but not
-option, so I've added that capability to the script (attached), thus
allowing it to add custom key combinations for layout switching.
Then I added the necessary options in
~/.config/qubes-keyboard-layout.rc, each separated by a + sign:

us,il,ru + ,,phonetic + grp:alt_shift_toggle

And that worked perfectly for me.

Then, after another thought, since I want the same layout configuration
to propagate to all the VMs, I just commented out the entire script, and
added the command I wanted in the end (last line in the attached file).
That worked perfectly well too.

Solved!
Thank you for your help.

--
NaBaCo.

PS: If relevant, I'll be glad to make a PR for the script and to add
this into the official documentation.

-- 
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/pcbshl%248g5%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


qubes-keymap.sh
Description: application/shellscript

Re: [qubes-users] Re: 4.0 'current' in dom0 but 'current-testing' in Fed26 based AppVM?

['awokd' via qubes-users]

On Wed, May 2, 2018 7:54 am, john wrote:

>
> thanks for responding, so in the Fed-26 template sudo dnf list installed
> qubes-* shows most of the packages as "current-testing"  but
>
> in Fed-26's /qubes-r4.repo   only  "current"  has an enabled=1
>
> not  "current-testing"
>
>
> so, am I getting updates  to "current-testing"  or "current"   or  If I
> prefer "current"  how would I fix this ?

You're all set then- you are getting updates for "current" only. You must
have manually updated to testing at some point. Now it's just a matter of
waiting until the packages released at "current" supersede the ones you
updated earlier from testing. If you want to force it, you could reinstall
the template but I'd just wait unless you are having problems from one of
the testing packages.


-- 
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/71c5f9d3102629f273b4480fe09cdf89.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: 4.0 'current' in dom0 but 'current-testing' in Fed26 based AppVM?

[john]

On 05/01/18 21:19, 'awokd' via qubes-users wrote:

On Tue, May 1, 2018 5:36 pm, john wrote:

Hello,  when I look at that "boolean" in /etc/yum.repos.d/qubes-dom0.repo


This file only applies to updates for dom0, not templates. You need to
look inside each template's repo settings (and probably disable testing if
it's enabled). See Testing Repositories under
https://www.qubes-os.org/doc/software-update-vm/.




thanks for responding, so in the Fed-26 template
sudo dnf list installed qubes-*
shows most of the packages as "current-testing"  but

in Fed-26's /qubes-r4.repo   only  "current"  has an enabled=1

not  "current-testing"


so, am I getting updates  to "current-testing"  or "current"   or  If I 
prefer "current"  how would I fix this ?



I'll go read the URL you provided  also :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/920c8d3a-2b25-0d37-422e-2c882d7592f9%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 4.0 set hw clock timezone for windows AppVM

['awokd' via qubes-users]

On Wed, May 2, 2018 3:19 am, wyory wrote:
> Hi,
>
>
> I have a time mismatch between my dom0 and my windows AppVM (Linux
> AppVMs are fine).
>
>
> In 3.2, it was possible to offset the hw clock for an AppVM using
> qvm-prefs timezone. As far as I can tell, that option is no longer
> available. What's the correct way to address this?

Look for a Windows registry setting that tells it the hardware clock is in
UTC.

-- 
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/13152a8a0f3ea45df5f11e2b55b0bb1f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 4.0 interrupted AppVM restore, completed restore

['awokd' via qubes-users]

On Wed, May 2, 2018 2:37 am, wyory wrote:
> Hi,
>
>
> I accidentally interrupted the AppVM restore process and then ran it
> again and completed it. Now I have two copies of every AppVM ("name" and
> "name1"). How can I tell which of these were correctly restored and
> which I should delete?

Check disk size in Qube Manager, but probably the *1 set of VMs is valid.

-- 
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/781002b058b8f938394900a5eddf2a99.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: PS2 Mouse with adaptor

['awokd' via qubes-users]

On Tue, May 1, 2018 11:35 pm, x...@gmail.com wrote:
> Hi,
> I have the opposite problem. Most thin and light laptops do not have PS2,
> but have USB. I guess using PS2 mouse and keyboard with the PS2 to USB
> converter for my laptop won't help-it will be the same for Qubes as
> directly using USB mouse and keyboard. In this case, my only choice is to
> buy a laptop with PS2, I guess? Thank you

Most laptop's built in keyboards already use PS/2. Don't think you'll find
any with an external PS/2 port current enough to run 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/880bacf8fb180e563d482e9673503a68.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 4.0 'current' in dom0 but 'current-testing' in Fed26 based AppVM?

['awokd' via qubes-users]

On Tue, May 1, 2018 5:36 pm, john wrote:
> Hello,  when I look at that "boolean" in /etc/yum.repos.d/qubes-dom0.repo

This file only applies to updates for dom0, not templates. You need to
look inside each template's repo settings (and probably disable testing if
it's enabled). See Testing Repositories under
https://www.qubes-os.org/doc/software-update-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/19a9cd952ba14260ba93ba42c942c032.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q4.0 - rc.local doesn't run automatically in AppVMs

['awokd' via qubes-users]

On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
> Hello,
> I have a simple command in /rw/config/rc.local the sets the keyboard
> layout and shortcuts. I have made the script executable, and after
> searching the internet found there's a timing problem (the system runs the
> script too early), so I've added "sleep 5" to the beginning of the script.
>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
> manually from command line, yet when I start the VMs, there's no effect.
> This affects both debian-9 and fedora-26 AppVMs.
> Increasing the "sleep" time didn't help.

Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
/home/user/1", chmod 755 it, and it worked first try. Might want to add
something similar to yours to make sure it's firing, then troubleshoot
accordingly. Also check out
https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.

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

Re: [qubes-users] HCL - Clevo N850

['awokd' via qubes-users]

On Tue, May 1, 2018 3:14 pm, Brunoais wrote:

>
> GPU (GTX1050TiM) passthrough: Unfortunately, I was completely unable to
> setup a passthrough for this GPU. I've tried many other success stories.
> According to my research, I'd need nouveau working on DOM0 and qubes
> allowing OpenGL (or equivalent) because the contents of the qube would be
> shown on a window instead of a different screen and then I'd need to get
> bumblebee (or equivalent) to work on DOM0. (E.g. guide:
> https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28)

That's an interesting link. Looks like he is using QEMU and passing
through the discrete GPU to his VM, then getting output back over
RDP/RemoteFX. You should be able to pass the GPU through to a Qube by
attaching it, but I'm not sure anyone has been able to get it to work like
you describe.

-- 
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/c08980455d56dd097e815b4d2a342e40.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.