[qubes-users] Re: Network problems with Windows 7 HVM and AppVM

[wordswithnemo]

> I was able to gain network access by changing the network adapter IPv4 
> address to the same IP address set for the DNS, class A subnet mask, and no 
> gateway. I did receive a warning that this IP was in use. I have not however 
> seen any issues arise. I have internet access on my windows vm with tools 
> installed, as well as internet access on other vm's.

This worked for me as well, but it does bother me... I guess Windows thinks 
that it's taken that IP, but in reality is hasn't? It doesn't seem to affect 
anything outside of the Windows VM itself...

-- 
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/4eba9b18-14d7-4a6e-afaa-4a89c3e2ee32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN gateway using iptables and CLI scripts fails

[Gaijin]

On 2017-07-10 18:32, Chris Laprise wrote:
> On 07/10/2017 09:28 AM, Gaijin wrote:
>> On 2017-07-10 02:40, Chris Laprise wrote:
>>> On 07/09/2017 05:35 PM, Gaijin wrote:
 I've been trying to setup my VPN using the instructions here: Set up a
 ProxyVM as a VPN gateway using iptables and CLI scripts
 https://www.qubes-os.org/doc/vpn/

 I can get the VPN to work in the terminal using an openvpn config. After
 adding the DNS-handling script and firewall script the VPN fails to
 connect. I get several errors:

 write UDPv4: Operation not permitted (code=1)

 Then the socket is closed and the script tries to connect again. It will
 keep trying until I kill it.

 I've tried to recreate several ProxyVMs, copying and pasting the
 settings from the Qubes Docs. The result has been the same. I'm
 wondering if anyone else has run into this or how I might work around
 it.
>>>
>>> In the firewall script you can try changing the output policy from:
>>> iptables -P OUTPUT DROP
>>>
>>> to:
>>> iptables -P OUTPUT ACCEPT
>>>
>>> This will relax the rules a bit without negatively affecting the leak
>>> protection for connected appVMs.
>>>
>>> --
>>>
>>> Chris Laprise, tas...@openmailbox.org
>>> https://twitter.com/ttaskett
>>> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
>>
>> That got things moving. Thanks. It worked on the first try but I tried
>> rebooting a few times to try to get the LINK IS UP part of the routine
>> to work. I couldn't get that working and then the connection stopped
>> working altogether. I reverted to the original DROP, and the VPN still
>> worked.
>>
>> I just can't get the LINK IS UP/DOWN part to show. Running OpenVPN from
>> the CLI I can see that the 'up' seems to be being passed. The script is
>> executable, but it doesn't seem to be showing when it's run.
>>
> 
> The notifications use 'notify-send' so that needs to be working
> correctly in your chosen template.

Indeed, that doesn't seem to be working. I was using the Fedora minimal
template with the notification-daemon added. It also has libnotify
installed. However neither the template or AppVMs based on it show
anything from a notify-send "test". Is there anything else I could add
to this minimal template to get notifications 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/e8d542303e31aab3966ac8aec940f55d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows 7 HVM - suddenly no networking / Starting of Qubes Network Setup fails

[wordswithnemo]

On Tuesday, March 22, 2016 at 1:22:21 PM UTC-4, piitb...@gmail.com wrote:
> Hello,
> 
> after updating my windows 7 machine to the latest version, suddenly the 
> network conmectivity seems to be broken.
> If i try an ipconfig /release and ipconfig /renews I get the following Error 
> Message:
> 
> "RPC-Server is not available"
> 
> After some troubleshooting I found out that the "Qubes Network Setup" is not 
> started.
> When I start it manually via cmd I get an error message
> 
> c:\Program Files\Invisible Things Lab\Qubes Tools\bin\network-setup.exe 
> -service
> 
> Error:
> 
> [...] SvcMainLoop: StartServiceCtrlDispatcher failed with error 1063: 
> 
> Any ideas where to  continue from here?
> 
> As I have made a clone of the windows VM after installing, I retry the 
> setup/updates to figure out at which point the network connectivity gets 
> broken.
> 
> - Piit

I am having the same problem. Did you ever find a solution?

-- 
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/6f207011-daf2-4a1b-8a2b-0e5bb621b63c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does VPN needs its own firewall VM?

[Chris Laprise]

On 07/10/2017 03:15 PM, yreb-qusw wrote:

On 07/09/2017 11:56 PM, Chris Laprise wrote:

On 07/09/2017 11:48 PM, yreb-qusw wrote:

at the end of the VPN CLI setup it says :

==
If you want to be able to use the Qubes firewall, create a new
FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
Then, configure AppVMs to use your new FirewallVM as their NetVM.
==

is there some reason why I should or should not just use the existing
firewall, or should each of the VPN VMs each have it's own firewall VM
for some reason?



Qubes firewall creates DNS accept rules that target only the upstream
netVM. This has no side-effect until you start whitelisting in the
presence of a tunnel; then DNS queries become blocked by the "Deny
except" rule even if "Allow DNS" is selected.

One workaround is to use a firewall VM between the VPN VM and downstream
VMs, as suggested in doc. You need one for each VPN VM where you intend
to whitelist.

The existing sys-firewall normally interfaces to sys-net; In that
configuration it can't filter any traffic that gets routed through the
tunnel. But you can re-assign it to use a VPN VM instead of sys-net; The
only downside is if you have any VMs that need direct non-VPN access to
the net, in which case its still good to keep sys-firewall connected to
sys-net and use other proxyVMs as VPN firewalls.

-

A different workaround is to use 'sed' to update iptables with the
correct DNS entries, as in this script which can replace
"qubes-vpn-handler.sh":

https://github.com/tasket/Qubes-vpn-support/blob/new-1/rw/config/vpn/qubes-vpn-ns



...then add this to the end of "qubes-firewall-user-script":

/rw/config/vpn/qubes-vpn-ns fwupdate


Thanks, and if I DONT intend to white list anything, then is there any
reason to use the separate fw-VPNs  for each  VPN VM?


No reason to use separate fw-VPNs in that case.



As, I think this white listing fw  stuff has always been 'over my head'
.

And I use suspend function daily, and it's a bit hassle to get the VPNs
up and running again, even with the launcher workaround,  very often I
must use the launcher rc.local  multiple times , and ping to see if it
works, and quite often  they don't restart  properly


This has become a problem with newer openvpn versions: It appears to 
give up due to an internal error instead of reconnecting.


My VPN support project solves this by setting up a systemd service for 
the VPN; this forces openvpn to restart after it exits. It also makes it 
more manageable via systemctl start/stop/restart/status etc...


https://github.com/tasket/Qubes-vpn-support

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/e7e60589-53af-f2f1-5a1f-a69bdce4a9f5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes OS 4 pre RC1

['P R' via qubes-users]

Hello,

On Sun, Jul 09, 2017 at 12:42:35AM +0200, 'P R' via qubes-users wrote:

> When I reboot, Qubes Boot Menu comes up, but when I hit enter, after
> roughly 6 seconds a reboot happens.


No further help needed.
I downgraded to Qubes 3.2 again and will wait until the official release
candidate will come.

- PhR

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

Re: [qubes-users] Re: qubes-usb-proxy on Archlinux?

[Johannes Graumann]

On Thu, 2017-07-06 at 09:01 +0200, 'Olivier Médoc' via qubes-users
wrote:
> On 07/04/2017 08:40 AM, Johannes Graumann wrote:
> > Hello,
> > 
> > Can anyone give any pointers what needs to be done to have "qubes-
> > usb-
> > proxy" available in the ArchLinux template kindly provided by
> > Olivier
> > Medoc? Is there a howto on building this package anywhere?
> > 
> > I have the template running nicely following Olivier's recent hints
> > in
> > the group (https://groups.google.com/d/msg/qubes-users/5EJxdzgeRLY/
> > rI5d
> > otHTAQAJ), but would like to be able to pass usb device through to
> > it -
> > the Medoc-repo does not seem to contain the qubes-usb-proxy package
> > ...
> > 
> > Thank you for any hints.
> > 
> > Sincerely, Joh 
>  
> 
> Hello,
> 
> Are you talking about qubes-app-linux-usb-proxy repository [1] ?
> 
> I don't think somebody worked on this package for archlinux yet.
> 
> In order to implement it, you need to create a PKGBUILD and integrate
> it into qubes builder.
> 
> The simplest way is to copy on qubes-gui-common builder [2]. You need
> to:
> - Create inside qubes-app-linux-usb-proxy a archlinux directory
> - Create a PKGBUILD file into this directory and adapt it to build
> qubes-app-linux-usb-proxy
> - Edit Makefile.builder inside qubes-app-linux-usb-proxy and add the
> following line:
> 
> ARCH_BUILD_DIRS := archlinux
> 
> This should be sufficient to start building an archlinux package
> using 'make app-linux-usb-proxy-vm' inside qubes-builder.
> 
> The difficult part is then to test that everything work properly as
> it is often required to adapt code in order to get it working
> properly in archlinux.
> 
> 
> [1] https://github.com/QubesOS/qubes-app-linux-usb-proxy
> [2] https://github.com/QubesOS/qubes-gui-common

Hello,

Thank you for your pointers - I started exploring this:
- created a fedora 25- based development machine
- followed your docu at https://www.qubes-os.org/doc/building-archlinux
-template/
- cloned qubes-app-linux-usb-proxy as a git submodule into the qubes-
src directory

I cannot build that module though: "No rule to make target 'app-linux-
usb-proxy'" - what am I still misiing?

Joh

-- 
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/1499714330.4133.16.camel%40graumannschaft.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does VPN needs its own firewall VM?

[yreb-qusw]

On 07/09/2017 11:56 PM, Chris Laprise wrote:

On 07/09/2017 11:48 PM, yreb-qusw wrote:

at the end of the VPN CLI setup it says :

==
If you want to be able to use the Qubes firewall, create a new
FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
Then, configure AppVMs to use your new FirewallVM as their NetVM.
==

is there some reason why I should or should not just use the existing
firewall, or should each of the VPN VMs each have it's own firewall VM
for some reason?



Qubes firewall creates DNS accept rules that target only the upstream
netVM. This has no side-effect until you start whitelisting in the
presence of a tunnel; then DNS queries become blocked by the "Deny
except" rule even if "Allow DNS" is selected.

One workaround is to use a firewall VM between the VPN VM and downstream
VMs, as suggested in doc. You need one for each VPN VM where you intend
to whitelist.

The existing sys-firewall normally interfaces to sys-net; In that
configuration it can't filter any traffic that gets routed through the
tunnel. But you can re-assign it to use a VPN VM instead of sys-net; The
only downside is if you have any VMs that need direct non-VPN access to
the net, in which case its still good to keep sys-firewall connected to
sys-net and use other proxyVMs as VPN firewalls.

-

A different workaround is to use 'sed' to update iptables with the
correct DNS entries, as in this script which can replace
"qubes-vpn-handler.sh":

https://github.com/tasket/Qubes-vpn-support/blob/new-1/rw/config/vpn/qubes-vpn-ns


...then add this to the end of "qubes-firewall-user-script":

/rw/config/vpn/qubes-vpn-ns fwupdate

Thanks, and if I DONT intend to white list anything, then is there any 
reason to use the separate fw-VPNs  for each  VPN VM?


As, I think this white listing fw  stuff has always been 'over my head' 
.


And I use suspend function daily, and it's a bit hassle to get the VPNs 
up and running again, even with the launcher workaround,  very often I 
must use the launcher rc.local  multiple times , and ping to see if it 
works, and quite often  they don't restart  properly


So, unless there is a great reason , in my case, to do the extra 
separate VPN fw VMs , I'd rather skip 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/ab79946c-4824-e813-22f9-9a5898815243%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes silently ditches Librem

[Chris Laprise]

On 07/10/2017 10:56 AM, Unman wrote:

This simply isn't true - it's clear from the Purism statement that Librem
13v2 has not been entered for certification.

Since Qubes 4 is still at an early stage of development (not even RC1),
there is little prospect of ANY machine being certified for it at this
stage.
The fact that there are issues with Coreboot now is irrelevant - there
are issues with all sorts of things in 4 as it stands. But it was stated
that Qubes certified hardware should run on open source boot firmware,
and I dont think that has changed.

I dont think that Librem users have been "left in the lurch". It was
made clear that the Librem13 was not likely to be certified for Qubes 4.
This doesnt mean that the machine wont work with 4 - if you look at the
requirements page for 4, minimal are VT-x,VT-d SLAT.
A quick look at the HCL and the purism site confirms that the 13 has
CoreI5 6200U, and that CPU does have VT-x, VT-d and SLAT.
So in what sense does OP have grounds for feeling  "left in the lurch"?

unman



And I think its worth re-stating that Qubes wants a formal certification 
process (which Purism chose not to continue).


Qubes should be lauded for creating this process and standing by it; It 
guards against the erroneous perceptions people have about "PC hardware" 
being a uniform blank canvas for creating an OS.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/295976f4-a103-f66a-7526-25dfa56e121d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN gateway using iptables and CLI scripts fails

[Chris Laprise]

On 07/10/2017 09:28 AM, Gaijin wrote:

On 2017-07-10 02:40, Chris Laprise wrote:

On 07/09/2017 05:35 PM, Gaijin wrote:

I've been trying to setup my VPN using the instructions here: Set up a
ProxyVM as a VPN gateway using iptables and CLI scripts
https://www.qubes-os.org/doc/vpn/

I can get the VPN to work in the terminal using an openvpn config. After
adding the DNS-handling script and firewall script the VPN fails to
connect. I get several errors:

write UDPv4: Operation not permitted (code=1)

Then the socket is closed and the script tries to connect again. It will
keep trying until I kill it.

I've tried to recreate several ProxyVMs, copying and pasting the
settings from the Qubes Docs. The result has been the same. I'm
wondering if anyone else has run into this or how I might work around
it.


In the firewall script you can try changing the output policy from:
iptables -P OUTPUT DROP

to:
iptables -P OUTPUT ACCEPT

This will relax the rules a bit without negatively affecting the leak
protection for connected appVMs.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


That got things moving. Thanks. It worked on the first try but I tried
rebooting a few times to try to get the LINK IS UP part of the routine
to work. I couldn't get that working and then the connection stopped
working altogether. I reverted to the original DROP, and the VPN still
worked.

I just can't get the LINK IS UP/DOWN part to show. Running OpenVPN from
the CLI I can see that the 'up' seems to be being passed. The script is
executable, but it doesn't seem to be showing when it's run.



The notifications use 'notify-send' so that needs to be working 
correctly in your chosen template.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/cd4be3cd-890d-37a8-135e-f074d7f3b017%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Win7 Template?

['P R' via qubes-users]

Hello Henry,

Am 07.07.2017 3:42 nachm. schrieb :


I have 2 use cases for Windows.
1. Watch Netflix or Amazon etc. They reject the use of VPN and ask for a
lot of "information", which is basically ok for me.


I had the same request and solved it by setting up a dedicated multimedia
App VM based on the default Debian 8 template.
It can be used for Amazon Prime, Netflix, Spotify and to play DVDs.
To spare others thew work, I am writing a how-to, which didn't make it to
the main doc repositories  yet.
You can check it out here:
https://github.com/phrabe/qubes-doc/blob/patch-2/configuration/multimedia

If there are any questions which are not included in the docu, drop me an
email, I'll update the description with your feedback.

2. Banking. I have 2 banking applications that have multilevel
authentication one of which makes use of a usb token. Here I want a usb-vm
to connect these and only these usb devices. And I want a VPN connection
with a trusted server and on top of that a very restrictive (IP-range
based) Firewall.


Have you checked it it possible to use a Linux compatible Banking App?
If not you can of course use a Windows HVM to do your banking business.

Kind regards

- PhR

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

Re: [qubes-users] Qubes 3.2 UEFI install media

[Stephan Marwedel]

Thanks for this interesting hint. Following your detailed instructions I 
was able to create a bootable media that correctly boots on my Thinkpad 
in UEFI mode. However, when the kernel finished loading, an emergency 
shell appears and the following messages are displayed:


Starting Dracut Emergency Shell...

Warning: /dev/root does not exist

Entering emergency mode

It seems that the kernels loads OK, but is unable to find a root 
filesystem to mount. As I do not have Qubes currently installed on my 
machine, I am unsure about how to specify a root filesystem. The only 
valid root filesystem is the one on the installation media, but that 
should be found automatically. Or is it necessary to specify it manually?


Regards,
Stephan

On 06/26/2017 08:29 AM, Dave C wrote:

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/181c454b-acb3-f535-f470-c989d08e1d6c%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Win7 Template?

[henrydoblinger]

> Just had to do some digging, looks like both of them support Linux now :-)
Yes, thank you. But it's this and that with basically no security and no 
privacy.
hen


-- 
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/4251eac2-a8e5-4002-9525-1d39aa51c7fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Win7 Template?

[henrydoblinger]

> Yeah, it's harddisk consuming and I have to upgrade each cloned VM
> manually... 

Outch ...

-- 
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/fbfda56e-b638-4b3b-a03a-b918b5c6ca06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Chromium complains about certificate transparency

[Unman]

On Mon, Jul 10, 2017 at 04:50:34PM +0200, Rune Philosof wrote:
> On Mon, Jul 10, 2017 at 4:20 PM, Unman  wrote:
> 
> > On Mon, Jul 10, 2017 at 10:03:09AM +0200, Rune Philosof wrote:
> > > I get an error in Fedora 23 Chromium, that I don't get in Firefox or in
> > > Chromium on Debian 8.
> >
> > This is a well known bug in Chrome - fixed I think in 55, and therefore in
> > the Debian version.
> > You really shouldnt be using Fedora 23 any more - update your template
> > manually or install a new template:
> > in dom0 sudo qubes-dom0-update qubes-template-fedora-24
> >
> > unman
> >
> 
> Fedora 23 is default in Qubes 3.2.
> Fedora 24 isn't exactly recommended on
> https://www.qubes-os.org/doc/supported-versions/#templatevms.
> Although Fedora 23 is unsupported by Fedora. So I agree that Qubes should
> start informing users that they should upgrade to Fedora 24.

It's been extensively covered on this list and in News on the website.
Perhaps a statement could be added on the "Download" page as well.

> 
> Maybe your upgrade instruction 'sudo qubes-dom0-update
> qubes-template-fedora-24' should be included on
> https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/ with some
> explanation about why one would choose one method over the other.
> 

It's not an upgrade - as I said, it will install a new template. If
you have a heavily customised template, then you may prefer to upgrade it
in place using the instructions on the website.
I prefer to start afresh.
Entirely up to you.

In general, I think the team assumes that users will be handling the
security and configuration of their templates for themselves. There are
tools to help with this (by notifying when updates are available), but
they dont take responsibilty away from the user.


-- 
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/20170710151147.hvdireuay773vy5g%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes silently ditches Librem

[Unman]

On Sun, Jul 09, 2017 at 11:01:27AM +, 
qubesos-q7wo9g+UVklWk0Htik3J/w...@public.gmane.org wrote:
> bald...@tutanota.com:
> > For those of us who followed Qubes hardware recommendations and then bought 
> > or ordered shiny new Librem 13 laptops, you'll maybe not have noticed  that 
> > qubes has silently and sneakily withdrawn the recommendation leaving us all 
> > in the lurch.
> > Originally qubes was sold to as all as a reasonably secure OS - that 
> > security they said was built around the trusted ZEN platform. We now know 
> > that Zen has numerous security vulnerabilities
> > How can we trust Qubes judgement anymore? I certainly don't.
> > 
> > 
> > --
> > Securely sent with Tutanota. Claim your encrypted mailbox today!
> > https://tutanota.com
> > 
> 
> Despite the "spin" put out earlier today by Qubes's Andy Wong, the real
> reason Qubes ditched Librem 13, is because the Librem 13 v2 BIOS
> firmware is from Coreboot. Regretably, Qubes 4 will not yet boot
> properly from Coreboot [see github] - hence Librem 13 v2 is useless.

This simply isn't true - it's clear from the Purism statement that Librem
13v2 has not been entered for certification.

Since Qubes 4 is still at an early stage of development (not even RC1),
there is little prospect of ANY machine being certified for it at this
stage.
The fact that there are issues with Coreboot now is irrelevant - there
are issues with all sorts of things in 4 as it stands. But it was stated
that Qubes certified hardware should run on open source boot firmware,
and I dont think that has changed.

I dont think that Librem users have been "left in the lurch". It was
made clear that the Librem13 was not likely to be certified for Qubes 4.
This doesnt mean that the machine wont work with 4 - if you look at the
requirements page for 4, minimal are VT-x,VT-d SLAT.
A quick look at the HCL and the purism site confirms that the 13 has
CoreI5 6200U, and that CPU does have VT-x, VT-d and SLAT.
So in what sense does OP have grounds for feeling  "left in the lurch"? 

unman

-- 
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/20170710145626.lcuyypfr6mtpo2m4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Chromium complains about certificate transparency

[Rune Philosof]

On Mon, Jul 10, 2017 at 4:20 PM, Unman  wrote:

> On Mon, Jul 10, 2017 at 10:03:09AM +0200, Rune Philosof wrote:
> > I get an error in Fedora 23 Chromium, that I don't get in Firefox or in
> > Chromium on Debian 8.
>
> This is a well known bug in Chrome - fixed I think in 55, and therefore in
> the Debian version.
> You really shouldnt be using Fedora 23 any more - update your template
> manually or install a new template:
> in dom0 sudo qubes-dom0-update qubes-template-fedora-24
>
> unman
>

Fedora 23 is default in Qubes 3.2.
Fedora 24 isn't exactly recommended on
https://www.qubes-os.org/doc/supported-versions/#templatevms.
Although Fedora 23 is unsupported by Fedora. So I agree that Qubes should
start informing users that they should upgrade to Fedora 24.

Maybe your upgrade instruction 'sudo qubes-dom0-update
qubes-template-fedora-24' should be included on
https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/ with some
explanation about why one would choose one method over the other.

-- 
*Rune Schjellerup Philosof*

-- 
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/CAK%2BkuBRO14QuUP0pAjmQ0%2BRjqiswF7UoUABfzKLkQzTWPJGj-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Chromium complains about certificate transparency

[Unman]

On Mon, Jul 10, 2017 at 10:03:09AM +0200, Rune Philosof wrote:
> Hi
> 
> I get an error in Fedora 23 Chromium, that I don't get in Firefox or in
> Chromium on Debian 8.
> 
> I am wondering what is different in the setup of Qubes Fedora 23 that makes
> this error appear. I guess it is just a matter of using a different version
> of Chromium (54.0.2840.90 in Fedora and 57.0.2987.98 in Debian).
> Has any of you guys encountered the same problem, and what have you done to
> overcome it?
> 
> == The error is:
> 
> ```
> NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
> The server presented a certificate that was not publicly dislosed using the
> Certificate Transparence policy. This is a requirement for some
> certficates, to ensure that they are trustworthy and protect against
> attackers.
> ```
> 
> I have seen it on https://www.microsoft.com and https://getharvest.com.
> 

This is a well known bug in Chrome - fixed I think in 55, and therefore in the 
Debian version.
You really shouldnt be using Fedora 23 any more - update your template
manually or install a new template:
in dom0 sudo qubes-dom0-update qubes-template-fedora-24

unman

-- 
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/20170710142050.rkdl7ewpq6pxag7v%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4 Fails to Boot With Coreboot

[Noor Christensen]

On Mon, Jul 10, 2017 at 03:55:09AM -0400, 'Protonmij' via qubes-users wrote:
> I see the Seabios screen "booting from hard drive", this hangs for 10
> to 20 secs then goes the through the boot again endlessly

What payload did you choose in SeaBIOS menuconfig?

-- noor

|_|O|_|
|_|_|O|  Noor Christensen  
|O|O|O|  n...@fripost.org ~ 0x401DA1E0

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


signature.asc
Description: PGP signature

Re: [qubes-users] VPN gateway using iptables and CLI scripts fails

[Gaijin]

On 2017-07-10 02:40, Chris Laprise wrote:
> On 07/09/2017 05:35 PM, Gaijin wrote:
>> I've been trying to setup my VPN using the instructions here: Set up a
>> ProxyVM as a VPN gateway using iptables and CLI scripts
>> https://www.qubes-os.org/doc/vpn/
>>
>> I can get the VPN to work in the terminal using an openvpn config. After
>> adding the DNS-handling script and firewall script the VPN fails to
>> connect. I get several errors:
>>
>> write UDPv4: Operation not permitted (code=1)
>>
>> Then the socket is closed and the script tries to connect again. It will
>> keep trying until I kill it.
>>
>> I've tried to recreate several ProxyVMs, copying and pasting the
>> settings from the Qubes Docs. The result has been the same. I'm
>> wondering if anyone else has run into this or how I might work around
>> it.
> 
> In the firewall script you can try changing the output policy from:
> iptables -P OUTPUT DROP
> 
> to:
> iptables -P OUTPUT ACCEPT
> 
> This will relax the rules a bit without negatively affecting the leak
> protection for connected appVMs.
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

That got things moving. Thanks. It worked on the first try but I tried
rebooting a few times to try to get the LINK IS UP part of the routine
to work. I couldn't get that working and then the connection stopped
working altogether. I reverted to the original DROP, and the VPN still
worked.

I just can't get the LINK IS UP/DOWN part to show. Running OpenVPN from
the CLI I can see that the 'up' seems to be being passed. The script is
executable, but it doesn't seem to be showing when it's run.

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

Re: [qubes-users] Re: Qubes 4 Fails to Boot With Coreboot

[Noor Christensen]

On Sat, Jul 08, 2017 at 09:01:41AM -0700, Andrew Morgan wrote:
> On 07/07/2017 10:20 AM, 'Protonmij' via qubes-users wrote:
> > As recommended by Qubes, I have installed Coreboot on my X230 - which
> > successfully runs Debian, Tails etc. I've tried to run Qubes 3.2 but
> > although the Installer process works OK, Qubes refuses to boot [hangs].
> > From what I can gather, its a Zen issue that's preventing the boot.
> > I had hoped the issue would be resolved in Qubes 4. However, I've been
> > disappointed - I get exactly the same symptoms having downloaded the
> > trial version from
> > https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20170706.iso
> > 
> > Is this an isolated example or is there a wider problem with Coreboot
> > and Qubes?
> 
> Can you provide any more details about at what point in the boot process
> it hangs? It's hard to suggest anything to try based on the current
> description.

Just want to add that there are no "wider problem" with Qubes and
Coreboot, that I know of. I've been using this setup on my X220 without
hurdles for 6 months now.

Protonmij, 

* What payload are you using for Coreboot?
* Did you configure SeaBIOS and GRUB correctly?
* Did you flash a working GRUB config together with the firmware?

Also as Andrew mentioned it is very hard to diagnose anything without a
better description of what actually happens when you try to boot.

-- noor

|_|O|_|
|_|_|O|  Noor Christensen  
|O|O|O|  n...@fripost.org ~ 0x401DA1E0

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


signature.asc
Description: PGP signature

Re: [qubes-users] Why does VPN needs its own firewall VM?

[Chris Laprise]

On 07/09/2017 11:48 PM, yreb-qusw wrote:

at the end of the VPN CLI setup it says :

==
If you want to be able to use the Qubes firewall, create a new
FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
Then, configure AppVMs to use your new FirewallVM as their NetVM.
==

is there some reason why I should or should not just use the existing
firewall, or should each of the VPN VMs each have it's own firewall VM
for some reason?



Qubes firewall creates DNS accept rules that target only the upstream 
netVM. This has no side-effect until you start whitelisting in the 
presence of a tunnel; then DNS queries become blocked by the "Deny 
except" rule even if "Allow DNS" is selected.


One workaround is to use a firewall VM between the VPN VM and downstream 
VMs, as suggested in doc. You need one for each VPN VM where you intend 
to whitelist.


The existing sys-firewall normally interfaces to sys-net; In that 
configuration it can't filter any traffic that gets routed through the 
tunnel. But you can re-assign it to use a VPN VM instead of sys-net; The 
only downside is if you have any VMs that need direct non-VPN access to 
the net, in which case its still good to keep sys-firewall connected to 
sys-net and use other proxyVMs as VPN firewalls.


-

A different workaround is to use 'sed' to update iptables with the 
correct DNS entries, as in this script which can replace 
"qubes-vpn-handler.sh":


https://github.com/tasket/Qubes-vpn-support/blob/new-1/rw/config/vpn/qubes-vpn-ns

...then add this to the end of "qubes-firewall-user-script":

/rw/config/vpn/qubes-vpn-ns fwupdate

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/ee9bfdd5-d36b-1fde-1396-8df628397030%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why does VPN needs its own firewall VM?

[Noor Christensen]

On Sun, Jul 09, 2017 at 05:48:55PM -1000, yreb-qusw wrote:
> at the end of the VPN CLI setup it says :
> 
> ==
> If you want to be able to use the Qubes firewall, create a new FirewallVM
> (as a ProxyVM) and set it to use the VPN VM as its NetVM. Then, configure
> AppVMs to use your new FirewallVM as their NetVM.
> ==
> 
> is there some reason why I should or should not just use the existing
> firewall, or should each of the VPN VMs each have it's own firewall VM for
> some reason?

You can use this firewall to manage a policy of what should be allowed
through the VPN, and what should be blocked. To do this, you need the
firewall to be in front of the VPN, since the traffic after VPN will be
encrypted.

Additionally, if you want to use a non-VPN NetVM for any other AppVMs
while the VPN is active you probably don't that traffic to be mixed with
the VPN traffic. Especially not if that firewall is in front of the VPN
(unencrypted).

-- noor

|_|O|_|
|_|_|O|  Noor Christensen  
|O|O|O|  n...@fripost.org ~ 0x401DA1E0

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


signature.asc
Description: PGP signature

[qubes-users] Chromium complains about certificate transparency

[Rune Philosof]

Hi

I get an error in Fedora 23 Chromium, that I don't get in Firefox or in
Chromium on Debian 8.

I am wondering what is different in the setup of Qubes Fedora 23 that makes
this error appear. I guess it is just a matter of using a different version
of Chromium (54.0.2840.90 in Fedora and 57.0.2987.98 in Debian).
Has any of you guys encountered the same problem, and what have you done to
overcome it?

== The error is:

```
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
The server presented a certificate that was not publicly dislosed using the
Certificate Transparence policy. This is a requirement for some
certficates, to ensure that they are trustworthy and protect against
attackers.
```

I have seen it on https://www.microsoft.com and https://getharvest.com.


-- 
Venlig hilsen/Kind regards


*Rune Schjellerup Philosof*Softwareudvikler

Centic | Softwareudvikling og IT-konsulenter
Website: www.centic.dk

Egelundsvej 18
DK 5260 Odense S

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

Re: [qubes-users] Re: Qubes 4 Fails to Boot With Coreboot

['Protonmij' via qubes-users]

I see the Seabios screen "booting from hard drive", this hangs for 10 to 20 
secs then goes the through the boot again endlessly

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: [qubes-users] Re: Qubes 4 Fails to Boot With Coreboot
> Local Time: July 8, 2017 4:01 PM
> UTC Time: July 8, 2017 4:01 PM
> From: a...@openmailbox.org
> To: qubes-users@googlegroups.com
> On 07/07/2017 10:20 AM, "Protonmij" via qubes-users wrote:
>> As recommended by Qubes, I have installed Coreboot on my X230 - which
>> successfully runs Debian, Tails etc. I"ve tried to run Qubes 3.2 but
>> although the Installer process works OK, Qubes refuses to boot [hangs].
>> From what I can gather, its a Zen issue that"s preventing the boot.
>> I had hoped the issue would be resolved in Qubes 4. However, I"ve been
>> disappointed - I get exactly the same symptoms having downloaded the
>> trial version from
>> https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20170706.iso
>> 
>> Is this an isolated example or is there a wider problem with Coreboot
>> and Qubes?
>>
>>
>> Sent with ProtonMail  Secure Email.
>>
>> --
>> 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/MGEZpVt6pYIaYOxOT7U0emGldUOgkz521w70eU6KKu_oqgrtrhNn6YMBoLabZmKIGBYpnoxU-7nRlIjC82QZf6VP4FIKzAYo_Bu017uqq4Q%3D%40protonmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
> Can you provide any more details about at what point in the boot process
> it hangs? It"s hard to suggest anything to try based on the current
> description.
> Does it reach the Qubes loader-bar screen or do you just get a black
> screen while booting?
> I believe you can press ESC in the Qubes-logo booting process to show
> more detailed information, as well as removing the "quiet" entry in the
> kernel arguments on boot (you can do this by pressing "e" at the
> grub/bootup screen, press right arrow-key to see the rest of the arguments).
> Andrew Morgan
> --
> 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/ojqvl2%242fd%241%40blaine.gmane.org.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [qubes-users] Using and Mounting a Secondary Internal HD

['P R' via qubes-users]

Hello ,

I am also using 2 internal drives.
One for Qubes and one for windows.
I have just installed Qubes to the 2nd drive and set it up as default boot
drive in the BIOS.
If I need to boot into Windows I just hit F12 when starting, which brings
me to the boot menu.

If I understand you right, you want to use a 2nd drive as additional (!)
storage for Qubes, right?

I think what you want is to setup the partition as a LUKAS partition (to
have encryption) and then create a filesystem (extX) on top.

Maybe also setup LVM.

Another option could be to extend the LVM (if you are using LVM in Qubes)
with a 2nd drive (your M2 SSD).

In case you do not want to enter 2 credentials for LUKS you could maybe
store the decryption key on dom0.

Then adding the 2nd drive to LVM, create an own Volumegroup and migrate the
VMs.

- Philipp

 schrieb am Mo., 10. Juli 2017, 04:05:

> Hello Everyone,
>
> I'm working on getting a second m.2 internal SSD set up and partitioned
> for Qubes. I already have it formatted by fdisk /dev/sdb. Created a new
> extended partition.
>
> I added the /dev/sdb to fstab as an ext5. I'm getting  wrong fs type
> error. One fix I found was installing nfs-tools. But you can't seem to get
> that installed on Dom0.
>
> What is the default extension created in fdisk on qubes? I've tried ext,
> ext [1-5]. Parted -l only shows extended (whereas primary it shows ext4).
>
>
> What do I need to do to allow the creation and migration of Qubes VM's to
> the new disk?
>
> I'll be researching and working it on my end. But if any of you guys out
> there have an answer, or can point me in the right direction it would be
> greatly appreciated.
>
> --
> 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/172791d1-44b3-434b-8f2b-37d4a9dff604%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/CAM8xnvJvaLRYhyhOFzJKn%2BMK8AKsXGDJqJfRbrP6jdhib8jFYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.