[qubes-users] Re: Installing Win7 on a Dell

2018-02-18 Thread Yuraeitha
On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote:
> On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
> > On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> > > Hi,
> > > 
> > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. 
> > >  I have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
> > > installed Qubes I used the Dell recovery tool to create a recovery usb 
> > > disk for Win7 to re-install the OS but I'm not sure if this is usable to 
> > > install with Qubes.
> > > 
> > > I tried following the instructions on the Qubes website by creating a new 
> > > Qube without a template but I could not change it from PVM to HVM.  Then 
> > > when I tried booting from the USB recovery disk it would load up a 
> > > terminal and then exit after 10 seconds.
> > > 
> > > When I try to boot the recovery USB disk from the main BIOS it boots up 
> > > fine.  Does anyone have any tips for installing Win7 in Qubes 4?
> > > 
> > > Thanks,
> > > 
> > > Glen
> > 
> > Hi,
> > 
> > Check out these two issues:
> > Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
> > Installing Qubes Windows Tools: 
> > https://github.com/QubesOS/qubes-issues/issues/3585
> > 
> > The two problems you describe in the post seem to be the following:
> > 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
> > 2. Make sure you set the video-model to cirrus for install.
> > 
> > Best,
> > Daniel
> 
> Hi,
> 
> Thanks for the tips Daniel.  I'm stuck at not being able to boot from the usb 
> disk.  I am doing:
> 
> ```
> qvm-create --class StandaloneVM --label red win7new
> qvm-prefs win7new virt_mode hvm
> qvm-prefs win7new memory 4000
> qvm-prefs win7new maxmem 4000
> qvm-prefs win7new kernel ''
> qvm-volume extend win7new:root 25g
> qvm-prefs win7new debug True
> qvm-features win7new video-model cirrus
> 
> # Then attach usb drive to untrusted, but all of these fail to boot:
> 
> qvm-start --hddisk untrusted:sda win7new
> qvm-start --hddisk untrusted:sda1 win7new
> qvm-start --hddisk untrusted:/dev/sda win7new
> qvm-start --hddisk untrusted:/dev/sda1 win7new
> ```
> 
> I'm not sure whether to use the whole drive (no name) or the first partition 
> (named DELLRESTORE)...but I tried both.
> 
> I get the error message in the win7new terminal:
> 
> ```
> SeaBIOS (version ...)
> Machine UUID ...
> Booting from Hard Disk...
> Boot failed: not a bootable disk
> 
> Booting from Floppy...
> Boot failed: could not read the boot disk
> 
> No bootable device.
> ```
> 
> So it seems that it doesn't recognize the USB drive as bootable even though I 
> can boot it from the main BIOS (in legacy mode).  
> 
> Any help would be appreciated.
> 
> Glen

First, welcome to the Qubes community! :)

A few things first, starting to use Qubes can be a bit overwhelming, but you'll 
get the hang of it over time if you keep using it. For starters, look here in 
the command you use "untrusted:sda" which is something Qubes exclusive and you 
therefore had no chance knowing this. Untrusted, is a word that needs replacing 
for whichever untrusted AppVM you're using to hold your USB or SATA 
controllers. It's called untrusted because dom0 is trusted, and you need to use 
an less untrusted domain that doesn't compromise your more trusted domain, 
dom0. This is a bit tricky for new users to catch on, on, as it's ambiguity for 
new users, at best. To solve this, then you first need to figure out where your 
controller is located. If you have no sys-usb or similar, then it's likely 
still in dom0. It's insecure to keep this in the secure dom0 domain, but mostly 
you should be fine for some time yet if you're not a high target profile, and 
never leave your computer unattended in public or near people you don't trust 
with your life. Still, having it in dom0 is still more secure than not using 
Qubes. Just keep in mind you eventually want to migrate away from using dom0 
for anything, but it's not always easy just yet due to some fixes and hardwares 
require you still manually manage dom0 from time to time, so it's not yet 
entirely a users responsibility, as there are still times when you need to use 
dom0.

So if your USB or SATA controllers are in dom0 (Your SATA controllers will be 
if you did not move them yourself, and USB controllers depend on your hardware, 
the installer might or might not have done it automatically). If you don't have 
a sys-usb VM, then it's probably still in dom0. 

I don't know your current knowledge on Linux, so I'll take the liberty to add 
more details just in case.

In conclusion from the above, instead of untrusted, it should look like this 
dom0:sda for dom0, and sys-usb:sda for sys-usb, whereever that controller is 
located.
further, sda may look like sdb, sdc, or if adding partitins, like sdb2 or sdf4.
It's kind of like C:/ in windows, followed by d:/ for your DVD drive, on most 
machines. Instead it's "sd" 

[qubes-users] Re: Installing Win7 on a Dell

2018-02-18 Thread Glen H
On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
> On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> > Hi,
> > 
> > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4.  
> > I have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
> > installed Qubes I used the Dell recovery tool to create a recovery usb disk 
> > for Win7 to re-install the OS but I'm not sure if this is usable to install 
> > with Qubes.
> > 
> > I tried following the instructions on the Qubes website by creating a new 
> > Qube without a template but I could not change it from PVM to HVM.  Then 
> > when I tried booting from the USB recovery disk it would load up a terminal 
> > and then exit after 10 seconds.
> > 
> > When I try to boot the recovery USB disk from the main BIOS it boots up 
> > fine.  Does anyone have any tips for installing Win7 in Qubes 4?
> > 
> > Thanks,
> > 
> > Glen
> 
> Hi,
> 
> Check out these two issues:
> Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
> Installing Qubes Windows Tools: 
> https://github.com/QubesOS/qubes-issues/issues/3585
> 
> The two problems you describe in the post seem to be the following:
> 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
> 2. Make sure you set the video-model to cirrus for install.
> 
> Best,
> Daniel

Hi,

Thanks for the tips Daniel.  I'm stuck at not being able to boot from the usb 
disk.  I am doing:

```
qvm-create --class StandaloneVM --label red win7new
qvm-prefs win7new virt_mode hvm
qvm-prefs win7new memory 4000
qvm-prefs win7new maxmem 4000
qvm-prefs win7new kernel ''
qvm-volume extend win7new:root 25g
qvm-prefs win7new debug True
qvm-features win7new video-model cirrus

# Then attach usb drive to untrusted, but all of these fail to boot:

qvm-start --hddisk untrusted:sda win7new
qvm-start --hddisk untrusted:sda1 win7new
qvm-start --hddisk untrusted:/dev/sda win7new
qvm-start --hddisk untrusted:/dev/sda1 win7new
```

I'm not sure whether to use the whole drive (no name) or the first partition 
(named DELLRESTORE)...but I tried both.

I get the error message in the win7new terminal:

```
SeaBIOS (version ...)
Machine UUID ...
Booting from Hard Disk...
Boot failed: not a bootable disk

Booting from Floppy...
Boot failed: could not read the boot disk

No bootable device.
```

So it seems that it doesn't recognize the USB drive as bootable even though I 
can boot it from the main BIOS (in legacy mode).  

Any help would be appreciated.

Glen

-- 
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/582b151d-3198-4c85-93bf-4608075505d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 11:00:35 PM UTC+1, [799] wrote:
> -- 
> Qubes 4rc3 > Lenovo X230 + Lenovo W540
> 
> Gesendet von ProtonMail mobile
> 
> 
> 
> 
>  Original-Nachricht 
> An 18. Feb. 2018, 22:25, Yuraeitha wrote:
> 
> On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: 
> > Hello, 
> > 
> > having the idea of a qvm-screenshot-to-clipboard script I was eager to try 
> > writting a script. 
> > The solution I had in mind could work but I am struggling with a small 
> > issue and would like to get some help. 
> > The script takes a screenshot in dom0, store it to a file and qvm-copy the 
> > file to the target appvm (one and only command line argument for the 
> > script). 
> > Then within the AppVM it is using xclip to copy the graphic to clipboard 
> > and removes all temporary files in the AppVM and dom0 
> > All pieces are working, except the xclip command when launced from dom0. 
> > 
> > When I launch the command within the AppVM it is working. 
> > But I need to start the xclip command from an external script and when I do 
> > so, the same command is not working. 
> > It seems that I am missing something when using xclip via script which is 
> > run in a new terminal session (from dom0 but also within the App) 
> > 
> > Any ideas how to fix this? 
> > It feels so frustrating that I nearly have a working solution but I am 
> > missing the last few meters. 
> > 
> > How to use the script: 
> > 
> > 1) in dom0: launch script 
> > 
> > 2) make the screenshot by selection the area 
> > 
> > as the xclip is not working in the AppVM as supposed: 
> > 
> > 3) switch to the AppVM where the screenshot should be used 
> > 
> > 4) launch the "helper script" in the AppVM which is running the following 
> > command 
> > 
> > xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png 
> > 
> > My qvm-screenshot-to-clipboard script which has to be placed and run from 
> > dom0: 
> > 
> > --- BEGIN of script --- 
> > 
> > 
> > #!/bin/bash 
> > # qvm-screenshot-to-clipboard 
> > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM 
> > 
> > MyAppVM=$1 
> > MyScreenshot=qvm-screenshot-to-clipboard.png 
> > 
> > # Take screenshot in dom0 by selecting an area and adding border+shadow 
> > gnome-screenshot --area --include-border --border-effect=shadow 
> > --file=/tmp/$MyScreenshot 
> > 
> > # Copy screenhot to AppVM command line argument / delete existing file 
> > 
> > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' 
> > 
> > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot 
> > 
> > ###FIXME begin 
> > 
> > # I would like to just invoke the following 
> > # command via qvm-run in the AppVM 
> > # but the clipboard is just empty when using 
> > # this approach. 
> > # running the same command 
> > # xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png 
> > # therof I have put the command into a helper 
> > # script in my AppVM: 
> > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh 
> > # the script is working when it is launched from 
> > # an already opened gnome-terminal window 
> > # but it will not work when the script is invoked 
> > # from dom0 via qvm-run or through an own  
> > # strangely it is also not working when I start 
> > # the script from within the appvm 
> > # 'xterm -e 
> 
> > If interested, I've recently made a similar
> > script that works a little differently.
> > [...]
> > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots 
> > ( sleep 3 ) 
> > qvm-move-to-vm Base ~/Screenshots/screenshot_* 
> > [...]
> 
> Your scripts can be used to save all screenshots to a folder in an AppVM 
> whereas my scripts is mainly for quick copy'n paste.
> 
> I think I'll also change my script to use xfce4-screenshoiter instead of 
> gnome-screenshot.
> Thanks for the hint.
> 
> I have uploaded my script to GitHub, maybe you should do the same or we add 
> it to the repository so that users can pick the right script for their needs?
> 
> As you mentioned:
> Choice is always a good thing.
> 
> [799]

@ [799]

Aight, I followed up on your suggestion and made a wiki for this script. Feel 
free to use it any way you like. 
https://github.com/Aekez/scripting-qubes/wiki/Streamlining-the-Screenshotting

If our scripts in the end can't be merged without loosing strengths or avoiding 
new weaknesses in them, then perhaps an idea could be to use ideas from each 
others scripts which work. For example if you're okay with it I might add the 
clipboard functionality. Of course crediting you. But then there is the 
question if our scripts could essentially be merged into a single script by 
such a move? If so, then I don't mind you posting it, I'll simply add a 
reference to your script in the wiki so anyone reading it will be made aware of 
yours. Credits doesn't matter much to me, so I don't mind if you put a merged 
script together, if 

[qubes-users] Re: Undoing an errant qubes-dom0-upgate

2018-02-18 Thread Yuraeitha
On Monday, February 19, 2018 at 2:43:59 AM UTC+1, Demi Obenour wrote:
> I ran qubes-dom0-upgate with the testing repo enabled, which broke my system. 
>  How do I recover?

How was it broken? Can you reach dom0? or can't you boot at all? 
Any error messages of interest appearing during failure? For example during 
grub, kernel, xen, graphic and x-server errors, virtualisation errors?

Do you have access to the journalctl command?
Can you reach the dom0 system with recovery mode, from your Qubes install media?

Do you remember the nature of the updates you installed? Was there a kernel 
included? Xen perhaps? Something you remember? even a single word might be 
insightful and give a better clue.

You can always manually extract your AppVM's data from a live medium boot, but 
this, is probably a last ditch resort if nothing else works. But for that, we 
need more information to go on, there are literally beyond thousands upon 
thousands of ways a system can break. But a clue, can for example narrow it 
down to 30% of all the ways something broke, and another clue perhaps further 
narrowing down the possible culprit. 

Therefore, information is vital here, more is needed.

-- 
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/08eaa4e0-af53-4663-bec3-49f789bd7799%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Undoing an errant qubes-dom0-upgate

2018-02-18 Thread Demi Obenour
I ran qubes-dom0-upgate with the testing repo enabled, which broke my
system.  How do I recover?

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


[qubes-users] Re: Did qubes-dom0-upgrade to R4.0, won't boot

2018-02-18 Thread Yuraeitha
On Monday, February 19, 2018 at 1:09:08 AM UTC+1, Demi Obenour wrote:
> I upgraded my install to R4.0 and now my system won't boot.  How can I fix it?
> 
> 
> Some notes:
> 
> 
> - Firmware recognizes Qubes, tries to load it
> - Qubes won't boot
> - The filesystems CAN mount when I do a rescue boot.
> - Transient message is attached

I did not watch the video you attached, can you perhaps instead describe what 
happens? For example, does your screen go black during boot after install? or 
during early install? Such details may provide vital clues.

It sounds a lot to me like it's a graphic driver issue, which is probably due 
to the kernel, or associated modules. Everything written below, follows that 
"assumption". 

- For Grub, you can easily temporarily modify the grub settings during early 
boot, by pressing the E key on a grub menu. Put "nomodeset" somewhere in the 
latter part of the Module line.   

- For EFI, you'll have to either fetch a live-boot to gain access to Qubes root 
system, and then edit the efi.cfg file found somewhere in /boot, typically 
/boot/efi/EFI/qubes/xen.cfg or something like it, or if you're terminal savy, 
you can edit the file directly from the qubes dom0 terminal that you reported 
you gained access to (probably the most easy if you're that far already). This 
fix applies both to the EFI installer medium, as well as any finished installed 
system booting via EFI, whichever is having the black screen.

- Grub is by far the most quick to troubleshoot, but they may also act 
differently, for example on which drivers they load. Try both approaches, see 
if one works. 

- You can also try disable IOMMU for GTX graphics. If you know your system 
fully meet the system requirements, then try change UEFI settings. Sometimes 
it's a rogue setting messing everything up, sometimes it may be a really 
unlikely setting. For example I've once seen Qubes unable to boot up, because 
external graphic card was sharing memory with the internal graphic card. Stuff 
like this, trial and error and see if you can find something. 

-- 
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/0a702dad-5c90-4de9-9e10-4faf1f0b9a89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HP 1040 G3 laptop - wireless toggle button doesn't work

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 8:49:09 PM UTC+1, cub...@tutamail.com wrote:
> Hi, 
> I've installed Qubes-OS 4.0 rc4 on HP 1040 G3 laptop. 
> It seems HP has changed the rules of the game and introduced dedicated driver 
> for the physical wireless toggle button (located above the keyboard, next to 
> the audio on/off button). 
> I actually test installed Windows 10 on the laptop to confirm the new 
> feature. And indeed, without installing "wireless button driver" pressing the 
> button would not cause any effect. 
> The same holds true with Qubes-OS installed on the laptop. 
> 
> Is there any way of forcing this button to work? It works fine on older HP 
> laptop models but they seems to be tightening their hardware architecture 
> even further. 
> 
> My alternative approach for now is to create scrips in sys-net VM to load / 
> unload kernel modules (sudo rmmod iwlmvm / sudo rmmod iwlwifi / sudo modprobe 
> iwlwifi). This does work fine but is not as elegant as pressing dedicated 
> button. 
> 
> Please share your thoughts and suggestions on forcing HP 1040 G3 to behave. 
> 
> Thank you
> Paul

As for your wireless button, you can do the same as above, write it in a 
script, and keybind it. While the specific keybind key may not be changeable, 
you can literally pick any other default keys to keybind instead. 

I'm not sure about the fan speed thingy, it sounds like you either need a 
better kernel module (kind of like an external, optional, secondary driver from 
the kernel's more primary drivers, if using windows language), or a poor 
setting in UEFI. It could also be a bad UEFI version that requires UEFI to be 
updated, but you may want to try other fixes before updating your UEFI, which 
can go wrong if not done properly, bricking your laptop's motherboard. But 
perhaps you have done it before, in which case, it's less dangerous if you know 
what you get yourself into here. But try see if you can find a kernel moduel 
first for your CPU/motherboard, try google any Linux systems using your 
hardware, this is not something unique to Qubes, but may likely appear on any 
number of Linux systems using this hardware.

-- 
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/fc96c952-68a9-4391-9a41-c7b1581ca71c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 11:32:16 PM UTC+1, awokd wrote:
> On Sun, February 18, 2018 10:24 pm, Yuraeitha wrote:
> 
> > hmm, thinking about it, did you try awokd's approach?
> 
> He had but it wasn't working so I was just suggesting trying out a
> different command line option for xclip. Could be because it was in a
> different session or something, like you're saying.

@awokd 
Most likely yes, I haven't seen a command that can't be run from dom0 yet, it 
just need a little spanki'... Ahem, love. 

I haven't yet fully grasped why some commands behave different as they do when 
from dom0, compared to when same command is executed inside the AppVM. For 
example the bash example above. But I imagine, grasping this difference, one 
can probably execute anything from dom0.

-- 
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/d5e105c6-8007-48c7-9a60-303bdf4c5453%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 11:00:35 PM UTC+1, [799] wrote:
> -- 
> Qubes 4rc3 > Lenovo X230 + Lenovo W540
> 
> Gesendet von ProtonMail mobile
> 
> 
> 
> 
>  Original-Nachricht 
> An 18. Feb. 2018, 22:25, Yuraeitha wrote:
> 
> On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: 
> > Hello, 
> > 
> > having the idea of a qvm-screenshot-to-clipboard script I was eager to try 
> > writting a script. 
> > The solution I had in mind could work but I am struggling with a small 
> > issue and would like to get some help. 
> > The script takes a screenshot in dom0, store it to a file and qvm-copy the 
> > file to the target appvm (one and only command line argument for the 
> > script). 
> > Then within the AppVM it is using xclip to copy the graphic to clipboard 
> > and removes all temporary files in the AppVM and dom0 
> > All pieces are working, except the xclip command when launced from dom0. 
> > 
> > When I launch the command within the AppVM it is working. 
> > But I need to start the xclip command from an external script and when I do 
> > so, the same command is not working. 
> > It seems that I am missing something when using xclip via script which is 
> > run in a new terminal session (from dom0 but also within the App) 
> > 
> > Any ideas how to fix this? 
> > It feels so frustrating that I nearly have a working solution but I am 
> > missing the last few meters. 
> > 
> > How to use the script: 
> > 
> > 1) in dom0: launch script 
> > 
> > 2) make the screenshot by selection the area 
> > 
> > as the xclip is not working in the AppVM as supposed: 
> > 
> > 3) switch to the AppVM where the screenshot should be used 
> > 
> > 4) launch the "helper script" in the AppVM which is running the following 
> > command 
> > 
> > xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png 
> > 
> > My qvm-screenshot-to-clipboard script which has to be placed and run from 
> > dom0: 
> > 
> > --- BEGIN of script --- 
> > 
> > 
> > #!/bin/bash 
> > # qvm-screenshot-to-clipboard 
> > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM 
> > 
> > MyAppVM=$1 
> > MyScreenshot=qvm-screenshot-to-clipboard.png 
> > 
> > # Take screenshot in dom0 by selecting an area and adding border+shadow 
> > gnome-screenshot --area --include-border --border-effect=shadow 
> > --file=/tmp/$MyScreenshot 
> > 
> > # Copy screenhot to AppVM command line argument / delete existing file 
> > 
> > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' 
> > 
> > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot 
> > 
> > ###FIXME begin 
> > 
> > # I would like to just invoke the following 
> > # command via qvm-run in the AppVM 
> > # but the clipboard is just empty when using 
> > # this approach. 
> > # running the same command 
> > # xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png 
> > # therof I have put the command into a helper 
> > # script in my AppVM: 
> > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh 
> > # the script is working when it is launched from 
> > # an already opened gnome-terminal window 
> > # but it will not work when the script is invoked 
> > # from dom0 via qvm-run or through an own  
> > # strangely it is also not working when I start 
> > # the script from within the appvm 
> > # 'xterm -e 
> 
> > If interested, I've recently made a similar
> > script that works a little differently.
> > [...]
> > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots 
> > ( sleep 3 ) 
> > qvm-move-to-vm Base ~/Screenshots/screenshot_* 
> > [...]
> 
> Your scripts can be used to save all screenshots to a folder in an AppVM 
> whereas my scripts is mainly for quick copy'n paste.
> 
> I think I'll also change my script to use xfce4-screenshoiter instead of 
> gnome-screenshot.
> Thanks for the hint.
> 
> I have uploaded my script to GitHub, maybe you should do the same or we add 
> it to the repository so that users can pick the right script for their needs?
> 
> As you mentioned:
> Choice is always a good thing.
> 
> [799]

btw, I don't mind if you merge some of the code, what I feel is important here 
is that people have something that just works. Besides a crucial part of this 
code is something I got elsewhere anyway, I just don't remember where anymore. 
In short, the mv "$()" part of the script to bypass the "save as" is not my 
invention, but something I learned elsewhere, where-ever that was in time and 
space.

-- 
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/b3a09260-755f-4c3d-b56f-61062ce10a57%40googlegroups.com.
For 

Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread 'awokd' via qubes-users
On Sun, February 18, 2018 10:24 pm, Yuraeitha wrote:

> hmm, thinking about it, did you try awokd's approach?

He had but it wasn't working so I was just suggesting trying out a
different command line option for xclip. Could be because it was in a
different session or something, like you're saying.


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


Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 1:11:58 AM UTC+1, [799] wrote:
> Hello awokd,
> 
>  Original-Nachricht 
> An 17. Feb. 2018, 23:41, 'awokd' via qubes-users schrieb:
> 
> > Can't really find a man page for xclip. What
> > happens when you run this in dom0? 
> 
> xclip doesn't have to be present in dom0 as the command is only used in the 
> AppVM.
> As such you might need to install it in your template VM.
> 
> In dom0 you are only using gnome-screenshot to make the screenshot.
> If it is not available in dom0 you can install it via qubes-dom0-update 
> gnome-screenshot or use any other existing sxreenshot-app which is available 
> in your dom0 and offers the option to safe screenshots directly to file.
> 
> Question regarding security:
> As far as I can tell I don't think that the suggested solution to transfer 
> screenshots to an AppVM offers a great security risk as the data is only 
> flowing from (!) dom0 to your AppVM and the graphic file is creating in dom0.
> But as I am far away from being a security expert, I'd like to hear a more 
> qualified feedback if working with this script might be a bad idea.
> 
> Regards
> 
> [799]

hmm, thinking about it, did you try awokd's approach? I do something very 
similar for my QubesTV setup that I'm working on polishing, which works on 
scripts too, like we're doing here. The command may have to be adjusted a bit, 
but in general, it should work, even without xclip in dom0. 

Actually, I'd go as far as to say it should most definitely work for xclip, 
while my scripts here are different, I've done it enough to tell it can work if 
modified correctly.

Either way, try awokd's command out, it will definitely work in one variant or 
different. The question is if require a bit of modification. For example, maybe 
use "qvm-run AppVM bash 'command to execute inside AppVM -o etc. lalala'" 
instead of say, "qvm-run AppVM gnome-terminal -e 'command to execute inside 
AppVM -o etc. lalala'". 

For example I've seen a case where one when executed inside the AppVM, will 
open the executed QubesTV streaming link in the same browser, same tab, while 
the very same command inserted into the AppVM from dom0, would open up a whole 
new instance of Firefox, and thereby open a new window. Which, needless to say, 
doesn't work. The solution was to use bash for already running firefox, so that 
it won't start a new firefox instance. Hopefully you can use any of this to 
make qvm-run appvm "command" work.

In terms of security, I'm in the same boat, I can't say for sure. But I agree 
with the notion, that it "probably"? is secure due to the one direction flow of 
data.

-- 
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/8bc85072-ac09-4ccc-8915-331ea300a33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Custom 16:9 dispay resolution to be applied at qubes-os startup (Q4.0rc4)

2018-02-18 Thread cubecub

Hi,
Could anyone help me with figuring out how to set one of the custom display 
resolution as startup default? 

Qubes 4.0 rc 4 comes with many predefined resolutions but unfortunately only 
one with the aspect ration of 16:9. 

I then created various custom resolution modes and added them to desplay 
options. I used the following commands:
cvt - to get new mode parameters
xrandr --newmode - to define new resolution mode
xrandr --addmode - to add newly defined resolution mode to deplay drop-down box
xrandr --output - to apply new, desired resolution to the current display. 

What I can't work out is how to make of my new, custom resolution to be used by 
qubes-os as default. 
What qubes-os configuration files should I modify and how in order to achieve 
that? Do I need to interfere with xen.config? 

If you already have a solution please share. 

Thank you
Paul






-- 
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/L5ezclA--3-0%40tutamail.com.
For more options, visit https://groups.google.com/d/optout.


AW: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread '[799]' via qubes-users
--
Qubes 4rc3 > Lenovo X230 + Lenovo W540

Gesendet von ProtonMail mobile

 Original-Nachricht 
An 18. Feb. 2018, 22:25, Yuraeitha wrote:

On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote:
> Hello,
>
> having the idea of a qvm-screenshot-to-clipboard script I was eager to try 
> writting a script.
> The solution I had in mind could work but I am struggling with a small issue 
> and would like to get some help.
> The script takes a screenshot in dom0, store it to a file and qvm-copy the 
> file to the target appvm (one and only command line argument for the script).
> Then within the AppVM it is using xclip to copy the graphic to clipboard and 
> removes all temporary files in the AppVM and dom0
> All pieces are working, except the xclip command when launced from dom0.
>
> When I launch the command within the AppVM it is working.
> But I need to start the xclip command from an external script and when I do 
> so, the same command is not working.
> It seems that I am missing something when using xclip via script which is run 
> in a new terminal session (from dom0 but also within the App)
>
> Any ideas how to fix this?
> It feels so frustrating that I nearly have a working solution but I am 
> missing the last few meters.
>
> How to use the script:
>
> 1) in dom0: launch script
>
> 2) make the screenshot by selection the area
>
> as the xclip is not working in the AppVM as supposed:
>
> 3) switch to the AppVM where the screenshot should be used
>
> 4) launch the "helper script" in the AppVM which is running the following 
> command
>
> xclip -selection clipboard -t image/png 
> /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
>
> My qvm-screenshot-to-clipboard script which has to be placed and run from 
> dom0:
>
> --- BEGIN of script ---
>
>
> #!/bin/bash
> # qvm-screenshot-to-clipboard
> # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM
>
> MyAppVM=$1
> MyScreenshot=qvm-screenshot-to-clipboard.png
>
> # Take screenshot in dom0 by selecting an area and adding border+shadow
> gnome-screenshot --area --include-border --border-effect=shadow 
> --file=/tmp/$MyScreenshot
>
> # Copy screenhot to AppVM command line argument / delete existing file
>
> qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot'
>
> qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot
>
> ###FIXME begin
>
> # I would like to just invoke the following
> # command via qvm-run in the AppVM
> # but the clipboard is just empty when using
> # this approach.
> # running the same command
> # xclip -selection clipboard -t image/png 
> /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
> # therof I have put the command into a helper
> # script in my AppVM:
> # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh
> # the script is working when it is launched from
> # an already opened gnome-terminal window
> # but it will not work when the script is invoked
> # from dom0 via qvm-run or through an own
> # strangely it is also not working when I start
> # the script from within the appvm
> # 'xterm -e

> If interested, I've recently made a similar
> script that works a little differently.
> [...]
> mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots
> ( sleep 3 )
> qvm-move-to-vm Base ~/Screenshots/screenshot_*
> [...]

Your scripts can be used to save all screenshots to a folder in an AppVM 
whereas my scripts is mainly for quick copy'n paste.

I think I'll also change my script to use xfce4-screenshoiter instead of 
gnome-screenshot.
Thanks for the hint.

I have uploaded my script to GitHub, maybe you should do the same or we add it 
to the repository so that users can pick the right script for their needs?

As you mentioned:
Choice is always a good thing.

[799]

-- 
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/Yekef6OjKPpwPjI-xqxT_nSnXoHRm9BjlG8YaNa36L9YOdGyQwzsiesfsyxieEXbD0zj-R-_GTp2KWoWAHBtxjyukwYjOnGj6ZYOEEy06qc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 10:25:19 PM UTC+1, Yuraeitha wrote:
> On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote:
> > Hello,
> > 
> > having the idea of a qvm-screenshot-to-clipboard script I was eager to try 
> > writting a script.
> > The solution I had in mind could work but I am struggling with a small 
> > issue and would like to get some help.
> > The script takes a screenshot in dom0, store it to a file and qvm-copy the 
> > file to the target appvm (one and only command line argument for the 
> > script).
> > Then within the AppVM it is using xclip to copy the graphic to clipboard 
> > and removes all temporary files in the AppVM and dom0
> > All pieces are working, except the xclip command when launced from dom0.
> > 
> > When I launch the command within the AppVM it is working.
> > But I need to start the xclip command from an external script and when I do 
> > so, the same command is not working.
> > It seems that I am missing something when using xclip via script which is 
> > run in a new terminal session (from dom0 but also within the App)
> > 
> > Any ideas how to fix this?
> > It feels so frustrating that I nearly have a working solution but I am 
> > missing the last few meters.
> > 
> > How to use the script:
> > 
> > 1) in dom0: launch script
> > 
> > 2) make the screenshot by selection the area
> > 
> > as the xclip is not working in the AppVM as supposed:
> > 
> > 3) switch to the AppVM where the screenshot should be used
> > 
> > 4) launch the "helper script" in the AppVM which is running the following 
> > command 
> > 
> > xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
> > 
> > My qvm-screenshot-to-clipboard script which has to be placed and run from 
> > dom0:
> > 
> > --- BEGIN of script ---
> > 
> > 
> > #!/bin/bash
> > # qvm-screenshot-to-clipboard
> > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM
> > 
> > MyAppVM=$1
> > MyScreenshot=qvm-screenshot-to-clipboard.png
> > 
> > # Take screenshot in dom0 by selecting an area and adding border+shadow
> > gnome-screenshot --area --include-border --border-effect=shadow 
> > --file=/tmp/$MyScreenshot
> > 
> > # Copy screenhot to AppVM command line argument / delete existing file
> > 
> > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot'
> > 
> > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot
> > 
> > ###FIXME begin
> > 
> > # I would like to just invoke the following
> > # command via qvm-run in the AppVM
> > # but the clipboard is just empty when using
> > # this approach.
> > # running the same command
> > # xclip -selection clipboard -t image/png 
> > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
> > # therof I have put the command into a helper
> > # script in my AppVM:
> > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh
> > # the script is working when it is launched from
> > # an already opened gnome-terminal window
> > # but it will not work when the script is invoked
> > # from dom0 via qvm-run or through an own 
> > # strangely it is also not working when I start
> > # the script from within the appvm
> > # 'xterm -e
> 
> If interested, I've recently made a similar script that works a little 
> differently. I'll put it here as having options and choice is a good thing.
> 
> 
> mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots
>  ( sleep 3 )
> qvm-move-to-vm Base ~/Screenshots/screenshot_*
> 
> 
> 
> 
> 
> I know many here don't need an explanation since it's a rather straight 
> forward simple working script that "just works", but for those who may need 
> it, here are some considerations to take into account about the script:
> 
> - The mv "$() part of the script serves as a function to remove "save as" and 
> instead auto-save with the name screenshot_+date+timestamp. 
> 
> - Never remove the -o attribute if you want the mv "$() part of the script 
> working.
> 
> - The first line decides where to save the screenshot, and the third line 
> pulls the screenshot from this location. By narrowing down an empty folder 
> specifically this use-case, you avoid false positive transfers, although 
> those are unlikely in dom0 anyway.
> 
> - By default this scripts sends screenshots to an offline AppVM that I 
> frequently have running in the background for offline applications and daily 
> used data.
> 
> - AppVM name used: Base
> 
> - Fullscreen, keep the f attribute.
> 
> - Region, change -fo to -ro
> 
> - Window, change -fo to -wo
> 
> - The screenshot_* part, will move any files or folders beginning with 
> screenshot_*, at the given address location. If you got older screenshots 
> there, then they will also be moved. This should not be a big problem though, 
> if you only use these scripts and keep the folder empty.
> 
> - You can also optionally keybind scripts to different AppVM's, so you don't 
> have to move them a second time from the standard AppVM.
> 
> - Need longer 

[qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt

2018-02-18 Thread Yuraeitha
On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote:
> Hello,
> 
> having the idea of a qvm-screenshot-to-clipboard script I was eager to try 
> writting a script.
> The solution I had in mind could work but I am struggling with a small issue 
> and would like to get some help.
> The script takes a screenshot in dom0, store it to a file and qvm-copy the 
> file to the target appvm (one and only command line argument for the script).
> Then within the AppVM it is using xclip to copy the graphic to clipboard and 
> removes all temporary files in the AppVM and dom0
> All pieces are working, except the xclip command when launced from dom0.
> 
> When I launch the command within the AppVM it is working.
> But I need to start the xclip command from an external script and when I do 
> so, the same command is not working.
> It seems that I am missing something when using xclip via script which is run 
> in a new terminal session (from dom0 but also within the App)
> 
> Any ideas how to fix this?
> It feels so frustrating that I nearly have a working solution but I am 
> missing the last few meters.
> 
> How to use the script:
> 
> 1) in dom0: launch script
> 
> 2) make the screenshot by selection the area
> 
> as the xclip is not working in the AppVM as supposed:
> 
> 3) switch to the AppVM where the screenshot should be used
> 
> 4) launch the "helper script" in the AppVM which is running the following 
> command 
> 
> xclip -selection clipboard -t image/png 
> /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
> 
> My qvm-screenshot-to-clipboard script which has to be placed and run from 
> dom0:
> 
> --- BEGIN of script ---
> 
> 
> #!/bin/bash
> # qvm-screenshot-to-clipboard
> # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM
> 
> MyAppVM=$1
> MyScreenshot=qvm-screenshot-to-clipboard.png
> 
> # Take screenshot in dom0 by selecting an area and adding border+shadow
> gnome-screenshot --area --include-border --border-effect=shadow 
> --file=/tmp/$MyScreenshot
> 
> # Copy screenhot to AppVM command line argument / delete existing file
> 
> qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot'
> 
> qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot
> 
> ###FIXME begin
> 
> # I would like to just invoke the following
> # command via qvm-run in the AppVM
> # but the clipboard is just empty when using
> # this approach.
> # running the same command
> # xclip -selection clipboard -t image/png 
> /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png
> # therof I have put the command into a helper
> # script in my AppVM:
> # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh
> # the script is working when it is launched from
> # an already opened gnome-terminal window
> # but it will not work when the script is invoked
> # from dom0 via qvm-run or through an own 
> # strangely it is also not working when I start
> # the script from within the appvm
> # 'xterm -e

If interested, I've recently made a similar script that works a little 
differently. I'll put it here as having options and choice is a good thing.


mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots
 ( sleep 3 )
qvm-move-to-vm Base ~/Screenshots/screenshot_*





I know many here don't need an explanation since it's a rather straight forward 
simple working script that "just works", but for those who may need it, here 
are some considerations to take into account about the script:

- The mv "$() part of the script serves as a function to remove "save as" and 
instead auto-save with the name screenshot_+date+timestamp. 

- Never remove the -o attribute if you want the mv "$() part of the script 
working.

- The first line decides where to save the screenshot, and the third line pulls 
the screenshot from this location. By narrowing down an empty folder 
specifically this use-case, you avoid false positive transfers, although those 
are unlikely in dom0 anyway.

- By default this scripts sends screenshots to an offline AppVM that I 
frequently have running in the background for offline applications and daily 
used data.

- AppVM name used: Base

- Fullscreen, keep the f attribute.

- Region, change -fo to -ro

- Window, change -fo to -wo

- The screenshot_* part, will move any files or folders beginning with 
screenshot_*, at the given address location. If you got older screenshots 
there, then they will also be moved. This should not be a big problem though, 
if you only use these scripts and keep the folder empty.

- You can also optionally keybind scripts to different AppVM's, so you don't 
have to move them a second time from the standard AppVM.

- Need longer time, for example to carefully select text in region screenshots, 
then expand the sleep timer to, say, 20 seconds.

- Make scripts executable and put them in dom0 $HOME/ folder. Then simply just 
keybind them in Qubes Menu --> System-Tools --> Keyboard ---> Shortcut tab. 

- If dom0 is ever compromised, or the AppVM you backup your 

[qubes-users] Re: Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 7:15:47 PM UTC+1, klausd...@mail2tor.com wrote:
> Hey guys,
> 
> I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how to
> do this. Can someone help me or someone who aleady did this, can describe
> how to do this?
> 
> best regards

What are the reasons you want Ubuntu? By any chance is it due to codecs and 
such licenses? You can quite easily get all of that working in Fedora or 
Debian. 

I may have overlooked something, but one of the bigger reasons to want ubuntu, 
may be codecs and ability to play videos? I'll go ahead and take a guess that 
it might be partly codec related, though I may be guessing wrong. 

For example an easy fix to make Fedora play almost any modern video --> clone 
your fedora template --> Add RPMFusion to your new fedora clone template. 
Install ffmpeg and vlc from RPMFusion repositories (Qubes has a really easy and 
quick guide to enable them). Voila, you can now watch HTML5 content videos in 
firefox on AppVM's based on your fedora template clone. Verify if it works with 
www.youtube.com/html5

For protected content, such as copyright protection, which can mess up an 
otherwise working HTML5 video, you'll probably need the google browser either 
way, directly from googles website. Unfortunately it can be messy to get 
protected content to play in browsers like Firefox. But that should apply to 
Ubuntu as well.

-- 
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/7971f3c5-51af-468a-9f08-607ec29c76c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread Unman
On Sun, Feb 18, 2018 at 08:20:40PM -, 'awokd' via qubes-users wrote:
> On Sun, February 18, 2018 7:10 pm, Unman wrote:
> > On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote:
> 
> >> https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems
> >> to be impacting Ubuntu builds as well.
> >>
> >>
> >
> > That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3
> > HAS broken the builds because of the changes in debian packaging there.
> 
> The changes in Debian packaging also broke Debian builds. Is your point
> one of semantics, or is it a different root cause? (Asking for my own
> education, not to nitpick.)

It's a different root cause.
The stretch build completes all the modules but then breaks on the
template build.
The Ubuntu builds fail on the packaging within the modules. 
Its almost always the case that major (sometimes minor) changes in
Debian builds will break the Ubuntu templates because they arent
incorporated in to the testing structure. So we are always playing catch
up in those circumstances.

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


Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread 'awokd' via qubes-users
On Sun, February 18, 2018 7:10 pm, Unman wrote:
> On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote:

>> https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems
>> to be impacting Ubuntu builds as well.
>>
>>
>
> That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3
> HAS broken the builds because of the changes in debian packaging there.

The changes in Debian packaging also broke Debian builds. Is your point
one of semantics, or is it a different root cause? (Asking for my own
education, not to nitpick.)

> Im going to fix this.

Thank you!


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


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-18 Thread Yuraeitha
On Sunday, February 18, 2018 at 3:51:00 AM UTC+1, William Bormann wrote:
> On a lark, I purchased a Yubico FIDO U2F Security key.  It's an inexpensive 
> USB token that can be used for two-factor authentication for Gmail and 
> Facebook, among others.  I'd like to use it on my Qubes RC4 system.
> 
> I've read the USB documentation, but thought I'd see if somebody else running 
> Qubes has managed to get this working as advertised on their system. The 
> current path that seems most promising is to bring up SYS-USB, but I have 
> some concerns about doing this since my keyboard and mouse are both usb 
> devices.
> 
> Can anyone reply with a "hand waving" set of steps I should follow?  I would 
> greatly appreciate hearing your solution.

I did not yet get around to testing it out for locking down Qubes my self just 
yet, but there should be quite a lot of people who managed to. Consider that 
there are at least a good amount of people wanting this, and generally you see 
people posting about whether to do it or not (like your post), over people who 
somehow messed it up and are locked out of their system. 

>From that, I'd deduce that it is probably safe. But you may want to do backup 
>first, at least of your most important AppVM's, just in case something should 
>go south. You never know, whatever can go wrong, will eventually go wrong, as 
>the saying goes.

Also for what purposes? LUKS disk decryption? Qubes password login/logout when 
insert/retracting the Yubi-key? Third-party services in AppVM's?

But having said that, I doubt it's a big issue, especially not if you backup 
first. Also from what I can read, your old password still works, in case the 
key isn't working anymore, or is lost/stolen. This isn't a measure against 
cracking, but a measure against people looking over a persons shoulder, or if 
sitting under a camera, stuff like that where the password can be stolen. 
Although of course, it can also servee as a means to memorize a crazy long 
strong password with high entropy, which makes cracking your drive even harder.

Whatever the case, you should probably have a means to remember a long random 
password with strong entropy, in case you loose your hardware key, for example 
write it on a piece of paper and hide it inside a wall (or something crazy like 
that). You can alaos backup the hardware key's seed, which is recommended in 
case you loose the key and need a new key with same 2nd factoring credentials.

Essentially, it likely more boils down to how you handle your key, and how you 
prevent loosing it, or exposing it to potential attackers in the physical 
world. Just search these google mails, you probably won't find many having 
issues, and instead find people asking questions before they start using 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/f73f119e-24ca-4e16-a78d-0128c87ceddb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HP 1040 G3 laptop - wireless toggle button doesn't work

2018-02-18 Thread cubecub
Hi, 
I've installed Qubes-OS 4.0 rc4 on HP 1040 G3 laptop. 
It seems HP has changed the rules of the game and introduced dedicated driver 
for the physical wireless toggle button (located above the keyboard, next to 
the audio on/off button). 
I actually test installed Windows 10 on the laptop to confirm the new feature. 
And indeed, without installing "wireless button driver" pressing the button 
would not cause any effect. 
The same holds true with Qubes-OS installed on the laptop. 

Is there any way of forcing this button to work? It works fine on older HP 
laptop models but they seems to be tightening their hardware architecture even 
further. 

My alternative approach for now is to create scrips in sys-net VM to load / 
unload kernel modules (sudo rmmod iwlmvm / sudo rmmod iwlwifi / sudo modprobe 
iwlwifi). This does work fine but is not as elegant as pressing dedicated 
button. 

Please share your thoughts and suggestions on forcing HP 1040 G3 to behave. 

Thank you
Paul







-- 
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/L5eSbDB--3-0%40tutamail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HP laptop - issue with "pulsating" fan, ramping up and down every 3s

2018-02-18 Thread cubecub
Hi, 
I've recently bought an HP 1040 G3 laptop to use with Qubes-OS. The latest 
version has been installed (4.0 rc4) but I have few issues that I'm trying to 
sort out. 

One of them is the issue with fan speed. As the qubes OS starts the fan is 
constantly on, but the speeed seems to insrease ever so slightly every 3s. That 
creates an "pulsting" effect of the fan noise which, when using the laptop for 
a longer time, becomes really disturbing. 

I tried to find solutions online but as of now was unsuccessful. In Power 
Management settings of quebes there is no reference to fan speed or settings 
that could influence it. 

Could anyone advise how to setup and control fan speed with qubes-os? 

Many 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/L5ePVnF--3-0%40tutamail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread Unman
On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote:
> On Sun, February 18, 2018 5:41 pm, klausdiet...@mail2tor.com wrote:
> > Hey guys,
> >
> >
> > I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how
> > to do this. Can someone help me or someone who aleady did this, can
> > describe how to do this?
> 
> https://www.qubes-os.org/doc/templates/ubuntu/ . Also, check
> https://www.qubes-os.org/doc/building-archlinux-template/ for a bit more
> detailed example, but I suggest waiting until
> https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems to
> be impacting Ubuntu builds as well.
> 
> 

That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3
HAS broken the builds because of the changes in debian packaging there.
Im going to fix this.
If you want a Ubuntu template pro tem until the build is fixed, I've
put some here:
qubes.3isec.org

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


Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread 'awokd' via qubes-users
On Sun, February 18, 2018 5:41 pm, klausdiet...@mail2tor.com wrote:
> Hey guys,
>
>
> I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how
> to do this. Can someone help me or someone who aleady did this, can
> describe how to do this?

https://www.qubes-os.org/doc/templates/ubuntu/ . Also, check
https://www.qubes-os.org/doc/building-archlinux-template/ for a bit more
detailed example, but I suggest waiting until
https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems to
be impacting Ubuntu builds as well.



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


[qubes-users] Installing Ubuntu template VM in Qubes 3.2

2018-02-18 Thread KlausDieter2
Hey guys,

I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how to
do this. Can someone help me or someone who aleady did this, can describe
how to do this?

best regards

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


Re: [qubes-users] Re: Install on Dell XPS 13 (9350)

2018-02-18 Thread 'awokd' via qubes-users
On Sat, February 17, 2018 8:33 pm, ynwa44 via qubes-users wrote:
> On Tuesday, February 13, 2018 at 4:31:33 PM UTC+4, awokd wrote:
>
>> On Tue, February 13, 2018 11:32 am, xxx.l...@gmail.com wrote:
>>
>>> Thank you for your help awokd, I now have sys-net running in HVM mode
>>> on the XPS 9350 wifi card in permissive mode, this resolve the issue
>>> on 4.0.
>>
>> Glad it worked out! But consider getting a different wifi card some day
>>  that doesn't need permissive mode, it's not the best from a security
>> perspective. :)
>
> Can you please help with connecting to wifi for the first time?

Sure, but more details would be helpful. If you have the same model laptop
and wireless card and need to enable permissive mode, check up thread for
documentation on how to do that.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/2518d9cbd073721d42d1b85f502768eb.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Bitmessage Shortcut in Whonix APP VM

2018-02-18 Thread KlausDieter2
Hey,

i want to know how to set a shortcut in the whonix App VM. I installed
Bitmessage in Whonix WS Template and used this to create a shortcut:

https://qubes-os.org/doc/managing-appvm-shortcuts/

But it didn´t work this way. Any Ideas?

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


[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.

2018-02-18 Thread QUBE-A-LICIOUS
On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com wrote:
> On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote:
> > Hi there,
> > 
> > I have a fresh install of Qubes 4r4.  However, when I reboot and or login I 
> > have to manually change dom0 time to UTC.
> > 
> > Impact: Whonix/Tor does not work because of the incorrect time.
> > 
> > Manual workaround:
> > 1.  Get the correct UTC from a browser.
> > 2.  Open Dom0 Terminal and update to UTC such as the following:
> > 
> >   sudo date --set "2018-02-13 21:30"
> > 
> > 3. Shutdown Service:sys-whonix
> > 4.  Restart a whonix domain such as Domain:anon-whonix(this restarts the 
> > sys-whonix service that was just shutdown.
> > 5.  Then run WhonixCheck to make sure it works.  It usually does and 
> > Whonix/Tor is functional.
> > 
> > =
> > Qubes cannot be this bad, really.
> > 
> > How can I have this Date and time correctly updated on boot up?  Like it 
> > should.
> > 
> > Thanks for all your help.
> > NSJ
> 
> Most times it is easy to point on another guilty one instead looking what may 
> happen with the own stuff. So far you are the only one with this misbehavior.
> Qubes works as expected - at least in this point.
> But most user already experienced this behavior; qubes-os or any other 
> distribution.
> The keyword is hwclock. You always update the software-based time, but if you 
> restart, all temporary data is gone. (should)
> So your OS fetches at boot the time from the bios.
> If you update your time within the qubes-os, you should update your hardware 
> clock (hc) as well: sudo hwclock --systohc
> If your time resets when you unplug your device from power supply, your 
> device's battery is flat.

--
I did some analysis this morning.  So at the same point in time the following 
settings on my Qubes laptop showed the following values.  (Bottom line is that 
whonix/tor does not work)

1.  The hardware BIOS clock is:  1030  (BIOS battery good, removed laptop 
battery for few hours and date/time stayed same)

2.  Dom0 time is: 0530 ( via date command)

3.  service:sys-whonix is:  1030 (via date command)

4.  Clock on upper right of screen is:  0430

Tor Boostrap info is:

Whonixcheck gave up waiting
clock skew -21635 in directory from DIRSERV

sudo date --set “2018 -02-18 17:30:00”

-
I think that on a normal bootup the clocks should be in sync and Whonix/Tor 
should work.

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


Re: [qubes-users] Re: R4.0 rc4 sys-whonix. Tor running as root and shouldn't be?

2018-02-18 Thread Unman
On Sun, Feb 18, 2018 at 07:25:55AM -0800, msgh...@gmail.com wrote:
> On Sunday, February 18, 2018 at 9:29:26 PM UTC+7, sebuq wrote:
> > The command sudo tor --verify-config produces an output You are running
> > Tor as root. You don't need to, and you probably shouldn't (full output
> > below).
> > 
> > How is this rectified?
> > 
> > 
> > user@host:~$ sudo tor --verify-config
> > Feb 18 14:21:23.474 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running
> > on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8,
> > Liblzma 5.1.0alpha, and Libzstd N/A.
> > Feb 18 14:21:23.474 [notice] Tor can't help you if you use it wrong!
> > Learn how to be safe at https://www.torproject.org/download/download#warning
> > Feb 18 14:21:23.474 [notice] Read configuration file "/etc/tor/torrc".
> > Feb 18 14:21:23.477 [warn] You are running Tor as root. You don't need
> > to, and you probably shouldn't.
> 
> Run it as user without sudo as warning suggests:
> user@host:~$ tor --verify-config
> 

sudo allows you to execute a command as superuser, or another user. In
Qubes, it's use is unfettered, although you can change this if you wish.
This is in the FAQ, and also here:
https://www.qubes-os.org/doc/vm-sudo

By calling "sudo tor" you invoke tor as root, which is not recommended.
As msgheap says, dont use sudo here.
If you check with ps, you'll see that tor isnt running as root in normal
operation.

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


Re: [qubes-users] cannot build ubuntu template

2018-02-18 Thread Unman
On Sat, Feb 17, 2018 at 07:54:17AM -0800, snowboard...@gmail.com wrote:
> running qubes 3.2
> 
> I am following default instructions from Archlinux.Tried to build template 
> for trusty.
> 
> I cloned the default repo.
> 
> there is a problem with python2 because in fedora 23 there is no such 
> package. I had to manually edit and put python-sh in Makefile, builder.conf 
> and setup script. After that everything seems to be working fine but it 
> crashes during make qubes-vm with this message:
> 
> ln -s ../../bin/qrexec-client-vm 
> /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes/qrexec_client_vm
> install qrexec-fork-server 
> /home/user/qubes-src/core-agent-linux/debian/tmp/usr/bin
> install qubes-rpc-multiplexer 
> /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes
> make[2]: Leaving directory `/home/user/qubes-src/core-agent-linux/qrexec'
> make[1]: Leaving directory `/home/user/qubes-src/core-agent-linux'
>dh_install
> cp: cannot stat 
> 'debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf': 
> No such file or directory
> dh_install: cp -a 
> debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf 
> debian/qubes-core-agent//lib/systemd/system/netfilter-persistent.service.d/ 
> returned exit code 1
> make: *** [binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> /home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:200: 
> recipe for target 'dist-package' failed
> make[2]: *** [dist-package] Error 2
> Makefile.generic:156: recipe for target 'packages' failed
> make[1]: *** [packages] Error 1
> Makefile:212: recipe for target 'core-agent-linux-vm' failed
> 
> 
> Why is it so difficult to build a default template? Should be working oob 
> right?
> 
It should indeed work oob.
Truth is that I only really support 1 LTS and the latest Ubuntu
version. I havent built Trusty for some time, and it's difficult to keep
it up to date with the changing code base.The right thing to do would be
to take it out the build configs.
If there's some specific reason that you need trusty, and you cant
install as HVM, I'll take a quick look and see if the build issues can
be fixed. It may be simple.
Can you let me know?

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


Re: [qubes-users] Re: qubes network

2018-02-18 Thread Unman
On Sun, Feb 18, 2018 at 02:58:34PM +, Mr SpOn wrote:
> thanks Andrew for the quick response. 
> 
> when trying to create a new VM 
> im getting this error: could not find capabilities for arch=x86_64.
> 
> those this means my laptop doesn't support this feature? 
> 
> thanks
> J
> 

Do you have VT-x enabled in BIOS? That would be the usual cause.

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


[qubes-users] Re: Installing Win7 on a Dell

2018-02-18 Thread Daniel Moerner
On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> Hi,
> 
> I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4.  I 
> have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
> installed Qubes I used the Dell recovery tool to create a recovery usb disk 
> for Win7 to re-install the OS but I'm not sure if this is usable to install 
> with Qubes.
> 
> I tried following the instructions on the Qubes website by creating a new 
> Qube without a template but I could not change it from PVM to HVM.  Then when 
> I tried booting from the USB recovery disk it would load up a terminal and 
> then exit after 10 seconds.
> 
> When I try to boot the recovery USB disk from the main BIOS it boots up fine. 
>  Does anyone have any tips for installing Win7 in Qubes 4?
> 
> Thanks,
> 
> Glen

Hi,

Check out these two issues:
Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
Installing Qubes Windows Tools: 
https://github.com/QubesOS/qubes-issues/issues/3585

The two problems you describe in the post seem to be the following:
1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
2. Make sure you set the video-model to cirrus for install.

Best,
Daniel

-- 
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/d9826928-1733-4ac4-ac8a-fdb6ab5fe490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: qubes network

2018-02-18 Thread Mr SpOn
thanks Andrew for the quick response. 

when trying to create a new VM 
im getting this error: could not find capabilities for arch=x86_64.

those this means my laptop doesn't support this feature? 

thanks
J

Sent from my iPhone

> On Feb 17, 2018, at 8:08 PM, Andrew David Wong  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
>> On 2018-02-17 04:44, Mr SpOn wrote:
>> hi how are you i just install your OS and it was great, very easy.
>> very happy :)
>> 
> 
> I'm glad to hear that. :)
> 
>> is there any documentation about the recomend setups needed the 
>> first time you install qubes os? for now ive only done an update.
>> 
> 
> Take a look at the Getting Started page:
> 
> https://www.qubes-os.org/getting-started/
> 
> And our documentation in general:
> 
> https://www.qubes-os.org/doc/
> 
>> is my laptop supposed to be connected to the internet all the 
>> time?
> 
> It can be, if you want, but it's not required.
> 
>> and every time i want to use firefox i should assign to "personal 
>> vm" network access? (under settings) for the period of time i want
>> to used it? (this is just an example).
>> 
> 
> For general web browsing, most people just have a dedicated VM (e.g.,
> the "untrusted" VM) that always has the same NetVM setting.
> 
>> thanks J
>> 
>> Sent from my iPhone
>> 
> 
> P.S. - Please keep the qube-users mailing list CCed and direct future
> queries there. You can read more about our mailing lists here:
> 
> https://www.qubes-os.org/mailing-lists/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqIxAMACgkQ203TvDlQ
> MDC3MRAAzWF8DU1pPPDAc3bWDP2tP0FpxxGSYuLL0CTHZ5p2iQPgzRCmlncr7jX3
> koI+CORgnEUEtCIsX7hhfnSUPseZESPFWAm2oIwZgFu+pKB7LYxyNL2g8JdUKOQB
> KgrOXFl/CSX8QRKQYh2jRvYkXVPAbUrnOK6gwNArBqR4vWU+E8riXodIrvDU2B/i
> yoY9hHt48rzVE9iD7nf7E78yUimhfbIc+mkFBOgzLOTcLAHgmRHvH91PBqD9ziwq
> p5PvNiG31KRigTe215aJiFkPy/ra/RCiJj9KA3qFZb1OEesSq8J9Io4f9nqXLu+L
> IuL2w/3VinAODwIb95Ub1EwyzLmm4smXHpoHwCKM6Tu/utkJlvIMRR7QDCnTeILF
> C8Vrr6vxjqnZ0tSeWJ2HP1p0HzDNrd2CbuT/vxqwsQytl9R7QdM6kVngGf8ANltK
> 857oYkDG+SiUQCiluB44aLAAlA08O4tDzyLSLGiXXVxN0MP3887+7HLFR2tXVaby
> DYv7+zFZoRHKInQZuzpf6j1vA0xN7HUyi/Z7z0tlXEwT1p/yv1PrAh6vwqbiz3rh
> ZTxZYCEtQjW+sCyO3ppdXJXKDAH27c0I4nOcdCBpBgQTOsVwqYsFGk+oMeuF4w+F
> 5vvSeGiRhiRvoHtCdB/VbcGkvi+Bpw0zwl8JkIb4bMwluds32Cc=
> =MbVl
> -END PGP SIGNATURE-
> 

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


[qubes-users] R4.0 rc4 sys-whonix. Tor running as root and shouldn't be?

2018-02-18 Thread 'sebuq' via qubes-users
The command sudo tor --verify-config produces an output You are running
Tor as root. You don't need to, and you probably shouldn't (full output
below).

How is this rectified?


user@host:~$ sudo tor --verify-config
Feb 18 14:21:23.474 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running
on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8,
Liblzma 5.1.0alpha, and Libzstd N/A.
Feb 18 14:21:23.474 [notice] Tor can't help you if you use it wrong!
Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 18 14:21:23.474 [notice] Read configuration file "/etc/tor/torrc".
Feb 18 14:21:23.477 [warn] You are running Tor as root. You don't need
to, and you probably shouldn't.


-- 
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/9abbf6d8-cb7b-b38e-f343-0564c335ccf9%40dasamy.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 4.0 - there will be rc5

2018-02-18 Thread JPL
Thought so. Wise decision IMO

-- 
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/863e74a1-4ef2-42b5-9835-e9227b9b98c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - ASRock Z370 Pro4, i5-8600K

2018-02-18 Thread Krišjānis Gross
Hi,

I have recently installed Qubes 4 rc4 on 8th gen intel CPU. HCL details
attached to this e-mail.

Note: There was an issue with graphic adapter. More details here:
https://groups.google.com/forum/#!msg/qubes-users/YjNkEM1srSk/ljMSWgNTBAAJ

Other than that everything works very nice.

Kind regards,
Krisjanis

-- 
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/CA%2BbLPogPufk7veLDtF73DBOSDu8n%2B3QPEB81-25TmHywO9HARQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-ASRock-Z370_Pro4-20180218-113044.yml
Description: application/yaml


Qubes-HCL-ASRock-Z370_Pro4-20180218-113044.cpio.gz
Description: GNU Zip compressed data


[qubes-users] Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-18 Thread msgheap
Hello,

Is it possible to start all VMs marked as "Start qube automatically on boot" on 
Qubes OS boot and not on user login in Qubes OS?
Is it possible to do it without Qubes OS autologin?
I want to have a working server application on VM on Qubes OS boot without the 
need to login in Qubes OS.

-- 
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/aac46c65-faa0-474e-9c8f-91dbfed35749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.