Re: [qubes-users] Qubes VM Manager freezeup

['P R' via qubes-users]

Hello James,

Am 12.07.2017 4:08 vorm. schrieb "James" :

Does anyone know what might be causing this, how I might fix it, or
what information I could provide to help diagnose it?
[...]


I am experiencing the same delays when starting a VM in Qubes: the whole
GUI freezes for a few seconds, even when there are plenty ressources
available (Core i7, 4 physical Cores, 2.8Ghz, 32 GB RAM, SSD).
Qubes is also showing the window when shutting down sys-net (Message:
shutdown takes longer, should I kill the VM).

Solving the GUI freezes would be great.

- PhR

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

[qubes-users] Qubes VM Manager freezeup

[James]

Does anyone know what might be causing this, how I might fix it, or
what information I could provide to help diagnose it?
(There should be an image attached to this message)

4.4.67-13.pvops.qubes.x86_64 w/ Xen 4.6.5

Nothing much(?) has been done to dom0 as far as I know, other than updates.

(Also, when powering off and rebooting, sometimes(/usually/always) it
seems to hang for upwards of the 3-minute hard timeout, something
about "Waiting for dom0 startup setup"…not sure if that's a related
issue or what, but I thought I should mention it in case it's relevant
to the main topic of this post.)

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

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

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-07-11 13:30, Nick Geary wrote:
> I'm not planning to use it for dual boot. Would like to have the additional 
> space to create larger VM's stored on the second drive. 
> 
> To be able to clone decent sized Ubuntu & Windows templates. 
> 
> So far I've attempted to format the disk through fdisk as an extended 
> partition. Then used mkfs.ext3 to format the drive. But when it comes to 
> putting ext3 type into fstab. it returns as an unrecognized type.
> 
> I then took a crack at these instructions:
> 
> https://www.qubes-os.org/doc/custom-install/#manual-encryption-configuration-r31
> 
> The most efficient way honestly, might be backing up all the VM's to an 
> external disk, wiping the OS, and installing with both drives formatted 
> together on initial installation. (would need to buy the drive)
> 
> It will be good experience to get it configured manually. But to pick up 
> where I left off required decryption and opening of the luks volume by 
> command line. 
> 
> What is the best method for extending the LVM within Qubes?
> 
> So 
> 
> 1) Lukas partition
> 2) mkfs.ext3
> 3) fstab & crypttab
> 
> -N
> 

https://www.qubes-os.org/doc/secondary-storage/

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

iQIcBAEBCgAGBQJZZX6YAAoJENtN07w5UDAwMi0P/3JSk/9YPDyQUTMyzn+91jZh
9sKNi1PrALf0jHvuJhVqfBydr5/3SjwjEJg4HKzB2kH5SvDutQOqawkvZEHglvGL
QfFkdMwo++QAjf640OfDCsxEddCtRmg5yxg7L6B5JA1Qrcmcjd3WeuJlub60u7D5
xktazTWlQmc+kTwnjxVAsDX1VFUTTkPDvDmdVID5F3vaScGT9Ord4hFKc1vaYzm1
iKTuqCUl0fixnlc3jsDf7ernoZqLF01aj41mjY5NJ+7B04Z06+yPcRwj9nglUQfp
zSRtn3rhRU5gLFzgIDVW7zKp/UORxuudunzjtX8V4X98QPlAeqYkJpgeKo8HhOHQ
Kj/0yf3RcEgQnwTk/FsdSaFCP82gI56lmOOa4VDjzO+J5bktEntQRaQKHY8xGxGC
7QgpzUr1p01iYufBUocrkq+YG2XP8o9gw9xMUaQ8AMC5US3dZK7kz3+ctLe2V1oP
K3y3X+wGYR3ccE7+HU2rl1dLj2FQ2FU9OhAFpi5i9EWlX2ZquD2wC2HRftBiO2Hr
CUEK+J60ttLnVXpcD6XNb2zcIHmTeT8+Egu7hjQdpmwQXz/At1mrWa9owG+6dhnl
+ao+54bZJ22aEFYMpflE4vaVwZF+AT0r3WpldyJflEmYTjdfRV4nq0erb82Rj9R6
X5pChb4C+ntuHB55FmdF
=f66q
-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/bd1c86a7-2671-a8ec-30ad-e560f9589ead%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[Salmiakki]

I liked this idea, so I wanted to try.

This seems to work:

in /etc/qubes/autostart/qubes-pulseaudio.desktop.d/30_qubes.conf 
put this:

[Desktop Entry]
OnlyShowIn=X-AppVM;

Now only AppVMs have audio.
Putting a name in there did not work for me but going to an AppVM and doing 
this:
mkdir ~/.config/autostart
cp /etc/xdg/autostart/pulseaudio.desktop ~/.config/autostart/

and adding X-GNOME-Autostart-enabled=false
to that worked!

-- 
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/0d5e11a0-c204-4709-9f8a-9e863b1c79ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[Salmiakki]

And according to the README in /etc/qubes/autostart you can override everything 
from within the VM using ~/.config/autostart:

> This mechanism overrides only content of /etc/xdg/autostart, files placed in
> ~/.config/autostart are unaffected, so can be used to override settings per-VM
> basis.

-- 
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/22de68fc-a670-43ad-94a5-66b9dadef72c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[Salmiakki]

On Wednesday, 12 July 2017 00:58:11 UTC+2, daltong defourne  wrote:

> Is it possible to do this on a per-app-VM basis and not on a per-template 
> basis?
> 

> > TemplateVMs. There is a "OnlyShowIn" that can be used to define in what VMs
> > the application should autostart, either **by name** or type
> > (appvm/templatevm etc).

Shouldn't that cover your use-case?

-- 
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/06883438-8a36-47a4-96fe-7aef9ca8433c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Unman]

On Tue, Jul 11, 2017 at 07:36:08PM +, 
baldric-q7wo9g+UVklWk0Htik3J/w...@public.gmane.org wrote:
> Chris Laprise:
> > On 07/10/2017 10:56 AM, Unman wrote:
> >> This simply isn't true - it's clear from the Purism statement that Librem
> >> 13v2 has not been entered for certification.
> >>
> >> Since Qubes 4 is still at an early stage of development (not even RC1),
> >> there is little prospect of ANY machine being certified for it at this
> >> stage.
> >> The fact that there are issues with Coreboot now is irrelevant - there
> >> are issues with all sorts of things in 4 as it stands. But it was stated
> >> that Qubes certified hardware should run on open source boot firmware,
> >> and I dont think that has changed.
> >>
> >> I dont think that Librem users have been "left in the lurch". It was
> >> made clear that the Librem13 was not likely to be certified for Qubes 4.
> >> This doesnt mean that the machine wont work with 4 - if you look at the
> >> requirements page for 4, minimal are VT-x,VT-d SLAT.
> >> A quick look at the HCL and the purism site confirms that the 13 has
> >> CoreI5 6200U, and that CPU does have VT-x, VT-d and SLAT.
> >> So in what sense does OP have grounds for feeling  "left in the lurch"?
> >>
> >> unman
> >>
> > 
> > And I think its worth re-stating that Qubes wants a formal certification
> > process (which Purism chose not to continue).
> > 
> > Qubes should be lauded for creating this process and standing by it; It
> > guards against the erroneous perceptions people have about "PC hardware"
> > being a uniform blank canvas for creating an OS.
> > 
> 
> 
> Sorry guys, I realise you are a couple of die-hard Qubesmen and are
> desperately trying to defend Qubes reputation, but you need to remove
> the blinkers and examine the facts.
> 
> Fact 1/ in my original post I stated "For those of us who followed Qubes
> hardware recommendations and then bought or ordered shiny new Librem 13
> laptops, you'll maybe not have noticed that qubes has silently and
> sneakily withdrawn the recommendation...".  Six months after Purism
> began taking orders for the version 2 of the Librem 13 and 12 hours
> after I posted, Andy Wong published an announcement acknowledging that
> Librem 13v2 was no longer certified by qubes. Now if that doesn't leave
> people who ordered a version2 Librem13  and just recently had it
> delivered, in the lurch - I don't know what does.
> 
> Fact 2/ In December 15 Qubes trumpeted via its News pages
> https://www.qubes-os.org/news/2015/12/09/purism-partnership/.Entitled;
> Partnering with Purism and the first Qubes-certified laptop.
> Within the document is this statement; "This begins with the
> certification of the Librem 13" - the words Librem 13 provides a link to
> https://puri.sm/librem-13. Contrary to the arguments you've posted,
> you'll notice that nowhere within the document does it specify that the
> certification covers Version 1 of Librem13 only. To the contrary,
> clicking the link takes you to Version2 of the Librem 13.
> 
> To summarise.
> Many months after Purism started taking orders for Version 2 of the
> Librem 13, Qubes formally withdrew its certification leaving users in
> the lurch. In the meantime Qubes pocketed $100 per order in commission.
> This is unforgivable, indefensible behavior.
> 

"die-hard Qubesman"? I'll take that as a compliment, it's quite catchy.

If I understand your complaint it's that Purism have sold you a laptop
which you thought was certified by Qubes, but isnt. It isnt certified
because Purism changed the specs and decided that they wouldnt submit
this model for certification.

I have no idea what the terms of the agreement were between Purism
and Qubes, nor what monies(if any) changed hands. I doubt that you do,
but perhaps you do.
I dont suppose that anyone considered what would happen if Purism
produced a new laptop with different specs but bearing the same name as
the certified one. At best it seems naive on their part.

If you told Purism you wanted the laptop because its Qubes certified,
you have a claim against them and can get a refund. If you can otherwise
show you were misled your claim is against Purism. I dont know what
jurisdiction you are under but it seems to me a claim of passing off
would succeed.

In any case, you still havent explained in what way you have been left
in the lurch. You have a laptop that seems to be compatible with Qubes
3.  It looks as if it will be compatible with 4, but there was never
any guarantee of that.

Anyway, I have no interest in "defending Qubes reputation"; nor any
interest in Purism. If you have specific problems with using Qubes on
your shiny new Librem 13, I'll try to help. 

cheers

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 

Re: [qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[daltong defourne]

Thanks!

Is it possible to do this on a per-app-VM basis and not on a per-template basis?

On Tuesday, July 11, 2017 at 12:37:49 PM UTC+3, Noor Christensen wrote:
> On Tue, Jul 11, 2017 at 01:40:34AM -0700, daltong defourne wrote:
> > All other commands in rc. local are executed as expected, so it's not
> > a rc.local issue per se, but rather maybe something like pulseaudio
> > startup thing.
> > 
> > Any pointers as to how to reliably "de-pulse-ize" VMs at startup?
> > 
> > P.S.: uninstalling pulseaudio from template breaks things for me on
> > several VMs and is not an option.
> 
> You might want to take a look at /etc/qubes/autostart directory in your
> TemplateVMs. There is a "OnlyShowIn" that can be used to define in what VMs
> the application should autostart, either by name or type
> (appvm/templatevm etc).
> 
> Check the README.txt in that directory for some guidelines, and look at
> the existing files for examples.
> 
> -- noor
> 
> |_|O|_|
> |_|_|O|  Noor Christensen  
> |O|O|O|  

-- 
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/85d68d55-909f-4e1c-8b1e-6b1ccf05f336%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Storage Qube" or otherwise share folders of a drive selectively?

[Florian Brandes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/11/2017 10:08 PM, codegee...@gmail.com wrote:
> Right now, I have a lot of stuff all just "consolidated" on one hard drive.
> /var/storage/{Anime,public_html,Documents,Pictures,.config/{pale\ 
> moon,deluge}} and so on.
> 
> But, obviously, I want to try with Qubes to have some isolation from my 
> webserver, perhaps have my Torrent client not be able to read my browser 
> profile, etc.
> 
> I'm thinking of setting up perhaps something like a "Storage Qube", which 
> will have the storage drive permanently attached, and be in charge of 
> managing permissions and serving the folders to authorized VMs via…NFS? SSHFS?
> 
> The catch is, I want to try to have it at least be reasonably performant 
> (i.e., my browser profile is there currently), and preferably not make it 
> "too" hacky/inelegant, in case the Qubes devs roll their own 
> guided/integrated system for this.
> 
> DOES Qubes have a facility to do this currently?
> 

Hi,

I'm new to qubes, so excuse me if I may sound stupid, but wouldn't it be easier 
to include your storage space in your overall qubes setup (maybe as an LVM), so 
that you would just use your qubes and extend their personal disk space? This 
way you could take advantage of the isolation provided by qubes without the 
hassle of setting up a dedicated storage VM which would also need to check 
permissions.

On the other hand you could probably set up a storage VM and serve the files 
via NFS on a IP basis. Since every qube has a unique IP address you could make 
sure that no other qube except the one you permit has access to a specific 
storage folder. 

Greetings, 

Florian 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI0BAEBCAAeBQJZZTp6FxxmbG9yaWFuLmJyYW5kZXNAZ214LmRlAAoJEKf3MHt6
BMRJ8REP/1Q1/3DYemY7X1zHtyhZ2BGTh82HXqfwSEKxJDOm4kLa60pl+JAeJuUm
INegwPw6zLLnCNnT2+aRjIB/keRJmLGs+/cJeLd3Qt0gu8BXBIitAOl4kXPxksNi
tdi5p7xmyy2opiXQakGkHGY/knWV1CowPSNAny6LL5RI+Sn0rYXZW1EvMeAoPSZs
oZrBJB3tafVA5CB7ywe25TkdszeDSFR+ZnEQn3ZbsTHbNm/LnH+BsZ+G0LUZIGLf
R6GG9d5+mQvzUOjCK/ANVdxxSGCflfvkhC2ERLu9LXNRgjh6mnrQMlJFvtiBwun4
CJ/FHIbiG692dDfEpiJ8UuXXNXKIzhsKzhXkuwEjq5+ygvimP2cAGgMLMiTGSFJ/
MUa61mY6/n2SZja5fG/Lxitw7zRKGiblRYFrjYcm1KEt4j4HC6G07icJkN9znqiN
2MKtLCt+5xlUFHvvD7Jz5KZSWqy8EfFj17WAruGBSs+qANPLw3jehTMFGUN39PDe
EYLYhDSLmJPnY0qFZR/KOG7aD3LVMTBuCLMeuxDBXd4c9NHH9hgoBfiB/l6FQObO
jlEuLcENHyHBNsGA6wtirwhPLeoCwzXZl1KUJEjp8YNz/FnKcVS1tUyGnj1reRrG
C5zJCljHaEMEw81yKRU+gNY5kZaBHwAJUsPSisfm+6KjHD7ablUB
=RDvn
-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/a6068c15-7553-4604-c6de-ad3035c16483%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] "Storage Qube" or otherwise share folders of a drive selectively?

[codegeek98]

Right now, I have a lot of stuff all just "consolidated" on one hard drive.
/var/storage/{Anime,public_html,Documents,Pictures,.config/{pale\ moon,deluge}} 
and so on.

But, obviously, I want to try with Qubes to have some isolation from my 
webserver, perhaps have my Torrent client not be able to read my browser 
profile, etc.

I'm thinking of setting up perhaps something like a "Storage Qube", which will 
have the storage drive permanently attached, and be in charge of managing 
permissions and serving the folders to authorized VMs via…NFS? SSHFS?

The catch is, I want to try to have it at least be reasonably performant (i.e., 
my browser profile is there currently), and preferably not make it "too" 
hacky/inelegant, in case the Qubes devs roll their own guided/integrated system 
for this.

DOES Qubes have a facility to do this currently?

-- 
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/c6be3032-aee8-4279-bbcb-a49f5273a7e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes silently ditches Librem

[baldric-q7wo9g+UVklWk0Htik3J/w...@public.gmane.org]

Chris Laprise:
> On 07/10/2017 10:56 AM, Unman wrote:
>> This simply isn't true - it's clear from the Purism statement that Librem
>> 13v2 has not been entered for certification.
>>
>> Since Qubes 4 is still at an early stage of development (not even RC1),
>> there is little prospect of ANY machine being certified for it at this
>> stage.
>> The fact that there are issues with Coreboot now is irrelevant - there
>> are issues with all sorts of things in 4 as it stands. But it was stated
>> that Qubes certified hardware should run on open source boot firmware,
>> and I dont think that has changed.
>>
>> I dont think that Librem users have been "left in the lurch". It was
>> made clear that the Librem13 was not likely to be certified for Qubes 4.
>> This doesnt mean that the machine wont work with 4 - if you look at the
>> requirements page for 4, minimal are VT-x,VT-d SLAT.
>> A quick look at the HCL and the purism site confirms that the 13 has
>> CoreI5 6200U, and that CPU does have VT-x, VT-d and SLAT.
>> So in what sense does OP have grounds for feeling  "left in the lurch"?
>>
>> unman
>>
> 
> And I think its worth re-stating that Qubes wants a formal certification
> process (which Purism chose not to continue).
> 
> Qubes should be lauded for creating this process and standing by it; It
> guards against the erroneous perceptions people have about "PC hardware"
> being a uniform blank canvas for creating an OS.
> 


Sorry guys, I realise you are a couple of die-hard Qubesmen and are
desperately trying to defend Qubes reputation, but you need to remove
the blinkers and examine the facts.

Fact 1/ in my original post I stated "For those of us who followed Qubes
hardware recommendations and then bought or ordered shiny new Librem 13
laptops, you'll maybe not have noticed that qubes has silently and
sneakily withdrawn the recommendation...".  Six months after Purism
began taking orders for the version 2 of the Librem 13 and 12 hours
after I posted, Andy Wong published an announcement acknowledging that
Librem 13v2 was no longer certified by qubes. Now if that doesn't leave
people who ordered a version2 Librem13  and just recently had it
delivered, in the lurch - I don't know what does.

Fact 2/ In December 15 Qubes trumpeted via its News pages
https://www.qubes-os.org/news/2015/12/09/purism-partnership/.Entitled;
Partnering with Purism and the first Qubes-certified laptop.
Within the document is this statement; "This begins with the
certification of the Librem 13" - the words Librem 13 provides a link to
https://puri.sm/librem-13. Contrary to the arguments you've posted,
you'll notice that nowhere within the document does it specify that the
certification covers Version 1 of Librem13 only. To the contrary,
clicking the link takes you to Version2 of the Librem 13.

To summarise.
Many months after Purism started taking orders for Version 2 of the
Librem 13, Qubes formally withdrew its certification leaving users in
the lurch. In the meantime Qubes pocketed $100 per order in commission.
This is unforgivable, indefensible behavior.


-- 
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/e5e3cb27-4a46-a4b9-f055-2221ea3895eb%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes silently ditches Librem

[baldric-q7wo9g+UVklWk0Htik3J/w...@public.gmane.org]

Chris Laprise:
> On 07/10/2017 10:56 AM, Unman wrote:
>> This simply isn't true - it's clear from the Purism statement that Librem
>> 13v2 has not been entered for certification.
>>
>> Since Qubes 4 is still at an early stage of development (not even RC1),
>> there is little prospect of ANY machine being certified for it at this
>> stage.
>> The fact that there are issues with Coreboot now is irrelevant - there
>> are issues with all sorts of things in 4 as it stands. But it was stated
>> that Qubes certified hardware should run on open source boot firmware,
>> and I dont think that has changed.
>>
>> I dont think that Librem users have been "left in the lurch". It was
>> made clear that the Librem13 was not likely to be certified for Qubes 4.
>> This doesnt mean that the machine wont work with 4 - if you look at the
>> requirements page for 4, minimal are VT-x,VT-d SLAT.
>> A quick look at the HCL and the purism site confirms that the 13 has
>> CoreI5 6200U, and that CPU does have VT-x, VT-d and SLAT.
>> So in what sense does OP have grounds for feeling  "left in the lurch"?
>>
>> unman
>>
> 
> And I think its worth re-stating that Qubes wants a formal certification
> process (which Purism chose not to continue).
> 
> Qubes should be lauded for creating this process and standing by it; It
> guards against the erroneous perceptions people have about "PC hardware"
> being a uniform blank canvas for creating an OS.
> 


Sorry guys, I realise you are a couple of die-hard Qubesmen and are
desperately trying to defend Qubes reputation, but you need to remove
the blinkers and examine the facts.

Fact 1/ in my original post I stated "For those of us who followed Qubes
hardware recommendations and then bought or ordered shiny new Librem 13
laptops, you'll maybe not have noticed that qubes has silently and
sneakily withdrawn the recommendation...".  Six months after Purism
began taking orders for the version 2 of the Librem 13 and 12 hours
after I posted, Andy Wong published an announcement acknowledging that
Librem 13v2 was no longer certified by qubes. Now if that doesn't leave
people who ordered a version2 Librem13  and just recently had it
delivered, in the lurch - I don't know what does.

Fact 2/ In December 15 Qubes trumpeted via its News pages
https://www.qubes-os.org/news/2015/12/09/purism-partnership/.Entitled;
Partnering with Purism and the first Qubes-certified laptop.
Within the document is this statement; "This begins with the
certification of the Librem 13" - the words Librem 13 provides a link to
https://puri.sm/librem-13. Contrary to the arguments you've posted,
you'll notice that nowhere within the document does it specify that the
certification covers Version 1 of Librem13 only. To the contrary,
clicking the link takes you to Version2 of the Librem 13.

To summarise.
Many months after Purism started taking orders for Version 2 of the
Librem 13, Qubes formally withdrew its certification leaving users in
the lurch. In the meantime Qubes pocketed $100 per order in commission.
This is unforgivable, indefensible behavior.


-- 
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/5cf60532-3b46-d448-133a-31ef9ff4b372%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

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

[Franz]

On Tue, Jul 11, 2017 at 1:00 PM, Noor Christensen <
kchr+qubes-us...@fripost.org> wrote:

> On Tue, Jul 11, 2017 at 07:58:17AM -0400, Protonmij wrote:
> > I appreciate you are trying to help, but I have no desire to try
> > unauthorised workarounds that potentially leave my machine compromised
> > or in an undefined state.
> > I think I'll wait until Qubes get the Coreboot issues resolved and
> > then formally issue a solution
> > Thank again for your efforts
>
> Sure, no problem.
>
> Mind if I ask what makes you feel that updating your GRUB configuration
> would be compromising and/or lead to undefined behavior?
>
>
I was wondering the same.  And a part Qubes developers may have much more
compelling problems related with R4 to find time to polish such minor x230
Coreboot issues. If they have a x230 at all since they once seem to like
larger screens.
Best
Fran

These GRUB commands mentioned in the workaround are the same ones that
> gets called by your Linux distribution upon upgrading the kernel, for
> example. They are standard procedure for updating the GRUB
> configuration.
>
> -- noor
>
> |_|O|_|
> |_|_|O|  Noor Christensen
> |O|O|O|  n...@fripost.org ~ 0x401DA1E0
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/qubes-users/20170711160005.cnt33zvgp7haxen2%40mail.
> For more options, visit https://groups.google.com/d/optout.
>

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

[qubes-users] Moving qubes to another drive, in preparation for cache

[motech man]

My system has a 120GB SSD and a 2TB HDD, and the HDD is totally empty now.

I want to use most of the SSD as a cache for the HDD according to 
https://groups.google.com/forum/#!msg/qubes-users/ArHTEeQAH8A/r9zzY0DLBQAJ, but 
qubes resides entirely on the SSD.

I have made a disk image of the SSD with Macrium Reflect. Can I restore that 
image onto the HDD, boot the Qubes 3.2 installer from USB or DVD, and fix 
change fstab to mount the HDD device instead of the SDD?

What other places need to be fixed? Are there other problems that lock the 
installation to the SSD I need to resolve (if even possible)?

I also have enough RAM to hold the entire filesystem, if that is any help in 
this migration process.

-- 
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/ec1fef08-3694-467f-becd-40ace133144c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nick Geary]

I'm not planning to use it for dual boot. Would like to have the additional 
space to create larger VM's stored on the second drive. 

To be able to clone decent sized Ubuntu & Windows templates. 

So far I've attempted to format the disk through fdisk as an extended 
partition. Then used mkfs.ext3 to format the drive. But when it comes to 
putting ext3 type into fstab. it returns as an unrecognized type.

I then took a crack at these instructions:

https://www.qubes-os.org/doc/custom-install/#manual-encryption-configuration-r31

The most efficient way honestly, might be backing up all the VM's to an 
external disk, wiping the OS, and installing with both drives formatted 
together on initial installation. (would need to buy the drive)

It will be good experience to get it configured manually. But to pick up where 
I left off required decryption and opening of the luks volume by command line. 

What is the best method for extending the LVM within Qubes?

So 

1) Lukas partition
2) mkfs.ext3
3) fstab & crypttab

-N

-- 
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/43069c7c-6488-4a15-9746-b3162a4487c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Trouble installing Powerpill in Arch template and curious about blacklisted package list for update

[memetic . contagion]

so I set up my pacman.conf as suggested in the documentation and I also 
initialized my keyring but I keep getting the following error:


error: xyne-x86_64: signature from "Xyne. (key #3) " is 
invalid
error: database 'xyne-x86_64' is not valid (invalid or corrupted database (PGP 
signature))

my clock is synced so that's not the issue, and I tried importing his new key 
listed on the aur page of powerpill, yet for some reason the problem persist. 
any Ideas


on an unrelated note does anyone have a list of packages/groups I should list 
in my pacman.conf in order to actually update my system again?

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

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

[Noor Christensen]

On Tue, Jul 11, 2017 at 07:58:17AM -0400, Protonmij wrote:
> I appreciate you are trying to help, but I have no desire to try
> unauthorised workarounds that potentially leave my machine compromised
> or in an undefined state.
> I think I'll wait until Qubes get the Coreboot issues resolved and
> then formally issue a solution
> Thank again for your efforts

Sure, no problem.

Mind if I ask what makes you feel that updating your GRUB configuration
would be compromising and/or lead to undefined behavior?

These GRUB commands mentioned in the workaround are the same ones that
gets called by your Linux distribution upon upgrading the kernel, for
example. They are standard procedure for updating the GRUB
configuration.

-- noor

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

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


signature.asc
Description: PGP signature

[qubes-users] Re: How do I upgrade to Fedora 26?

[Salmiakki]

So what is required to get a new template? If I understand correctly third 
parties create templates for other distros as well, right?

-- 
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/92eb354f-d593-432d-96e2-5ce50327df21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How do I upgrade to Fedora 26?

[Foppe de Haan]

On Tuesday, July 11, 2017 at 5:06:44 PM UTC+2, Salmiakki wrote:
> Since it just came out I would like to know if it is safe to upgrade or if 
> there are specific things that should be taken into account.
> 
> Can the same instruction as for the upgrade from 23 to 24 be used?

You can if/when a fc26 folder appears here: 
https://ftp.qubes-os.org/repo/yum/r3.2/current-testing/vm/
(But don't hold your breath. :) )

-- 
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/03dd99a7-5a5c-4f06-a436-e17fddffcddb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How do I upgrade to Fedora 26?

[Salmiakki]

Since it just came out I would like to know if it is safe to upgrade or if 
there are specific things that should be taken into account.

Can the same instruction as for the upgrade from 23 to 24 be used?

-- 
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/53e3b2c4-7640-45b3-9571-843399c03f3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Dell Studio XPS 435MT w/ Radeon HD 7870 GHz Edition

[agentorange]

I was unsure what to put in the "chipset-short" or "link" fields. The 
motherboard is made by Foxconn AFAICT, but it's an OEM product for Dell 
so they don't have any Official Link for it.


(It *seems to* have an X58 northbridge and an ICH10 southbridge: 
http://www.findlaptopdriver.com/dx58m01/ )


The GPU is aftermarket, 
http://www.sapphiretech.com/productdetial.asp?pid=58D84CE3-3BB0-46E0-981A-B86ED31CA295
(The machine has no integrated GPU, and I am unsure what the original 
add-in GPU was)


I hope this information is useful!

--
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/05f4ba459afa70f20ce661fe0e0a438c%408chan.co.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Dell_Inc_-Studio_XPS_435MT-20170711-090912.cpio.gz
Description: GNU Zip compressed data
---
layout:
  'hcl'
type:
  'desktop'
hvm:
  'yes'
iommu:
  'no'
slat:
  'yes'
tpm:
  'no'
remap:
  'no'
brand: |
  Dell Inc.
model: |
  Studio XPS 435MT
bios: |
  1.1.4
cpu: |
  Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
cpu-short: |
  Intel i7-920
chipset: |
  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port [8086:3400] (rev 12)
chipset-short: |
  Intel X58
gpu: |
  Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn XT [Radeon HD 7870 GHz 
Edition] [1002:6818] (prog-if 00 [VGA controller])
gpu-short: |
  Radeon HD 7870 GHz Edition
network: |
  Intel Corporation 82567LF-2 Gigabit Network Connection
memory: |
  8183
scsi: |
  WDC WD10EZEX-22B Rev: 1A01
  Hitachi HUA72303 Rev: A580
usb: |
  8
versions:

- works:
'yes'
  qubes: |
R3.2
  xen: |
4.6.5
  kernel: |
4.4.67-13
  remark: |
No problems, except that I had to disable /dev/snd/{hwC1D0,controlC1} until 
PulseAudio was updated
  credit: |
squeegily
  link: |
FIXLINK

---

[qubes-users] Viability of secrets vaults

[AntiTree]

We have KeePassX as the preferred password storage system when making
vaults but I wonder if something like Hashicorp Vault might be able to
provide additional security properties.

The benefit is that there's an audit trail, you can expire passwords, you
can set fine-grain controls on what VM's would have the password, MFA can
be supported, and others I'm sure.

Qubes API could query the vault (via IPC not network) and prompt the user
to allow access (similar to how GPG segregation works). Vault passwords
could be sent to system seamlessly (only 1 time) and keep a ledger of where
that password has been used. You'd still want to classify vaults based on
work, personal, secret based on the values of course.

The goal would be to make secret saving (password, ssh keys, certificates)
more managed so you can keep track of which VM accessed what.

I'm wondering if this would impact the threat model, be of value at all,
and even worth investigation? Are there others that have tried to do a
dedicated keyring type secrets storing application?

AntiTree

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

Re: [qubes-users] Safely use USB keyboard and untrusted USB devices with only 1 USB controller?

[Andres MRM]

[2017-05-23 15:18] Vít Šesták:

> So, I've created DVM-like sys-usb and it the first working version was easier 
> than I thought. Just make /var/lib/qubes/servicevms/sys-usb/private.img an 
> empty file. I have renamed the original file and performed "touch 
> private.img".
> 
> VM sys-usb then still boots and works as USB input proxy. It does not run X11 
> apps until I create+chown /home/user and perform systemctl restart 
> qubes-gui-agent.service, but it does not matter so much.

Thanks for the tip! I did it and hope it's working.
But now sometimes I need to "replug" mouse or/and keyboard after boot for them
to 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/149977468708.5204.3258625358229903159%40localhost.localdomain.
For more options, visit https://groups.google.com/d/optout.

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

['Protonmij' via qubes-users]

I appreciate you are trying to help, but I have no desire to try unauthorised 
workarounds that potentially leave my machine compromised or in an undefined 
state.
I think I'll wait until Qubes get the Coreboot issues resolved and then 
formally issue a solution
Thank again for your efforts

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

>  Original Message 
> Subject: Re: Fw: Re: [qubes-users] Re: Qubes 4 Fails to Boot With Coreboot
> Local Time: July 11, 2017 9:27 AM
> UTC Time: July 11, 2017 9:27 AM
> From: kchr+qubes-us...@fripost.org
> To: qubes-users@googlegroups.com 
> On Tue, Jul 11, 2017 at 04:52:27AM -0400, "Protonmij" via qubes-users wrote:
>> > The most significant fact about my post appears to have been
>> > overlooked - my x230 with Coreboot onboard boots all Linux distros
>> > I"ve tried, including;Tails, Debian, Fedora etc. Why does it not
>> > boot Qubes? Is there something special I need to do to get Qubes to
>> > boot. If so, I suggest Qubes post that installation information to
>> > the wider community.- after all Qubes recommended Coreboot in the
>> > first place.
> Sorry, I did not realize you"ve had actual installs of the other
> distributions. I was assuming you just tried to boot Live ISOs, which
> could work even though you have a broken payload/boot loader after
> SeaBIOS.
>> > From this post https://github.com/QubesOS/qubes-issues/issues/2553
>> > there is a clear acknowledgement from Qubes Developers that there
>> > are significant problems with Coreboot/Qubes compatibility.
>> > Seemingly, those problems are not being formally acknowledged by
>> > Qubes.
> In my setup, I have chosen GRUB as the Coreboot payload. Then I copied
> my grub.cfg from Qubes and added it to the Coreboot firmware.
> Could you try this and see if it works better?
> -- noor
> |_|O|_|
> |_|_|O| Noor Christensen
> |O|O|O| n...@fripost.org ~ 0x401DA1E0
> --
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/20170711092718.yfg6vkptxsv4okvg%40mail.
> 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/xmD6C2S9A9B572X_r8XGg_MSG3Tr3NxiInMAO9DhdWF4QUrW1MMF2BKhe6LJnyKFnKjbP8SePvzPORaC7nWGilSXl-TPvkE9MkOGJ_JgAyU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[Noor Christensen]

On Tue, Jul 11, 2017 at 01:40:34AM -0700, daltong defourne wrote:
> All other commands in rc. local are executed as expected, so it's not
> a rc.local issue per se, but rather maybe something like pulseaudio
> startup thing.
> 
> Any pointers as to how to reliably "de-pulse-ize" VMs at startup?
> 
> P.S.: uninstalling pulseaudio from template breaks things for me on
> several VMs and is not an option.

You might want to take a look at /etc/qubes/autostart directory in your
TemplateVMs. There is a "OnlyShowIn" that can be used to define in what VMs
the application should autostart, either by name or type
(appvm/templatevm etc).

Check the README.txt in that directory for some guidelines, and look at
the existing files for examples.

-- noor

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

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


signature.asc
Description: PGP signature

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

[Noor Christensen]

On Tue, Jul 11, 2017 at 04:52:27AM -0400, 'Protonmij' via qubes-users wrote:
> > The most significant fact about my post appears to have been
> > overlooked - my x230 with Coreboot onboard boots all Linux distros
> > I've tried, including;Tails, Debian, Fedora etc. Why does it not
> > boot Qubes? Is there something special I need to do to get Qubes to
> > boot. If so, I suggest Qubes post that installation information to
> > the wider community.- after all Qubes recommended Coreboot in the
> > first place.

Sorry, I did not realize you've had actual installs of the other
distributions. I was assuming you just tried to boot Live ISOs, which
could work even though you have a broken payload/boot loader after
SeaBIOS.

> > From this post https://github.com/QubesOS/qubes-issues/issues/2553
> > there is a clear acknowledgement from Qubes Developers that there
> > are significant problems with Coreboot/Qubes compatibility.
> > Seemingly, those problems are not being formally acknowledged by
> > Qubes.

In my setup, I have chosen GRUB as the Coreboot payload. Then I copied
my grub.cfg from Qubes and added it to the Coreboot firmware. 

Could you try this and see if it works better?

-- noor

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

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


signature.asc
Description: PGP signature

Re: [qubes-users] Attaching non-PCI block devices to VM

[Noor Christensen]

On Tue, Jul 11, 2017 at 05:17:06AM -0400, Chris Laprise wrote:
> On 07/11/2017 04:25 AM, Noor Christensen wrote:
> > Hi,
> > 
> > I am curious if it is possible to attach "arbitrary" block devices to a
> > VM, similar to how additional disks drives can be specified for HVMs.
> > 
> > For example, let's say I have a backup disk image on dom0 that I would
> > like to read from another VM without having to copy the entire file. Is
> > this possible?
> 
> Yes, have a look at 'qvm-block -a' and 'qvm-block -A' in dom0.
> 
> Also remember you don't have to use dom0 or sys-usb as a source; you can
> specify any VM that contains the volume.

Thanks for your swift response!

-- noor

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

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


signature.asc
Description: PGP signature

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

[Noor Christensen]

On Tue, Jul 11, 2017 at 11:27:18AM +0200, Noor Christensen wrote:
> On Tue, Jul 11, 2017 at 04:52:27AM -0400, 'Protonmij' via qubes-users wrote:
> > > From this post https://github.com/QubesOS/qubes-issues/issues/2553
> > > there is a clear acknowledgement from Qubes Developers that there
> > > are significant problems with Coreboot/Qubes compatibility.
> > > Seemingly, those problems are not being formally acknowledged by
> > > Qubes.
> 
> In my setup, I have chosen GRUB as the Coreboot payload. Then I copied
> my grub.cfg from Qubes and added it to the Coreboot firmware. 
> 
> Could you try this and see if it works better?

Also, did you try the workaround mentioned in the Github issue?

https://github.com/QubesOS/qubes-issues/issues/2553#issuecomment-296442883

I remember doing this "for good measure" after flashing the firmware, so
maybe it was a crucial step...

-- noor

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

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


signature.asc
Description: PGP signature

Re: [qubes-users] Attaching non-PCI block devices to VM

[Chris Laprise]

On 07/11/2017 04:25 AM, Noor Christensen wrote:

Hi,

I am curious if it is possible to attach "arbitrary" block devices to a
VM, similar to how additional disks drives can be specified for HVMs.

For example, let's say I have a backup disk image on dom0 that I would
like to read from another VM without having to copy the entire file. Is
this possible?

-- noor

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



Yes, have a look at 'qvm-block -a' and 'qvm-block -A' in dom0.

Also remember you don't have to use dom0 or sys-usb as a source; you can 
specify any VM that contains the volume.


--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5fc7a8f4-53d6-5b7b-afc8-834cdaf9f603%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

[Stephan Marwedel]

I was able to determine the cause of the problem. After having changed 
the label by editing xen.cfg as described the following needs to be done 
in addition before the media can be used on an UEFI system to install Qubes:


5. Unmount the USB media, but leave it connected to the machine. 
Assuming that the USB device is named /dev/xvdi, execute the following 
command:


dosfslabel /dev/xvdi1 BOOT

This creates a label name that the UEFI bootloader uses to identify the 
root image. Now the media can be used to install Qubes 3.2.


On 07/10/2017 06:46 PM, Stephan Marwedel wrote:

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

Starting Dracut Emergency Shell...

Warning: /dev/root does not exist

Entering emergency mode

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

Regards,
Stephan

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

I recently had some success install Qubes 3.2 on a lenovo p51, booting
UEFI.  I went through a lot of a trial and error in the process.  I'm
hoping this post can save others some time.  I've seen in other
threads some struggling to get Qubes working with UEFI firmware.

I intended to save my command history to disk so that I could post
step-by-step exactly what to do.  But I must have been in a dispvm at
the time, because now I can't find that history.  So the following is
from memory and not precise.

I tried every trick I could find related to Qubes UEFI installation,
and thinkpad troubleshooting.  What finally worked does not appear to
be documented in any of the Qubes documentation.  Qubes uses Fedora's
installer, Anaconda, and the following approach is documented on
Fedora's wiki.

1. Follow Qubes install guide up to the `dd` command.  Don't write to
usb with `dd`.
https://www.qubes-os.org/doc/installation-guide/

2. Instead, use Fedora's `livecd-iso-to-disk` tool.  You'll need the
`livecd-tools` package.  See
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29


I don't recall for certain exactly what I passed to
`livecd-iso-to-disk`.  Try this:

 sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso
/dev/xvdi

The media as written will not quite boot, yet.  Qubes EFI boot is
configured to find a label "Qubes-R3.2-x86_64", but the media written
by the livecd tool is labelled "BOOT" (and the filesystem does not
support the longer label, so the --label option would not help).

3. Mount the usb media (/dev/xvdi in the example above)

4. Edit xen.cfg.  If I recall correctly, `/EFI/BOOT/xen.cfg`.

In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64`
with `LABEL=BOOT`

You should now have install media that work on UEFI firmware!


After install, I recommend upgrading kernel version for recent
hardware.  I.e. with

 sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
kernel-qubes-vm






--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/76cb74a9-27f3-1694-a597-a09ed6ea48ca%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Completely disabling pulse audio (playback and record) in service VMs that don't need sound

[daltong defourne]

Hi!

Basically, I want to disable pulseaudio for stuff like firewall VM and VPN VM 
and the like.

They don't need it and it makes pavucontrol pannel a mess.

I tried just doing a 

sudo pactl exit

in terminal of VMs that don't need sound and it works like a charm

HOWEVER

inserting a 
pactl exit
line into 
/rw/config/rc.local
has no effect pulse still starts after reboot and the VM is still seen in 
pavucontrol)

All other commands in rc. local are executed as expected, so it's not a 
rc.local issue per se, but rather maybe something like pulseaudio startup thing.

Any pointers as to how to reliably "de-pulse-ize" VMs at startup?

P.S.: uninstalling pulseaudio from template breaks things for me on several VMs 
and is not an option.

-- 
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/fc1b638f-66c6-4a52-8412-31121dd00ce2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Noor Christensen]

On Mon, Jul 10, 2017 at 04:09:09PM -0400, Chris Laprise wrote:
> On 07/10/2017 03:15 PM, yreb-qusw wrote:
> > On 07/09/2017 11:56 PM, Chris Laprise wrote:
> > And I use suspend function daily, and it's a bit hassle to get the VPNs
> > up and running again, even with the launcher workaround,  very often I
> > must use the launcher rc.local  multiple times , and ping to see if it
> > works, and quite often  they don't restart  properly
> 
> This has become a problem with newer openvpn versions: It appears to give up
> due to an internal error instead of reconnecting.
> 
> My VPN support project solves this by setting up a systemd service for the
> VPN; this forces openvpn to restart after it exits. It also makes it more
> manageable via systemctl start/stop/restart/status etc...
> 
> https://github.com/tasket/Qubes-vpn-support

Really useful, thanks for the contribution!

-- noor

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

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


signature.asc
Description: PGP signature

[qubes-users] Attaching non-PCI block devices to VM

[Noor Christensen]

Hi,

I am curious if it is possible to attach "arbitrary" block devices to a
VM, similar to how additional disks drives can be specified for HVMs.

For example, let's say I have a backup disk image on dom0 that I would
like to read from another VM without having to copy the entire file. Is
this possible? 

-- noor

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

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


signature.asc
Description: PGP signature