Re: [qubes-users] Re: Still don't understand how Debian-9 template is connected to Whonix templates

['awokd' via qubes-users]

thedigitalsav...@gmail.com:

it happens to me that every time I update on debian-9, sys-whonix is started. 
In fact it does the update only through whonix.
This happens only with Debian-9.
How to remove this property?

In dom0, sudo edit /etc/qubes-rpc/policy/qubes.UpdatesProxy. Set your 
$type:TemplateVM $default allow,target=sys-net instead of =sys-whonix. 
This affects all non-whonix template updates. If you somehow have a 
different entry in there that you didn't add just for debian-9, please 
record it here.


--
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/efacf31b-9f56-360c-3d90-3a9e22ad69e1%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Still don't understand how Debian-9 template is connected to Whonix templates

[thedigitalsaving]

it happens to me that every time I update on debian-9, sys-whonix is started. 
In fact it does the update only through whonix.
This happens only with Debian-9.
How to remove this property?

-- 
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/6f33542a-7a9b-4732-9f68-c94a6c793f61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Hyperthreading on or off?

['awokd' via qubes-users]

jrsmi...@gmail.com wrote on 4/3/19 9:54 PM:

Looking for guidance on best practices for Qubes configuration:  given the 
vulnerabilities that have been reported with Hyperthreading, it would seem to 
be a no-brainer that it should be disabled, but I don’t see anyone coming right 
out and saying so.  Curious what this group thinks.

Off. Qubes defaults to this now by including "smt=off" in the Xen boot 
options.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/3e5820a5-6f22-6b90-da88-20f242ceb7fd%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Hyperthreading on or off?

[jrsmiley]

Looking for guidance on best practices for Qubes configuration:  given the 
vulnerabilities that have been reported with Hyperthreading, it would seem to 
be a no-brainer that it should be disabled, but I don’t see anyone coming right 
out and saying so.  Curious what this group thinks. 

-- 
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/f4580a97-000b-449d-b0b3-fcc368ea84bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nicklas Williams]

On Wednesday, April 3, 2019 at 2:33:16 PM UTC-7, awokd wrote:
> Nicklas Williams wrote on 4/3/19 9:30 PM:
> > Thanks for your help.  The issue here is that I cannot get to the loader.  
> > If i boot to USB it works after the kernel params listed above, but this 
> > model cannot do legacy boot to internal drives.  I have to do UEFI install 
> > but UEFI fails before I get to anaconda.  I need to be able to change the 
> > original ISO somehow to add the kernal params to turn off nouveau but 
> > because ISO is a read only file, it doesn't work.  I tried copying the 
> > files to a folder, then making an ISO from the folder, but that method does 
> > the same thing.  It will attempt to boot, then either go to the "dracut 
> > timeout" screen, or it just goes to a blank screen with no further 
> > activity.  Very frustrating, since I bought this laptop specifically to use 
> > Qubes, now im finding out that I can't install it.  Is there any way to 
> > edit the qubes ISO file so I dont have the nouveau driver activated?  Every 
> > method ive tried tells me "read only file"
> > 
> 
> Try "apt install isomaster" in Debian.

Thanks Awokd.  I see you responding to a lot of threads and its greatly 
appreciated.  I'll try with debian and let you all know the results.

-- 
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/09116376-ce8c-4dca-baa3-04a17fd97f38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['awokd' via qubes-users]

Nicklas Williams wrote on 4/3/19 9:30 PM:

Thanks for your help.  The issue here is that I cannot get to the loader.  If i boot to USB it 
works after the kernel params listed above, but this model cannot do legacy boot to internal 
drives.  I have to do UEFI install but UEFI fails before I get to anaconda.  I need to be able to 
change the original ISO somehow to add the kernal params to turn off nouveau but because ISO is a 
read only file, it doesn't work.  I tried copying the files to a folder, then making an ISO from 
the folder, but that method does the same thing.  It will attempt to boot, then either go to the 
"dracut timeout" screen, or it just goes to a blank screen with no further activity.  
Very frustrating, since I bought this laptop specifically to use Qubes, now im finding out that I 
can't install it.  Is there any way to edit the qubes ISO file so I dont have the nouveau driver 
activated?  Every method ive tried tells me "read only file"



Try "apt install isomaster" in Debian.

--
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/e689948d-5b62-a440-bc45-9a0ccac578f6%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

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

[Nicklas Williams]

Thanks for your help.  The issue here is that I cannot get to the loader.  If i 
boot to USB it works after the kernel params listed above, but this model 
cannot do legacy boot to internal drives.  I have to do UEFI install but UEFI 
fails before I get to anaconda.  I need to be able to change the original ISO 
somehow to add the kernal params to turn off nouveau but because ISO is a read 
only file, it doesn't work.  I tried copying the files to a folder, then making 
an ISO from the folder, but that method does the same thing.  It will attempt 
to boot, then either go to the "dracut timeout" screen, or it just goes to a 
blank screen with no further activity.  Very frustrating, since I bought this 
laptop specifically to use Qubes, now im finding out that I can't install it.  
Is there any way to edit the qubes ISO file so I dont have the nouveau driver 
activated?  Every method ive tried tells me "read only file"

-- 
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/2850d18c-3838-4b4b-ad7d-14718eba1906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

['awokd' via qubes-users]

cube...@tutamail.com wrote on 4/3/19 6:26 PM:


Thank you for your suggestion. I have given it a try but unfortunately the 
systems hasn't yet been restored. (I'm guessing you referred to the following 
commands to enter rescue mode: pkill -9 anaconda;  anaconda --rescue; )

I also tried mounting my Qubes disk in LinuxMint, using commands:
cryptsetup luksOpen /dev/sda2 qubes-disk;
then pvscan, pvdisplay, vgscan, vgdisplay, lvscan, lvdisplay.

These allowed me to see logical structure of my qubes_dom0 volumes, volumes 
representing AppVM, but I was unsuccessful mounting these volumes to get access 
to the data.
Comman 'lvscan' shows LV status next to each volumes, and  only 'swap' was 
marked as active. Everything else was 'NOT active', including 'root', 'pool00', 
and AppVM volumes.

Do you, or anybody else, have any idea how to proceed? I must recover the data. 
I hope they didn't get corrupted, only the access point has gone missing.

You're in the right area, but I don't see a "vgchange -ay" in your list 
of commands?



--
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/70a61521-d7dc-9e17-eae1-7872d2e79f95%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Still don't understand how Debian-9 template is connected to Whonix templates

['awokd' via qubes-users]

jrsmi...@gmail.com wrote on 4/3/19 6:55 PM:

So I can safely delete the Debian-9 template?


Correct, that won't impact your Whonix ones.

--
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/b828daa1-d0c3-af6d-22ee-7f4b98f5bc1d%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Still don't understand how Debian-9 template is connected to Whonix templates

[jrsmiley]

So I can safely delete the Debian-9 template?

-- 
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/4ba5ae55-6073-473e-8da2-31ddd1f990e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

[cubecub]

Apr 3, 2019, 4:40 PM by jayen.de...@gmail.com:

> On Wednesday, April 3, 2019 at 7:52:38 PM UTC+5:30, cub...@tutamail.com wrote:
>
>> Hi,
>>
>> Please help! 
>>
>> I've shut down my Qubes 4 system last night and it wouldn't restart. After 
>> providing my disk encryption password the system is stucks at:
>>
>>
>>
>> "[ OK ] Reached target Basic System. "
>>
>> followed by numerous line with:
>>
>> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
>> timeout scripts
>>
>> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
>> timeout scripts
>>
>> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
>> timeout scripts
>>
>> .
>>
>> [] dracut -initqueue[338]: Warning: Could not boot.
>>
>> [] dracut -initqueue[338]: Warning: /dev/mapper/qubes_dev0-root does not 
>> exist
>>
>> [] dracut -initqueue[338]: Warning: /dev/qubes_dev0/root does not exist
>>
>> Starting Dracut Emergency Shell...
>>
>>
>>
>> This is very strange. I haven't even updated 'dom0' lately and the system 
>> shut down clean. But it just wouldn't start today. 
>>
>>
>>
>> If I can't recover the Qubes-OS system as the whole please help me retrieve 
>> data/files that I have in my AppVM volumes. How can this be done. 
>>
>>
>>
>> This is an emergency for me and I would be immensely grateful for somebody's 
>> help to either fix systms boot, so that it could start again, OR help to 
>> connect my system disk to other OS and retrieve the data. 
>>
>>
>>
>> Thank you !
>>
>> cubecub
>>
>
> Have you tried rescue mode using installation media? You can try it and I 
> believe it should help. I had used rescue mode to edit my xen.cfg file which 
> had helped to me boot the system one again in case I had passed some wrong 
> parameters to xen.cfg. You can access rescue mode by pressing ctl+alt+f5. May 
> be it will help you. 
>

Hi, 
Thank you for your suggestion. I have given it a try but unfortunately the 
systems hasn't yet been restored. (I'm guessing you referred to the following 
commands to enter rescue mode: pkill -9 anaconda;  anaconda --rescue; )

I also tried mounting my Qubes disk in LinuxMint, using commands:
cryptsetup luksOpen /dev/sda2 qubes-disk;
then pvscan, pvdisplay, vgscan, vgdisplay, lvscan, lvdisplay. 

These allowed me to see logical structure of my qubes_dom0 volumes, volumes 
representing AppVM, but I was unsuccessful mounting these volumes to get access 
to the data. 
Comman 'lvscan' shows LV status next to each volumes, and  only 'swap' was 
marked as active. Everything else was 'NOT active', including 'root', 'pool00', 
and AppVM volumes. 

Do you, or anybody else, have any idea how to proceed? I must recover the data. 
I hope they didn't get corrupted, only the access point has gone missing. 

Please help with other suggestions or hopefully working solutions. 

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/6079c7b0-acaa-4d1f-8c60-caec837d4...@googlegroups.com
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

Re: [qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

On Wed, Apr 3, 2019 at 1:53 PM Ryan Tate  wrote:

> That said, I would just note --  Files from dom0 do traverse other VMs
> in all the scenarios we've discussed. I expect in backup/restore
> scenario they are encrypted as they transit, for example, sys-usb. But
> I don't know of any reason this could not be the case for random files
> you want to export -- you would encrypt in gpg symmetric mode in dom0
> with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
> wherever and out into the world.

As I should have suspected, using the official backup-restore tools
does get you integrity checks (and perhaps better encryption?)
compared to this more basic technique I outlined, so I'm not
suggesting anyone run out and do it.

https://www.qubes-os.org/doc/backup-emergency-restore-v4/

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

Re: [qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

Thanks for the thoughtful replies (I just now saw Chris' from before).
Also thank you Andrew for making a Github issue!

It sounds like there is at least some common ground on providing
smoother restore as an option, which I appreciate. If it's too much to
add code to that effect anytime soon (I know this is a small project)
I wonder if there could be some documentation just that's ok to
wholesale replace the new dom0 user home dir with the old one and
maybe giving the relevant shell command?

Personally, I expected the old dom0 to be the default and would vote
that it be the default as I wonder if these other scenarios (potential
compromised dom0, moving files to new machine) are really more common
than restore for more mundane reasons.BUT that said I think just
presenting the choice of whether to write old or new dom0 will provide
sufficient clarity for most people regardless of the default. I expect
most people look at the options pretty carefully when restoring.

Replying to some specific points:

On Tuesday, April 2, 2019 at 7:52:19 AM UTC-4, Chris Laprise wrote:
> The current method prevents an unsafe restore in the event that the
> system was reinstalled due to a compromise (or suspicion thereof). This
> change was made shortly after Qubes project started promoting the idea
> of "paranoid mode" restore, with which it fits very well.

That seems reasonable as the default if it is expected that this is
usually why people are restoring. I wonder if it's not more common
that people restore for other reasons, in which case I'd argue that
the current behavior should just be an option. But as I said above,
it's probably not a big deal - just giving people a choice would
probably lead to the right outcome.

On Wed, Apr 3, 2019 at 1:01 AM Andrew David Wong  wrote:
>
> In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
> dom0's home and VMs from one machine to another. This is because it is a
> violation of the Qubes security model to move files from a less trusted
> VM to dom0, and every other VM is, by definition, less trusted than
> dom0. Therefore, qvm-backup[-restore] is the only official, secure way
> to move files into dom0.

Fair point, I forgot how hard Qubes makes it to move files into dom0.

That said, I would just note --  Files from dom0 do traverse other VMs
in all the scenarios we've discussed. I expect in backup/restore
scenario they are encrypted as they transit, for example, sys-usb. But
I don't know of any reason this could not be the case for random files
you want to export -- you would encrypt in gpg symmetric mode in dom0
with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
wherever and out into the world.

Admittedly, you would then need to jump through hoops to go back into
dom0, so it can't be described as "the usual way" as I did.

> All you had to do was move everything out of the restored subdirectory:
>
>   $ mv home-restore-2019-04-01-etc/* .   # move all normal files out
>   $ mv home-restore-2019-04-01-etc/.* .  # move all hidden files out
>
> Simple, quick, and easy, with no weird hoops to jump through.
>
> Now, don't get me wrong. I understand perfectly well that it's only
> "simple, quick, and easy" _if you know what to do_ and that this will
> _not_ be obvious to many users. But that's precisely why I suggested
> that it should be an option via qvm-backup-restore and the GUI tool.
> Make it discoverable so that users can understand that there are two
> possible outcomes and choose the one they want, then do it for them.

Yes, agree, thanks for finding the common ground.

> > If people seem open to a change I’ll file an enhancement request.
> >
>
> Since I was already writing all this, I just went ahead and opened an
> issue for it:
>
> https://github.com/QubesOS/qubes-issues/issues/4946

Thanks again for doing this.

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

[qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

[Jayen Desai]

On Wednesday, April 3, 2019 at 7:52:38 PM UTC+5:30, cub...@tutamail.com wrote:
> Hi,
> 
> Please help! 
> 
> I've shut down my Qubes 4 system last night and it wouldn't restart. After 
> providing my disk encryption password the system is stucks at:
> 
> 
> 
> "[ OK ] Reached target Basic System. "
> 
> followed by numerous line with:
> 
> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
> timeout scripts
> 
> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
> timeout scripts
> 
> [] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
> timeout scripts
> 
> .
> 
> [] dracut -initqueue[338]: Warning: Could not boot.
> 
> [] dracut -initqueue[338]: Warning: /dev/mapper/qubes_dev0-root does not 
> exist
> 
> [] dracut -initqueue[338]: Warning: /dev/qubes_dev0/root does not exist
> 
> Starting Dracut Emergency Shell...
> 
> 
> 
> This is very strange. I haven't even updated 'dom0' lately and the system 
> shut down clean. But it just wouldn't start today. 
> 
> 
> 
> If I can't recover the Qubes-OS system as the whole please help me retrieve 
> data/files that I have in my AppVM volumes. How can this be done. 
> 
> 
> 
> This is an emergency for me and I would be immensely grateful for somebody's 
> help to either fix systms boot, so that it could start again, OR help to 
> connect my system disk to other OS and retrieve the data. 
> 
> 
> 
> Thank you !
> 
> cubecub

Have you tried rescue mode using installation media? You can try it and I 
believe it should help. I had used rescue mode to edit my xen.cfg file which 
had helped to me boot the system one again in case I had passed some wrong 
parameters to xen.cfg. You can access rescue mode by pressing ctl+alt+f5. May 
be it will help 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/6079c7b0-acaa-4d1f-8c60-caec837d475b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

[cubecub]

Hi,
Please help! 
I've shut down my Qubes 4 system last night and it wouldn't restart. After 
providing my disk encryption password the system is stucks at:

"[ OK ] Reached target Basic System. "
followed by numerous line with:
[] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
timeout scripts
[] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
timeout scripts
[] dracut -initqueue[338]: Warning: dracut-initqueue timeout - starting 
timeout scripts
.
[] dracut -initqueue[338]: Warning: Could not boot.
[] dracut -initqueue[338]: Warning: /dev/mapper/qubes_dev0-root does not 
exist
[] dracut -initqueue[338]: Warning: /dev/qubes_dev0/root does not exist
Starting Dracut Emergency Shell...

This is very strange. I haven't even updated 'dom0' lately and the system shut 
down clean. But it just wouldn't start today. 

If I can't recover the Qubes-OS system as the whole please help me retrieve 
data/files that I have in my AppVM volumes. How can this be done. 

This is an emergency for me and I would be immensely grateful for somebody's 
help to either fix systms boot, so that it could start again, OR help to 
connect my system disk to other OS and retrieve the data. 

Thank you !
cubecub



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

Re: [qubes-users] Attaching USB-stick to HVM (Windows7)

['awokd' via qubes-users]

jagro...@gmail.com:

I've been trying to attach a USB-stick to my Windows HVM. First I used the 
device-manager-icon but got following:

Error
Attaching device SanDisk. to win7 failed. Error: Domain 'win7': qrexec 
not connected.

With both running and not running HVM (win7) I've tried this:
[bm@dom0 ~]$ qrexec-client -d win7 user:bash

Result:
connect: No such file or directory

Any idea?

You need to install QWT in your HVM. It can be tricky, so clone it first 
so you'll have something you can roll back to if there's problems.


--
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/57a1d66d-074b-1ca1-202e-06a5ed47d3bc%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Vikings D8

['Vikings GmbH' via qubes-users]

Vikings D8 (rebranded ASUS KCMA-D8) running Libreboot stable 20160907.

NOTE: Onboard ASpeed VGA device not tested.
-- 
Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet
Thomas Umbach

Web: https://store.vikings.net/

Follow us on Twitter: https://twitter.com/vikingslibre

Vikings GmbH
Sauerackerweg 14, 60529 Frankfurt/Main, Germany
Register Court: AG Frankfurt am Main
Register No.: HR B 84497, CEO: Thomas Umbach
Tax Office: Frankfurt am Main, VATIN: DE254094338

GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5

-- 
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/673fd31c-5185-f85b-1ac2-4b98abf9ed3c%40vikings.net.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-ASUS-KCMA_D8-20190403-064530.cpio.gz
Description: application/gzip


Qubes-HCL-ASUS-KCMA_D8-20190403-064530.cpio.gz.sig
Description: PGP signature


Qubes-HCL-ASUS-KCMA_D8-20190403-064530.yml
Description: application/yaml


Qubes-HCL-ASUS-KCMA_D8-20190403-064530.yml.sig
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

[qubes-users] Attaching USB-stick to HVM (Windows7)

[jagrobot]

I've been trying to attach a USB-stick to my Windows HVM. First I used the 
device-manager-icon but got following: 

Error
Attaching device SanDisk. to win7 failed. Error: Domain 'win7': qrexec 
not connected.

With both running and not running HVM (win7) I've tried this:
[bm@dom0 ~]$ qrexec-client -d win7 user:bash

Result:
connect: No such file or directory

Any idea?

-- 
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/ae8f264c-649d-4885-9273-1dc2c8d298ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Activation of USB in Windows7 HVM

[jagrobot]

I've been trying to attach a USB-stick to my Windows HVM. First I used the 
device-manager-icon but got following: 

Error
Attaching device SanDisk. to Win7 failed. Error: Domain 'Win7': qrexec 
not connected.

With both running and not running HVM with the name 'win7' I've tried this:
[bm@dom0 ~]$ qrexec-client -d win7 user:bash

Result:
connect: No such file or directory

Any idea?

-- 
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/1b22f9c3-5ba7-445d-8adb-9fd52bf3f018%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.