Re: [qubes-users] Problems with Qubes 4 installation - Acer Aspire Laptop

2018-09-04 Thread lucas . sharinov 
Il giorno domenica 24 giugno 2018 02:59:11 UTC+2, lukz.e...@gmail.com ha 
scritto:
> > There is a somewhat drastic approach where you can use UEFI boot but still
> > disable Xen support for it. It's painful because you have to manually copy
> > files every time there's a Xen update, but it might help. See
> > https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda--disable-efi-runtime-services
> > if the other approach doesn't help.
> 
> Already tried this and didn't work, unfortunately.
> 
> I've disabled UEFI right now and the installation finally worked, so it 
> really was EFI messing up my installation. I'm going to wipe out my disk and 
> convert it to MBR, install Windows 10 all over again and then make a Windows 
> 10 / Qubes dualboot.

my laptop model is Model Acer aspire A515-51G-51V7;
I have the same problem, text->blackscreen->fan overwork.

and that poor soul have the same situation too 
-->https://github.com/QubesOS/qubes-issues/issues/3995<--

legacy installation work quite well but everything in esp was blowed up in my 
case (idk if i done something wrong with EFI shell or it's a qubes effect)

I await developments.

-- 
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/ecf49736-91ba-4276-90d0-13f440c1774e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: X1 Carbon again; Qubes DSDT override?

2018-09-04 Thread aqeel . akber 
On Wednesday, 1 August 2018 12:04:13 UTC+10, D. J. Bernstein  wrote:
> I finally decided to resort to patching the kernel. Suspend now seems to
> work normally in several tests on a Lenovo X1 ThinkPad Carbon 6th
> generation under Qubes R4.0. The idea of the patch is to do
> 
>if (sleep_state == ACPI_STATE_S3) {
>  *sleep_type_a = 5;
>  *sleep_type_b = 5;
>  return_ACPI_STATUS(AE_OK);
>}
> 
> near the top of acpi_get_sleep_type_data() (right after the "Validate
> parameters" part) in linux/drivers/acpi/acpica/hwxface.c. This has the
> same effect as the DSDT patches running around for this laptop: telling
> the kernel that the laptop supports S3 state (which the hardware _does_
> support---the starting problem is that the BIOS fails to announce this),
> and more specifically that S3 is hardware sleep type 5.
> 
> Of course, simply adding the lines above wouldn't be appropriate for
> non-laptops, or laptops where S3 is another hardware sleep type. The
> actual patch is instead triggered by
> 
>* DMI reporting this laptop, or
>* "acpi_force_s3=5" on the kernel command line (so users have a
>  relatively easy way to handle newer laptops with the same problem).
> 
> If this patch survives more tests and review (I'm not a Linux kernel
> expert) then it should be suitable for upstream adoption. I've attached
> the patch, and some notes on how I compiled a patched kernel for Qubes
> R4.0.
> 
> Beyond the patch, I've put
> 
>mem_sleep_default=deep
> 
> into my /boot/efi/EFI/qubes/xen.cfg on the kernel= line for the patched
> kernel, to tell the kernel to use S3 for suspend---otherwise it uses
> s2idle. The importance of S3 vs. s2idle for this laptop is different on
> Qubes from vanilla Linux: there are many reports of s2idle consuming
> more power than S3 on vanilla Linux, but Qubes seems unique in s2idle
> not waking up at all. I don't see a serious argument for s2idle when S3
> is supported, so I'm not sure why mem_sleep_default prefers s2idle over
> S3; even if there's a reason for this, maybe there would be general
> interest in a second patch that disables s2idle on this laptop.
> 
> ---Dan

Hi Dan,

I followed kernel-compile-notes.txt twice. The first time failed, the second 
time worked a charm with minor changes to the method. These are my notes on the 
experience.

Before I proceed, I note that the current version of the qubes-linux-kernel git 
on stable-4.14 is 4.14.67-1. This is the version of the kernel that I have 
compiled and applied your patch to.

The first (failed) attempted, I was on a fresh install of Qubes R4.0, kernel 
4.14.18-1. Compiling the kernel seemed to work, as did installing. Upon boot 
and unlocking my hard-drive the system never seemed to get anywhere on the 
loading. Upon pressing escape I noticed I was being spammed with a `dracut` 
error before eventually it dropped to an emergency shell. A more forward 
thinking me would have written down the error message. I simply reinstalled 
Qubes R4.0 fresh to start over.

The second (successful) attempt was after I had updated dom0. I was running 
kernel 4.14.57-2. I knew that this was an earlier version than the one I was 
going to compile so it wasn't going to be an issue (as you've described in your 
excellent notes). I doubt updating dom0 had anything to do with the success of 
this attempt, instead I did two things differently to your notes:

1. I ran the following command twice, superfluous I presume: 
   
   make verify-sources 

2. I ran the following command in dom0 after installing:
   
   dom0 $ sudo dracut -f "/boot/efi/EFI/qubes/initramfs-$version.img" "$version"

Paying special attention that the variable $version was expanded correctly. 

After adding the kernel parameter: 
   mem_sleep_default=deep
to the appropriate line in /boot/efi/EFI/qubes/xen.cfg - again as you've 
described.

To conclude, I can confirm that your patch works for version 4.14.67-1 of the 
qubes-linux-kernel too. That is, standby and wake from standby work as intended 
and the command:
   dmesg | grep ACPI | grep supports
yields:
   ACPI: (supports S0 S3 S5)
on my Carbon X1 Gen 6, i7 8550U.

However, perhaps unrelated, I have noticed the CPU doesn't turbo boost. Running 
the following command in dom0:
   xenpm get-cpufreq-states
shows that only 13 / 16 P-States are usable with P0, P1, P3 (the turbo states) 
clearly as the ones that aren't available.

Regards,
Aqeel

-- 
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/473a1a33-a7cb-45e3-8d2b-38fb7802bda0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to reset PCI device 0000:02.00.0

2018-09-04 Thread Jean-Philippe Ouellet 
On Tue, Sep 4, 2018 at 9:17 PM, Patrick  wrote:
> On Sunday, September 2, 2018 at 3:34:34 PM UTC-4, Jean-Philippe Ouellet wrote:
>> On Sun, Sep 2, 2018 at 10:12 AM, Patrick Bouldin
>>  wrote:
>> > On Sunday, September 2, 2018 at 10:10:55 AM UTC-4, Patrick Bouldin wrote:
>> >> Qubes 4.0 Error - "Start failed: Requested operation is not valid: PCI 
>> >> device :02:00.0 is in use by driver xenlight, domain sys-usb
>> >>
>> >> I don't know how to copy the log folder over and qubes doesn't have the 
>> >> wireless network, which I believe is related, but I've attached a picture 
>> >> of the log.
>> >>
>> >> This is a new Qubes install on a new Acer laptop Aspire A515-51-86AQ
>> >> Booting in legacy mode.
>> >>
>> >> I can get into the main desktop and get to Dom0 terminal, but can't 
>> >> launch any of the default domains.
>> >>
>> >> There is another thread on here with the same error. He ran:
>> >> $ qvm-pci attach --persistent --option permissive=true --option 
>> >> no-strict-reset=true sys-net dom0:00_XXX
>> >>
>> >> And it worked for him, but doesn't work for me, the response I get is 
>> >> "error : backend vm "dom0" doesn't expose device "00.XXX"
>>
>> The "XXX" in the PCI device should be filled in with your actual PCI device.
>>
>> >> So I wonder what "xenlight" is and it won't release what pci device?
>>
>> Just a library for interfacing with Xen. Unlikely to be the actual problem.
>>
>> >> Suggestions?
>> >>
>> >> Thanks,
>> >> Patrick
>> >
>> > Pics attached here.
>>
>> It would be the first time I've seen this, but it might perhaps be
>> conceivable that changing BIOS settings caused your device to show up
>> with a different BDF (essentially "PCI address") than when Qubes was
>> installed? Use `lspci` in dom0 to enumerate them.
>>
>> An easier way than doing this via the command line is to use the
>> Devices tab of the Qubes VM Settings GUI - remove all devices then add
>> the one which looks like your network device. You can also configure
>> no-strict-reset via the button at the bottom of the GUI, which is
>> sometimes necessary.
>
> Wow you really know this stuff. Thanks to your advice I was able to piece it 
> together. I confirmed as you said, then was able to start booting the VMs 
> based on using PVM and removing all the device elements. I'm sure I've got a 
> lot of experimenting to go but the basics are there with wireless.
>
> Thanks so much,
> Patrick

Glad it was helpful!

Also, in case you weren't already aware, VMs to which you wish to
assign PCI devices currently need to be in HVM mode (meaning: assisted
by a Qemu stub-domain for device-model emulation). This requirement
should be removed in the future, but there are Xen issues to work out
before we can fully ditch it and switch to PVH everywhere (meaning:
without Qemu and its associated attack surface and per-VM CPU/memory
overhead).

To check the virtualization mode:
[user@dom0 ~]$ qvm-prefs sys-net virt_mode
hvm

To reset the mode to default (which should automatically be HVM for
VMs with PCI devices and PVH otherwise):
[user@dom0 ~]$ qvm-prefs -D sys-net virt_mode

If you need to explicitly set the mode, you can do so (possibly
replacing "hvm" with "pvh" or the very-deprecated "pv"):
[user@dom0 ~]$ qvm-prefs sys-net virt_mode hvm

Cheers,
Jean-Philippe

-- 
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/CABQWM_BbW%2BSHLOOhEZ%3DpOB0yEcJj_cSpARSSZW_%2BrBQfKBfwpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: System freezes several times a day

2018-09-04 Thread Marcus Linsner 
On Monday, September 25, 2017 at 5:35:44 PM UTC+2, Jan Martin Krämer wrote:
> I am not sure if magic sysrq is enabled on qubes, I guess I would have to 
> test it while it is still working, but if it is, it also didn't work.

On dom0, looks like only the sync command(sysrq+s) of sysrq is enabled by 
default:

[ctor@dom0 ~]$ grep -nH sysrq -- /usr/lib/sysctl.d/* /etc/sysctl.d/*
/usr/lib/sysctl.d/50-default.conf:16:# Use kernel.sysrq = 1 to allow all keys.
/usr/lib/sysctl.d/50-default.conf:18:kernel.sysrq = 16
/etc/sysctl.d/95-sysrq.conf:1:kernel.sysrq=1

I actually had to enable all by creating /etc/sysctl.d/95-sysrq.conf (as seen 
above).

All info from here: 
https://www.kernel.org/doc/Documentation/admin-guide/sysrq.rst

   -  0 - disable sysrq completely
   -  1 - enable all functions of sysrq
   - >1 - bitmask of allowed sysrq functions (see below for detailed function
 description)::

  2 =   0x2 - enable control of console logging level
  4 =   0x4 - enable control of keyboard (SAK, unraw)
  8 =   0x8 - enable debugging dumps of processes etc.
 16 =  0x10 - enable sync command
 32 =  0x20 - enable remount read-only
 64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
128 =  0x80 - allow reboot/poweroff
256 = 0x100 - allow nicing of all RT tasks

-- 
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/d589d40a-805c-468c-acce-fbba707cbfa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to cache these disk reads done by the likes of [14.xvda-0]

2018-09-04 Thread Marcus Linsner 
Regarding OP, maybe I should look into this: 
https://www.kernel.org/doc/Documentation/filesystems/caching/fscache.txt
I'm unsure if it'll work for what I want, yet.

On Tuesday, August 28, 2018 at 10:35:23 PM UTC+2, Marcus Linsner wrote:
> Side question: how can I send eg. sysrq+m to a qube? (seems not possible 
> according to this 2016 post https://phabricator.whonix.org/T553#10438 ? )

Looks like it's possible, from dom0:

$ xl sysrq
'xl sysrq' requires at least 2 arguments.

Usage: xl [-vf] sysrq  

Send a sysrq to a domain.


Or, maybe not:
[   61.904917] xen:manage: sysrq_handler: Error -13 writing sysrq in 
control/sysrq

I tried on a disposable VM, 's' and 'h'.
$ sysctl kernel.sysrq
already reports =1

On first glance I found the code responsible here: 
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01068.html
if (sysrq_key != '\0') {
  err = xenbus_printf(xbt, "control", "sysrq", "%c", '\0');
...
I'm not sure if that looks right, I mean why isn't sysrq_key written instead of 
just a '\0' ? perhaps I'm misreading this. I'm not a programmer :D



-- 
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/6ed2a879-4ee1-42bc-914b-213eec9ac48a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to reset PCI device 0000:02.00.0

2018-09-04 Thread Patrick 
On Sunday, September 2, 2018 at 3:34:34 PM UTC-4, Jean-Philippe Ouellet wrote:
> On Sun, Sep 2, 2018 at 10:12 AM, Patrick Bouldin
>  wrote:
> > On Sunday, September 2, 2018 at 10:10:55 AM UTC-4, Patrick Bouldin wrote:
> >> Qubes 4.0 Error - "Start failed: Requested operation is not valid: PCI 
> >> device :02:00.0 is in use by driver xenlight, domain sys-usb
> >>
> >> I don't know how to copy the log folder over and qubes doesn't have the 
> >> wireless network, which I believe is related, but I've attached a picture 
> >> of the log.
> >>
> >> This is a new Qubes install on a new Acer laptop Aspire A515-51-86AQ
> >> Booting in legacy mode.
> >>
> >> I can get into the main desktop and get to Dom0 terminal, but can't launch 
> >> any of the default domains.
> >>
> >> There is another thread on here with the same error. He ran:
> >> $ qvm-pci attach --persistent --option permissive=true --option 
> >> no-strict-reset=true sys-net dom0:00_XXX
> >>
> >> And it worked for him, but doesn't work for me, the response I get is 
> >> "error : backend vm "dom0" doesn't expose device "00.XXX"
> 
> The "XXX" in the PCI device should be filled in with your actual PCI device.
> 
> >> So I wonder what "xenlight" is and it won't release what pci device?
> 
> Just a library for interfacing with Xen. Unlikely to be the actual problem.
> 
> >> Suggestions?
> >>
> >> Thanks,
> >> Patrick
> >
> > Pics attached here.
> 
> It would be the first time I've seen this, but it might perhaps be
> conceivable that changing BIOS settings caused your device to show up
> with a different BDF (essentially "PCI address") than when Qubes was
> installed? Use `lspci` in dom0 to enumerate them.
> 
> An easier way than doing this via the command line is to use the
> Devices tab of the Qubes VM Settings GUI - remove all devices then add
> the one which looks like your network device. You can also configure
> no-strict-reset via the button at the bottom of the GUI, which is
> sometimes necessary.

Wow you really know this stuff. Thanks to your advice I was able to piece it 
together. I confirmed as you said, then was able to start booting the VMs based 
on using PVM and removing all the device elements. I'm sure I've got a lot of 
experimenting to go but the basics are there with wireless.

Thanks so much,
Patrick

-- 
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/685cdfd7-bbb0-452f-ba5b-380e951157aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Strange sys-whonix-14 starts ; /etc/qubes-rpc/policy/qubes.UpdatesProxy

2018-09-04 Thread John S.Recdep 
Hello,

while upgrading to sys-whonix-14 many weeks ago, I was fighting to
maintain  my Fedora and Debian Template to keep using sys-net  not
sys-whonix-14

and sys-whonix-gw and -ws to use sys-whonix-14  , which are otherwise
working fine and I hesitate to mess with
/etc/qubes-rpc/policy/qubes.UpdatesProxy


However, once in a while I am concerned that sys-whonix-14 is starting
when I am NOT updating anything  eg in  dom0  today :

qvm-run -a fooappVM fooapplication   (for a fooappVM that wasn't open)
and sys-whonix-14  was shutdown

for some reason it started up

my  /etc/qubes-rpc/policy/qubes.UpdatesProxy ; looks like this :


--
# Default rule for all TemplateVMs - direct the connection to sys-net

$type:TemplateVM $default allow,target=sys-whonix-14

$tag:whonix-updatevm $default allow,target=sys-whonix-14
$tag:whonix-updatevm $anyvm deny



## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect

## Please use a single # to start your custom comments


# Default rule for all TemplateVMs - direct the connection to sys-net

$type:TemplateVM $default allow,target=sys-net





$anyvm $anyvm deny

--


It is in this order, because it works  and a bit fearful to change  it
, but  curious   what others looks like  and maybe it is obvious  what
the problem is ?


-- 
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/eb13f022-47e1-0f88-fe04-b62dc8bcc175%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't create Linux HVM

2018-09-04 Thread pc revival 
On Tuesday, September 4, 2018 at 8:45:10 AM UTC-4, steve.coleman wrote:
> On 09/03/18 22:01, pc revival wrote:
> > Hello all. I have been trying to install a version of Ubuntu Linux called 
> > Buscador and can't get past the partitioning utility. I boot the live iso 
> > and everything works fine but when I boot the installer I go through the 
> > user set up screen fine but the partition utility never finds the 
> > partitions. Even if I boot the live ISO in an established Linux install it 
> > still does not find the partitions. Any ideas would be appreciated.
> 
> I just had the same kind of issue when creating an HVM for a ReactOS 
> (windows like OS) install. Same issue, in that the new OS installer sees 
> no disk space in which to install.
> 
> When I asked in the ReactOS forum, with provided logs of the boot 
> process, they told me that the qemu "mptsas1068" controller was not 
> recognized by their OS. So the "qemu -device" option sent by Qubes would 
> need to changed to something else that the drivers in the yet to be 
> installed OS would understand natively.
> 
> Unfortunately I have not yet found where this option can be changed. I 
> saw a qubes-users discussion a while back where this option was changed 
> in Qubes, but I still need to go back find out what they patched to 
> modify it to the current setting.
> 
> If this is a general problem with HVM's, I think this should be a 
> qvm-prefs setting per VM, at least wherever qemu is required. I'm 
> certainly no expert, just thinking out loud since I didn't get an answer 
> to my own question yet. I think the two problems may be related.
> 
> > Thanks in advance
> >

Thanks for the input steve.coleman yours is the only sensible idea I have 
received. I have installed HVMs for Windows 10, Linux Mint 18.3 and Parrot OS 
4.0 with no other issues. This is the only issue I have had. Thanks again.

-- 
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/5ba03c24-a9ca-4144-b600-e56bcf11f8dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: cpu

2018-09-04 Thread Roy Bernat 
On Monday, 3 September 2018 13:13:23 UTC-4, Foppe de Haan  wrote:
> I'm afraid so, yeah.

Thank you for your answer . 

i am already 1.5 year with qubes and always hope to better performance . 

i dont know how  i will move to other system but the performance are very bad 

and making my work not so easy .   

Roy

-- 
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/000d2465-b737-4df6-8e20-5715a25d1967%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] setting up vpn issue

2018-09-04 Thread code9n 
Hi Nick,

  In case it's any use to you;

  I had a couple of vpns working on Q3.2 until about a week ago (moved to 4.0) 
and one of them was Expressvpn.
 
  What I did to set it up: 

   Make a clone of my up to date fedora template ( or use Debian or whatever 
you like).

  Allow network access in that template.

  Then put firefox in the template's applications (and set up it's privacy to 
your liking) - you need only go to the Expressvpn's https site - and you're 
going to trust them anyway.  (Plus it's a clone template.) 

 Install Expressvpn following their instructions for the linux (appropriate 
Fedora package) into that template from their website.

  Then follow the easy instructions (Expressvpn site) and activate on the 
template.

 

  If you want to you can now connect to the vpn - expressvpn connect - in the 
command line of the template and go to (for example), 
https://www.dnsleaktest.com/ in your firefox to test it's working ok.

 .

  Close network access again on the template.

  Then make a proxy vm based on that new clone template as described in the 
qubes documentation:  https://www.qubes-os.org/doc/vpn/

  Set it with sys-firewall as it's netvm.

  Then connect to Expressvpn in your new proxy (I called mine sys-vpn-exp) - to 
get a list of commands - expressvpn help -   in the command line.

  Set any appvms you want to go through that new proxy vpn (sys-vpn-exp) to 
have it as their netvm.

  Then open firefox in one of the appvms that go through your new sys-vpn-exp 
proxy and to test it - personally I mostly use:   https://www.dnsleaktest.com/  
or Expressvpn have their own dns leak test facility.  Where ever.

  .

  The Expressvpn site has instructions for qubes but they want you to set up in 
the sys-net vm which means everything goes through them.  I do it the above way 
because it's easy and you can use other vpn providers as well for some of your 
other appvms if you want to.

  It works fine.

  Or you could use:  https://github.com/tasket/Qubes-vpn-support  as suggested 
above - I use that for one of my vpns in Qubes 4 and it's excellent but it's 
more involved.  Also harder to change which server / country you want to come 
out of.

  cheers,

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

[qubes-users] Qubes V4 and Windows7-hardware

2018-09-04 Thread josefh.maier via qubes-users 
Hello forum.
Actual Intel CPU's do not anymore support Windows 7 and Qubes 4 does
require modern hardware...
Question:
Are Windows 7 based AppVMs supported on "Windows10-only" hardware?
Thank's for your feedback!

Joe

-- 
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/20180904152007.8847AE019C%40smtp.hushmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Redirection of DISP network traffic

2018-09-04 Thread drogo 
Is there an easy way to re-direct network traffic from disp VMs? I've already 
got a separate router for some outbound traffic, and would like to send traffic 
to that as a default gateway rather than my usual default gw.

Doing a quick look over the config (of sys-net), it seems like I might need a 
whole new sys-net serviceVM (and associated interface). Or is there an easier 
way?

Thanks.

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

Re: [qubes-users] Re: QSB #43: L1 Terminal Fault speculative side channel (XSA-273)

2018-09-04 Thread Adam Robinson 
>
> Is this something that can eventually be resolved, allowing safe
> re-enabling of hyperthreading? or is that even known yet?
>

I haven't been able to find many details on this for the Linux and Xen
communities.  Microsoft has a mitigation that allows for HyperThreading to
remain enabled with Hyper-V which they have named HyperClear
.
Additionally, I know VMware recommends leaving HyperThreading enabled in
the BIOS so that if a safe way to utilize HyperThreading on ESXi is
implemented in the future you don't have to reconfigure your BIOS again.

Thanks,
Adam Robinson
Virtualization and Cloud Infrastructure
Information and Technology Services
University of Michigan

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

Re: [qubes-users] Can't create Linux HVM

2018-09-04 Thread Steve Coleman 

On 09/03/18 22:01, pc revival wrote:

Hello all. I have been trying to install a version of Ubuntu Linux called 
Buscador and can't get past the partitioning utility. I boot the live iso and 
everything works fine but when I boot the installer I go through the user set 
up screen fine but the partition utility never finds the partitions. Even if I 
boot the live ISO in an established Linux install it still does not find the 
partitions. Any ideas would be appreciated.


I just had the same kind of issue when creating an HVM for a ReactOS 
(windows like OS) install. Same issue, in that the new OS installer sees 
no disk space in which to install.


When I asked in the ReactOS forum, with provided logs of the boot 
process, they told me that the qemu "mptsas1068" controller was not 
recognized by their OS. So the "qemu -device" option sent by Qubes would 
need to changed to something else that the drivers in the yet to be 
installed OS would understand natively.


Unfortunately I have not yet found where this option can be changed. I 
saw a qubes-users discussion a while back where this option was changed 
in Qubes, but I still need to go back find out what they patched to 
modify it to the current setting.


If this is a general problem with HVM's, I think this should be a 
qvm-prefs setting per VM, at least wherever qemu is required. I'm 
certainly no expert, just thinking out loud since I didn't get an answer 
to my own question yet. I think the two problems may be related.



Thanks in advance



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

Re: [qubes-users] Can I set an unencrypted external HD as /home folder for a VM

2018-09-04 Thread unman 
On Mon, Sep 03, 2018 at 03:03:25PM -0700, Guy Frank wrote:
> On Friday, August 31, 2018 at 6:31:58 PM UTC-4, Chris Laprise wrote:
> > On 08/31/2018 01:40 PM, Guy Frank wrote:
> > > On Friday, August 31, 2018 at 12:17:54 PM UTC-5, js...@bitmessage.ch 
> > > wrote:
> > >> Guy Frank:
> > >>> One question I had is whether there is any way to set an unencrypted 
> > >>> (or encrypted?) external HD as the /home folder for a VM?
> > >>>
> > >>> Guy
> > >>
> > >> Hi Guy,
> > >>
> > >> I'm not sure about setting it as /home but i think it's possible. But
> > >> it's easy to attach an external HD to a vm and save your files to it.
> > >>
> > >> https://www.qubes-os.org/doc/usb/
> > >>
> > >> Also it's pretty easy to encrypt it with luks for security, it just
> > >> takes a little longer each time.
> > >>
> > >> -- 
> > >> Jackie
> > > 
> > > Thanks Jackie for your reply!
> > > 
> > > I remember it being fairly easy to attach USB devices w/ the right clicks 
> > > here & there.  So, yes, I'd have access to the files on my external HD.
> > > 
> > > But it would be more convenient if I could get Qubes to mount the home 
> > > folder on the HD as the Home folder for the given virtual machine.  I 
> > > imagine that's trickier and was wondering if there's a way to do it?
> > > 
> > > Maybe use a script to mount the attached USB drive home (/home/guyuser) 
> > > over the Qubes home directory?  But then, if that's possible, some of the 
> > > setup in the Qubes home directory might get missed.
> > > 
> > 
> > The key to using it as /home would be to setup a new storage pool to 
> > hold that VM. Unfortunately the docs could use a rewrite:
> > 
> > https://www.qubes-os.org/doc/storage-pools/
> > 
> > The relevant commands are 'qvm-pool --add' and 'qvm-create --pool'.
> > 
> > -- 
> > 
> > Chris Laprise, tas...@posteo.net
> > https://github.com/tasket
> > https://twitter.com/ttaskett
> > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> 
> Hi Chris:  Thanks! This looks like a step in the right direction, but I have 
> some questions.  I'm guessing the commands will tell Qubes to treat my  
> external HD as a potential place to store a VM.  But that seems like it 
> wouldn't take the existing home directory on the external HD as the VM home 
> directory but instead store a VM file containing the VM's home directory 
> structure on the disk.  That file would, I imagine, be difficult to access on 
> the Kubuntu I have running on my home desktop and wouldn't contain the files 
> currently on my external hard disk, which mirror my Kubuntu files.  
> 
> Is that the case and is there any fix?  Am beginning to think the only way to 
> work this is to simply attach my external HD as a USB device and give up on 
> trying to make the files my home directory.
> 
> Guy
> 

If it were not USB it would be straightforward.

It occurs to me that you may be able to change the configuration, (see
previous thread on assigning SATA devices) to attach the USB device on
boot, and have fstab configured to mount the newly exposed device in
the qube as /home or a directory in /home.

I haven't tried this but I'm assuming it would be possible, and would fit
your needs.
I'll have a quick poke at this in the morning, and see if there's any
mileage in the thought.

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

Re: [qubes-users] Re: Unable to reset PCI device 0000:02.00.0

2018-09-04 Thread unman 
On Mon, Sep 03, 2018 at 08:06:01AM -0700, Patrick wrote:
> On Monday, September 3, 2018 at 10:31:50 AM UTC-4, unman wrote:
> > On Sun, Sep 02, 2018 at 03:56:46PM -0700, Patrick wrote:
> > > On Sunday, September 2, 2018 at 3:34:34 PM UTC-4, Jean-Philippe Ouellet 
> > > wrote:
> > > > On Sun, Sep 2, 2018 at 10:12 AM, Patrick Bouldin
> > > >  wrote:
> > > > > On Sunday, September 2, 2018 at 10:10:55 AM UTC-4, Patrick Bouldin 
> > > > > wrote:
> > > > >> Qubes 4.0 Error - "Start failed: Requested operation is not valid: 
> > > > >> PCI device :02:00.0 is in use by driver xenlight, domain sys-usb
> > > > >>
> > > > >> I don't know how to copy the log folder over and qubes doesn't have 
> > > > >> the wireless network, which I believe is related, but I've attached 
> > > > >> a picture of the log.
> > > > >>
> > > > >> This is a new Qubes install on a new Acer laptop Aspire A515-51-86AQ
> > > > >> Booting in legacy mode.
> > > > >>
> > > > >> I can get into the main desktop and get to Dom0 terminal, but can't 
> > > > >> launch any of the default domains.
> > > > >>
> > > > >> There is another thread on here with the same error. He ran:
> > > > >> $ qvm-pci attach --persistent --option permissive=true --option 
> > > > >> no-strict-reset=true sys-net dom0:00_XXX
> > > > >>
> > > > >> And it worked for him, but doesn't work for me, the response I get 
> > > > >> is "error : backend vm "dom0" doesn't expose device "00.XXX"
> > > > 
> > > > The "XXX" in the PCI device should be filled in with your actual PCI 
> > > > device.
> > > > 
> > > > >> So I wonder what "xenlight" is and it won't release what pci device?
> > > > 
> > > > Just a library for interfacing with Xen. Unlikely to be the actual 
> > > > problem.
> > > > 
> > > > >> Suggestions?
> > > > >>
> > > > >> Thanks,
> > > > >> Patrick
> > > > >
> > > > > Pics attached here.
> > > > 
> > > > It would be the first time I've seen this, but it might perhaps be
> > > > conceivable that changing BIOS settings caused your device to show up
> > > > with a different BDF (essentially "PCI address") than when Qubes was
> > > > installed? Use `lspci` in dom0 to enumerate them.
> > > > 
> > > > An easier way than doing this via the command line is to use the
> > > > Devices tab of the Qubes VM Settings GUI - remove all devices then add
> > > > the one which looks like your network device. You can also configure
> > > > no-strict-reset via the button at the bottom of the GUI, which is
> > > > sometimes necessary.
> > > 
> > > Thanks, I went to the work vm for example, and all of the devices were on 
> > > the left side, nothing on the right, then I selected the wifi device and 
> > > the response was "you've enabled dynamic memory balancing, some devices 
> > > might not work!"
> > > 
> > > and, it won't let me apply that change, saying "Can't attach pci device 
> > > to a VM in pvh mode"
> > > 
> > > Then I tried to issue your suggestion "$ qvm-pci attach --persistent 
> > > --option permissive=true --option no-strict-reset=true sys-net 
> > > dom02:00.0"which is my wireless device and the error response "no 
> > > backend vm '02'"
> > > 
> > > 
> > > I'm wondering if this is the right way to go or maybe just try a 
> > > different installation route?
> > > 
> > > Thanks,
> > > Patrick
> > > 
> > 
> > There's a typo in your command:
> > you have dom02:00.0 and the command should be dom0:02
> > 
> > The two messages you received can be fixed in the Qube settings window.
> > You can change the VM mode on the Advanced pane - select HVM.
> > There's a checkbox for memory balancing on the same pane , if that's
> > needed. I habitually turn this off and set the memory/maxmem settings
> > low. ymmv
> 
> Thanks, I'm feeling outgunned on this one. I really have no idea about what 
> is truly going on - what's the root cause issue and why? What device is not 
> resetting and why that matters, etc. etc.
> 
> Just to be clear. While I'm able to get into the Qubes desktop, and can get 
> to dom0 terminal, none of the pre-configured VMs are coming up. If I simply 
> do a start from the Dom0 qubes manager, on any VM, the same error comes up:
> 
> "Unable to reset PCI device :01:00.1: Internal error: active :01:00.0 
> devices on bus with :01:00.1 not doing bus reset."
> 
> The log says:
> "unable to release device /dev/loop0: No such device or address"
> 
> I have tried all your suggestions (HVM/mem checkbox/low mem), no change in 
> result.
> 
> Based on this, what is going on in the first place? I feel if I can 
> understand the root of it I stand a chance in solving. 
> 
> Thanks,
> 
> Patrick
> 

I'm as confused as you - the device you are referencing now is not the
one you were concerned with earlier. Are you trying something new?
Also, I don't understand why you were trying to attach a device to "work"

Almost certainly the problem is with starting sys-net. That's why your
qubes wont start. You could confirm this by changing the "Networking" setting
to

Re: [qubes-users] systemd replacement for dom0

2018-09-04 Thread Marcus Linsner 
On Monday, September 3, 2018 at 1:45:27 PM UTC+2, Rusty Bird wrote:

> Marcus Linsner:
> > I'm mainly asking because I fail to make certain services stop in a
> > certain order at reboot/shutdown. Hmm, maybe I should focus on
> > starting them in a certain order? then maybe shutdown will do it in
> > reverse order [...]
> 
> Yes, that's how systemd does it. See Before= and After= in the
> systemd.unit manpage.

I know it seems simple, and yet in practice it doesn't work (or rather, 
sometimes it works, mostly it doesn't). 
For example: In dom0, I added `udisks2.service` on the `After=` line of 
`qubes-core.service` (did do the required `sudo systemctl daemon-reload` - 
looks like `sudo` isn't required, thanks to passwordless sudo I suppose) then I 
the next reboot (from xfce Menu->Logout->Restart) seems to have worked in the 
sense that there were no more timeouts reported on the log, then the next 
reboot the timeouts were back. Seen here: 
https://gist.github.com/constantoverride/61207ebf622263d25fb1e5b1f11d0148/9443ef0babe29b32622dd0f17a2435a9e0f1df92#gistcomment-2696596

Another example, instead of `udisks2.service` I added `dev-block-253:0.device` 
on the `After=` line of `qubes-core.service`, then the next TWO reboots were 
fine!(aka no `timed out` or `timeout` reported, but on the third reboot the 
timeouts were back, without me changing anything.
All of that seen here: 
https://gist.github.com/constantoverride/61207ebf622263d25fb1e5b1f11d0148/9443ef0babe29b32622dd0f17a2435a9e0f1df92#gistcomment-2696607
(the contents of `qubes-core.service` can be seen one or two pages above the 
linked comment; the actual log of the reboots are linked to in the comment)

Maybe it's a systemd bug? but since dom0 is stuck with Fedora 25 (as opposed to 
Fedora 28), then I cannot get it upgraded, I believe.

Another example, I even tried replacing `dev-block-253:0.device` with 
`system.device` (later with `system.device systemd.device`) but there were no 
reboots (so far) that didn't time out.

Anyway, the point is: I don't know how to make use of systemd so that this 
stalling doesn't happen on reboot/shutdown 
https://github.com/QubesOS/qubes-issues/issues/1581#issuecomment-417968474


:)

-- 
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/09a1b66f-1b35-4ee0-9e27-acacda95fb31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.