[qubes-users] Re: Cannot execute qrexec-daemon

2018-01-14 Thread ThierryIT
update: All type of VMs can run only if there is no selected devices.



Le dimanche 14 janvier 2018 13:40:41 UTC+2, ThierryIT a écrit :
> Hello,
> 
> R3.2
> 
> 
> I have installed yesterday and this morning AEM and sys-usb.
> I had problem to make AEM working, but it seems now to work.
> When booting I should have my two VMs "netVM and proxyVM" running ... Not the 
> case anymore.
> My wifi device doesn't seems to be up as it was before (internal not usb).
> 
> I have removed sys-usb: same pb
> 
> TemplateVM are still able to run
> StandaloneVM are not running (cannot execute qrexec-daemon)
> netVM and proxyVM same pb than above.
> 
> Thx

-- 
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/98d2f48b-60db-4256-a997-aa6d3312edb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Black screen on install with lenovo

2018-01-14 Thread Rory
Yes this is same thing and having issues with 3.2 install 

-- 
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/e682b5da-cde9-489c-84a1-0c31a6a4b261%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Cannot execute qrexec-daemon

2018-01-14 Thread ThierryIT
I have done in the same time an upgrade of the fedora-26 template ...

Le dimanche 14 janvier 2018 13:40:41 UTC+2, ThierryIT a écrit :
> Hello,
> 
> R3.2
> 
> 
> I have installed yesterday and this morning AEM and sys-usb.
> I had problem to make AEM working, but it seems now to work.
> When booting I should have my two VMs "netVM and proxyVM" running ... Not the 
> case anymore.
> My wifi device doesn't seems to be up as it was before (internal not usb).
> 
> I have removed sys-usb: same pb
> 
> TemplateVM are still able to run
> StandaloneVM are not running (cannot execute qrexec-daemon)
> netVM and proxyVM same pb than above.
> 
> Thx

-- 
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/28b1e882-7bdd-4541-a30c-36c44ee2fd37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes in a corporate network behind HTTP proxy

2018-01-14 Thread pr0xy
On 2018-01-12 11:27, awokd wrote:
> On Fri, January 12, 2018 8:03 am, pr0xy wrote:
>>
>>
>> SUCCESS!
>>
>>
>> Changing the /etc/apt/apt.conf.d in Debian and the /etc/dnf/dnf.conf in
>> Fedora, AND allowing the proxy IP on the firewall of EACH TemplateVM
>> finally allows me to update them via the sys-firewall. That's a huge speed
>> improvement over sys-whonix.
>>
>> Now I'm wondering if my failure to set firewall rules was the reason I
>> couldn't use your earlier IPtables examples. I might revisit that, but for
>> now this solution allows me to use Qubes somewhat normally behind this
>> corporate proxy.
> 
> Glad to hear it! Sorry I couldn't help more. Would you mind providing a
> detailed list of steps you had to do to get this set up behind a corporate
> proxy? I know I'm a bit lost and it might help others in the future.

Thanks for jumping in with some ideas anyway awokd.

The company is using a Squid transparent proxy for HTTP/HTTPS and
another proxy for FTP (which I haven't completely figured out yet). The
proxies are:

HTTP PROXY http://proxy.example.com:8080
HTTPS PROXY http://proxy.example.com:8080
FTP PROXY http://proxy.example.com:10021

Step 1: Whonix

Set the torrc so that Whonix can connect thru the proxy. Go to
sys-whonix | Tor User Config and edit the torrc file to add these lines:

DisableNetwork 0
HTTPproxy 10.0.0.1:8080
HTTPSproxy 10.0.0.1:8080
FascistFirewall 1

It's important here to use the IP address instead of the proxy name.
I've confirmed this on the Whonix forums.

Step 2: Set TemplateVM apps to use proxy

As Marek stated above, you can set http_proxy and https_proxy variables
in your template(s) and all app VMs based on them automatically will
pick it up. Just create
/etc/profile.d/proxy.sh and export appropriate variables from there. 

I added the following to 
/etc/profile.d/proxy.sh 
in Fedora and 
/etc/environment 
in Debian templates:

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export ftp_proxy=http://proxy.example.com:10021
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export FTP_PROXY=http://proxy.example.com:10021

Here I used the fully qualified domain names instead of the proxy IP.

Step 3: Allow Qubes TemplateVMs to update via sys-firewall

Don't do this on the Whonix templates. They update thru sys-whonix.

Add the following to the bottom of
/etc/apt/apt.conf.d 
in Debian, and 
/etc/dnf/dnf.conf
in Fedora after
### QUBES END ###:

(ex.)
[user@fedora-26 ~]$ sudo gedit /etc/dnf/dnf.conf
.
.
### QUBES END ###
proxy=http://10.0.0.1:8080

Again, here I had to use the IP of the proxy. I tested with the fully
qualified name, and it didn't work.

Finally, allow the proxy IP on the firewall of EACH TemplateVM
>From the Qubes Manager (R3.2) | Firewall rules
Address 10.0.0.1
Protocol "Any"

That's working for me. I will try further experimentation with IPtables
and a ProxyVM, as those seem like better solutions. However, in the
meantime I have a working Qubes system and can actually do some work
with it instead of messing around with settings...for now.

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


Re: [qubes-users] Black screen on install with lenovo

2018-01-14 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-14 18:11, r...@tuta.io wrote:
> Having an issue with lenovo y520. I was getting the installer 
> working and then recieved an error- Errno 5 input/output error.
> 
> Then i tried again and when it starts to boot get "pane is dead" 
> error.
> 
> Now im trying all the uefi config troubleshooting and all it gives 
> me after adding the /mapbs and such at end of line is just a black 
> screen. Nothing else seems to work. Any help is appreciated.
> 

It sounds like you're encountering the same issue reported here:

https://github.com/QubesOS/qubes-issues/issues/3340

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpcDJMACgkQ203TvDlQ
MDANXw/+Mr8NR1iaQEPAeMjKlxyaO8L0RcLAqtYmvYp7MTtE0OT/p3YZU0cepqPi
859lOec/kdj8fUI2P+VV1xP2ghLbRWwWwbOG+Rtn/IKPAdVcgw4R40XUQRoLpydK
iN6hp3BPWwBNnOwZVA1v84SVcFOyC5Xu+cttng4EvGqflMwmfUZpexxwnCTurVt6
JWw4pjSNx1Ijiz37gBa8UorKK0D8u5pxiAz+UdfvNBeJexNCi01xkffuseWDN2R7
2h2ZH3/Awvo5mBHf74shhvXxLZM4DzAbRyHyxr2U7tFeItiOCUNDmKIMdSF5DKRF
WPwPACwbYxirEAMaFzppRUEtya0NOrOzLytwrL/KCxnqa/Q+qai3J2QWZ9nIbxvD
DU0+3YtgRwQe1a0XsdN4uu6X3QKzjoMqdChznIY5DQS4xJ/4jNdbkHs7yAOEpKJV
elj1Z7XDs6vfszILd5oTMC8bZ20qz1RVrtxlTCAWZ+oLMGYW9qfMWhrUJ027Y5RP
q52PKdYIFtJSpDNw08Evm+ytbAqtdWcelkusqr+ry+NJSxiJxa8wPgxH4a7UFN2v
QxihDg8EQcvlyB4czyTr7gzjUBDHR+03UCjkFvIn8hC6pPtOR09y47+Z2xh7vNM3
5NYJE110kMxdDupkZrV7uEu2gHu5N2pBr7quBTGegJpkPaugwbQ=
=quEl
-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/ce8d88bb-e1f5-d94b-392f-bec4682b244d%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

2018-01-14 Thread Nik H
Great news, 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/9a3deef1-d0cb-489c-8590-e07e04eeb5db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-14 Thread Nik H
On Monday, January 15, 2018 at 12:20:48 AM UTC+7, Vít Šesták wrote:
> As far as I understand it, microcode update cannot fix it. It just brings 
> some new instructions that can be used for Spectre fix. (But they don't help 
> on their own.)
> 
> You can try to update your BIOS if it is well supported by your vendor. Mine 
> is.
> 
> Alternatively, you can try to update microcode via Xen. (In fact, the new 
> microcode is loaded on every boot, because CPU has no persistent storage for 
> that. It should be loaded in early stage of boot.*) Xen has some 
> documentation, it would be probably enough to use some Linux package and add 
> something like “ucode=scan” to Xen parameters: 
> https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update
> 
> Regards,
> Vít Šesták 'v6ak'
> 
> *) Some μcode updates can be loaded even runtime, but this is not so general 
> and I don't recommend it. As far as I understand, the result of runtime 
> patching might vary on what instructions have been used before the attempt to 
> patch it, so you could end up with some race condition.


Thanks, this is good info. I found instructions to update microcode in linux - 
seems very simple. Xen instructions seem simple as well but where do I enter 
this? In the Dom0 terminal? I am a bit unclear as to how Dom0 and Xen interact.

I am guessing normal VMs do not have enough privileges to update microcode 
(well... hopefully, otherwise compromised VMs could install malicious 
microcode...)

As a side-note, spectre does compromise the entire qubes architecture. I know, 
nobody was thinking about these things, so no shame in that. But one of the 
main premises in qubes is that VMs are isolated from each other, and that is no 
longer the case as long as spectre is out there. Good that meltdown is not an 
issue, yes, but doesn't really matter, weakest link and all 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/effb5ab9-2bda-46d3-a9c1-604b1f1c1fbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Black screen on install with lenovo

2018-01-14 Thread Rory
Having an issue with lenovo y520. I was getting the installer working and then 
recieved an error- Errno 5 input/output error.

Then i tried again and when it starts to boot get "pane is dead" error. 

Now im trying all the uefi config troubleshooting and all it gives me after 
adding the /mapbs and such at end of line is just a black screen. Nothing else 
seems to work. Any help is appreciated. 

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


[qubes-users] inst.text boot option

2018-01-14 Thread breakupguugle
Qubes refuses to install with graphical installer and I get the mssage that I 
have to pass the inst.text option at boot. I tried it by appending 
option=inst.text to the bootloader, but it still tries to do graphical install 
and then anaconda surrounds itself and squeezes to death.

So how do you get the text mode installer to work ?
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/7905ace0-b5d3-499f-ae8c-48a7d60e32b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HCL - G505s (HD 8650G + R5 M230 dual graphics)

2018-01-14 Thread 'Emil Novik' via qubes-users
I did, no idea why HVM still doesn't work.

---
Emil Novik

 Original Message 
On Jan 14, 2018, 19:48, taii...@gmx.com wrote:

> On 01/14/2018 06:05 AM, 'Emil Novik' via qubes-users wrote:
>
>> Mostly works fine, but has some issues :
>> - Can't use any HVM(crashes the computer every time).
> Have you applied awokd's patch?

-- 
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/oAGVaaWfkw0wmj9fRuONKnWW_psJ28q9DVEV9VTDfiv63n5ZzbkDG-Dh2xot5AFRZPvxscZDA8xRnFTExl2sjqu-qQ9Z2_YKs0w6y6CQgMY%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: No more boot after update

2018-01-14 Thread Bertrand Lec
Le dimanche 14 janvier 2018 14:36:06 UTC+1, erikmunk...@gmail.com a écrit :
> Den søndag den 14. januar 2018 kl. 12.55.00 UTC+1 skrev awokd:
> > On Sun, January 14, 2018 11:19 am, erikmunk...@gmail.com wrote:
> > > Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:
> > 
> > >> From my understanding, it says that Qubes is the first one to be booted
> > >> but the currently booted is ubuntu (which is true :) )
> > >>
> > >> Do you have any idea for me?
> > 
> > 
> > > If this is indeed triggered by a too small EFI partition size, then we
> > > need to make it bigger next time to avoid it happening again. Though,
> > > this is not enough to recover now that it already happened. I'm still
> > > pondering about a possible solution.
> > 
> > Not sure if you two are having the same issue but I've run into what
> > Erik's describing before. I luckily caught it before rebooting, but it may
> > also work from rescue mode. I manually deleted older versions of initramfs
> > etc. in /boot/efi/EFI/qubes to free up space leaving just the single most
> > recent, and was able to rebuild the new Qubes EFI boot image with:
> > /usr/bin/dracut -f
> > /boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img
> > 4.4.31-11.pvops.qubes.x86_64
> > Replace the file names with the correct versions for your updated kernel.
> 
> Amazing, your approah worked smoothly! 
> Also I can confirm it works just fine in recovery mode too.  
> 
> Although I had to make some small minor modifications due to my slight 
> different situation, since seemingly I did not have the new 
> initramfs-4.14.13-1.pvops.qubes.x86_64 and only my old one 
> initramfs-4.9.56-21.pvops.qubes.x86_64 
> I'm not too sure why it didn't work for the new kernel, whether or not it was 
> due to the missing initramfs or not, but either way, it was probably just 
> that, lack of diskspace on the partition.
> 
> I did not just delete the old initramfs in the reocvery mode, since guessing 
> it might leave worse off not having a single one available. So to be sure not 
> to mess up, I could either make a copy elsewhere for backup before deleting 
> the last initramfs, or try restore my old kernel. 
> 
> So I resorted to trying re-establish my old kernel using your method, and it 
> worked. I'll explain what I did below in details in case others need it too. 
> I used your post as a guideline to make these modifcations. 
> 
> I booted my system normally using the old kernel after the above fix, and 
> proceeded to "sudo dnf remove kernel-4.14.13-1.pvops.qubes.x86_64" to get rid 
> of the new broken kernel.
> 
> I then made a backup copy of my EFI folder to my home folder (In case I 
> needed it again), and then followed up to delete the old 21MB'ish or so in 
> size initramfs for my old and current running kernel system. 
> 
> I then proceeded with updating again, installing the new kernel. This time it 
> installed cleanly. I then checked the EFI folder if the new kernel and new 
> initramfs was there, and the xen.cfg file also correctly pointed to the 
> kernel and initramfs without the need for edits.
> 
> Then rebooted, and now it works flawlessly with the new kernel update.
> 
> Thanks a lot awokd!
> 
> @Bertrand Lec, did you get yours working?

So, a little summary:
- I have plenty of room in my EFI partition.
- I was not installing from testing, just from normal repository, so my kenerl 
was 4.9.56
- I tried the dracut command, without success

However, I did a new fresh install of R3.2 but this time, to do the dom0 
update, I chose to use testing repository 
(--enablerepo=qubes-dom0-current-testing), and it works now fine !

What worries me the most is that I don't understand what happened (and that I 
am afraid of doing a new update of dom0, as it is requesting it).

Thank you all,
Bertrand

-- 
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/65178161-f4c4-4dd6-a1fc-87238db32d00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HCL - G505s (HD 8650G + R5 M230 dual graphics)

2018-01-14 Thread taii...@gmx.com

On 01/14/2018 06:05 AM, 'Emil Novik' via qubes-users wrote:


Mostly works fine, but has some issues :
- Can't use any HVM(crashes the computer every time).

Have you applied awokd's patch?

--
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/b7350d6e-b2a0-6422-3c4e-5e38a47230b8%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] template vm private.img file weighs (size) 171.8 MB, not 3 GB, can you save data?

2018-01-14 Thread 'Tom Zander' via qubes-users
On Sunday, 14 January 2018 15:02:48 GMT jerr...@disroot.org wrote:
> can you somehow save the data? is it a corrupt file? when i put this file
> in the template folder in /var/lib/qubes, the data is not there.

'private.img' is the contens of /home and /rw

you may be looking for 'root.img' if you are talking about a template.

Not sure if this command is available on 3.2, but qvm-volume is useful too.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


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


[qubes-users] Known working USB to VGA or USB to HDMI adapters with Qubes?

2018-01-14 Thread Joe Thielen
Does anyone have direct knowledge of a USB to VGA or USB to HDMI adapter
that is known to work in Qubes?

I've installed Qubes 4.0-rc3 on my new Dell 7577 laptop (Nvidia Geforce
GTX).  Everything seems good except I can not get another monitor to work
on the HDMI port (HCL forthcoming).  I followed the Qubes NVIDIA
instructions and get about the same issue as others have reported... X does
not start.  After I blacklisted the nvidia and nouveau modules I was able
to get X to function again.  xrandr in dom0 shows HDMI and DisplayPort
ports as disconnected, even when I have an HDMI monitor connected.  One
weird thing, when I plug in an HDMI monitor, the Qubes Display app pops up
automatically... like it knows something was plugged in, but nothing I did
was able to make it available for use or say "connected" in xrandr.

Anyway, I'd really like to add another monitor (or two!!!) to the setup.
If I have to purchase an external adapter to bypass the issue I guess that
will work, but I want to know that it works specifically with Qubes before
I buy one.  I've done searches for Qubes and Fedora and didn't seem to come
up with anything specifically positive, only negative reports.

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


[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-14 Thread Vít Šesták
As far as I understand it, microcode update cannot fix it. It just brings some 
new instructions that can be used for Spectre fix. (But they don't help on 
their own.)

You can try to update your BIOS if it is well supported by your vendor. Mine is.

Alternatively, you can try to update microcode via Xen. (In fact, the new 
microcode is loaded on every boot, because CPU has no persistent storage for 
that. It should be loaded in early stage of boot.*) Xen has some documentation, 
it would be probably enough to use some Linux package and add something like 
“ucode=scan” to Xen parameters: 
https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update

Regards,
Vít Šesták 'v6ak'

*) Some μcode updates can be loaded even runtime, but this is not so general 
and I don't recommend it. As far as I understand, the result of runtime 
patching might vary on what instructions have been used before the attempt to 
patch it, so you could end up with some race condition.

-- 
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/a7654f30-92d4-4386-8001-f2d731c72e65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Just installed AEM(Anti-Evil-Made)...see an error:(

2018-01-14 Thread velcro
Managed to find what was causing the error and how to remove the error:

https://askubuntu.com/questions/778875/tpm-error-6-when-booting-thinkpad

https://bugzilla.redhat.com/show_bug.cgi?id=1413409

In my BIOS I went to Security -> Security Chip -> Security Chip set to "Active"

However this brings up additional BIOS setting questions...

Any body have any thoughts on the best configuration for my default BIOS for a 
Lenovo? Specifically related to the "Security Chip" settings?

Clear Security Chip?
Intel TXT Feature?

I am not sure I am comfortable yet with changing my BIOS to Coreboot but love 
the idea:)

My threat vector is more from a well funded malicious hacker(vs Intel or a 
Government). Just trying to harden my PC the best I can...

Any thoughts or advice would be greatly appreciated.

Thanks,
V

-- 
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/1d1eba89-166f-4d97-883f-a0a81abdfb2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] template vm private.img file weighs (size) 171.8 MB, not 3 GB, can you save data?

2018-01-14 Thread 'awokd' via qubes-users
On Sun, January 14, 2018 3:02 pm, jerr...@disroot.org wrote:
> can you somehow save the data? is it a corrupt file? when i put this file
> in the template folder in /var/lib/qubes, the data is not there.

Try to copy it into a VM, then do a loop mount on it. In Stretch it would be:
cd ~
mkdir mnt
sudo mount private.img mnt


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


[qubes-users] template vm private.img file weighs (size) 171.8 MB, not 3 GB, can you save data?

2018-01-14 Thread jerry57
can you somehow save the data? is it a corrupt file? when i put this file in 
the template folder in /var/lib/qubes, the data is not there.

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


Re: [qubes-users] how to reinstall template? (i think it's not enabled by repo)

2018-01-14 Thread 'Tom Zander' via qubes-users
On Sunday, 14 January 2018 03:07:09 GMT jerr...@disroot.org wrote:
> the template is whonix-ws
> when running command
> sudo qubes-dom0-update --action=reinstall qubes-template-package-name

This is quite broken in 4.0 and you have to be a bit clever to work around 
this; here are some tips.

Reinstall doesn't work, you should delete and install instead.
But this is still quite tricky :)

So, first you want to do a 
  sudo yum remove qubes-template-NAME
the tricky part is that the RPM also calls 'qvm-revove' and refuses to 
continue when that fails.
If you hit that case where you already deleted your VM, all you need to do 
is calling 'qvm-create' with the name it expects and just make it follow the 
standard template etc.
The goal is to have an empty VM, just to allow the qvm-remove that yum calls 
to pass.

You should be able to do a simple 'qubes-dom0-update' to install the whonix 
template after this which probably includes downloading it.

Good luck!

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


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


Re: [qubes-users] Re: No more boot after update

2018-01-14 Thread erikmunkandersen
Den søndag den 14. januar 2018 kl. 12.55.00 UTC+1 skrev awokd:
> On Sun, January 14, 2018 11:19 am, erikmunkander...@gmail.com wrote:
> > Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:
> 
> >> From my understanding, it says that Qubes is the first one to be booted
> >> but the currently booted is ubuntu (which is true :) )
> >>
> >> Do you have any idea for me?
> 
> 
> > If this is indeed triggered by a too small EFI partition size, then we
> > need to make it bigger next time to avoid it happening again. Though,
> > this is not enough to recover now that it already happened. I'm still
> > pondering about a possible solution.
> 
> Not sure if you two are having the same issue but I've run into what
> Erik's describing before. I luckily caught it before rebooting, but it may
> also work from rescue mode. I manually deleted older versions of initramfs
> etc. in /boot/efi/EFI/qubes to free up space leaving just the single most
> recent, and was able to rebuild the new Qubes EFI boot image with:
> /usr/bin/dracut -f
> /boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img
> 4.4.31-11.pvops.qubes.x86_64
> Replace the file names with the correct versions for your updated kernel.

Amazing, your approah worked smoothly! 
Also I can confirm it works just fine in recovery mode too.  

Although I had to make some small minor modifications due to my slight 
different situation, since seemingly I did not have the new 
initramfs-4.14.13-1.pvops.qubes.x86_64 and only my old one 
initramfs-4.9.56-21.pvops.qubes.x86_64 
I'm not too sure why it didn't work for the new kernel, whether or not it was 
due to the missing initramfs or not, but either way, it was probably just that, 
lack of diskspace on the partition.

I did not just delete the old initramfs in the reocvery mode, since guessing it 
might leave worse off not having a single one available. So to be sure not to 
mess up, I could either make a copy elsewhere for backup before deleting the 
last initramfs, or try restore my old kernel. 

So I resorted to trying re-establish my old kernel using your method, and it 
worked. I'll explain what I did below in details in case others need it too. I 
used your post as a guideline to make these modifcations. 

I booted my system normally using the old kernel after the above fix, and 
proceeded to "sudo dnf remove kernel-4.14.13-1.pvops.qubes.x86_64" to get rid 
of the new broken kernel.

I then made a backup copy of my EFI folder to my home folder (In case I needed 
it again), and then followed up to delete the old 21MB'ish or so in size 
initramfs for my old and current running kernel system. 

I then proceeded with updating again, installing the new kernel. This time it 
installed cleanly. I then checked the EFI folder if the new kernel and new 
initramfs was there, and the xen.cfg file also correctly pointed to the kernel 
and initramfs without the need for edits.

Then rebooted, and now it works flawlessly with the new kernel update.

Thanks a lot awokd!

@Bertrand Lec, did you get yours working?

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


Re: [qubes-users] Re: No more boot after update

2018-01-14 Thread erikmunkandersen
Den søndag den 14. januar 2018 kl. 12.55.00 UTC+1 skrev awokd:
> On Sun, January 14, 2018 11:19 am, erikmunkander...@gmail.com wrote:
> > Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:
> 
> >> From my understanding, it says that Qubes is the first one to be booted
> >> but the currently booted is ubuntu (which is true :) )
> >>
> >> Do you have any idea for me?
> 
> 
> > If this is indeed triggered by a too small EFI partition size, then we
> > need to make it bigger next time to avoid it happening again. Though,
> > this is not enough to recover now that it already happened. I'm still
> > pondering about a possible solution.
> 
> Not sure if you two are having the same issue but I've run into what
> Erik's describing before. I luckily caught it before rebooting, but it may
> also work from rescue mode. I manually deleted older versions of initramfs
> etc. in /boot/efi/EFI/qubes to free up space leaving just the single most
> recent, and was able to rebuild the new Qubes EFI boot image with:
> /usr/bin/dracut -f
> /boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img
> 4.4.31-11.pvops.qubes.x86_64
> Replace the file names with the correct versions for your updated kernel.

Indeed, I'm not sure either. But gonna assume it is the same until he confirms 
or disconfirms it.

Your suggestions sounds like a great approach, I will try it once I'm done 
copying my /var/lib/qubes/appvms folder. I used qubes rescue to reach dom0 
terminal, and is currently copying all my data in case I need to re-install. 

USB 2 slowness and a lot of data to copy, probably gonna take some hours to 
run. Once finished then I'll try your method out, as you said hopefully it 
works in rescue/tty mode. 

I'll rapport back the outcome once I get through all the slow copying. 

-- 
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/033befdc-ef4d-484a-b358-020a0ff44ccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: No more boot after update

2018-01-14 Thread 'awokd' via qubes-users
On Sun, January 14, 2018 11:19 am, erikmunkander...@gmail.com wrote:
> Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:

>> From my understanding, it says that Qubes is the first one to be booted
>> but the currently booted is ubuntu (which is true :) )
>>
>> Do you have any idea for me?


> If this is indeed triggered by a too small EFI partition size, then we
> need to make it bigger next time to avoid it happening again. Though,
> this is not enough to recover now that it already happened. I'm still
> pondering about a possible solution.

Not sure if you two are having the same issue but I've run into what
Erik's describing before. I luckily caught it before rebooting, but it may
also work from rescue mode. I manually deleted older versions of initramfs
etc. in /boot/efi/EFI/qubes to free up space leaving just the single most
recent, and was able to rebuild the new Qubes EFI boot image with:
/usr/bin/dracut -f
/boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img
4.4.31-11.pvops.qubes.x86_64
Replace the file names with the correct versions for your updated kernel.


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


[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-14 Thread pixel fairy
what about the cpu microcode? can a package be backported for it? or does that 
have to be done through xen?

fedora 26 has some (theoretical?) protection against meltdown, maybe qubes-4 
should update dom0 to that in the rc.

-- 
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/e166d5cb-5635-4647-8bbf-bebb463120fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Cannot execute qrexec-daemon

2018-01-14 Thread ThierryIT
Hello,

R3.2


I have installed yesterday and this morning AEM and sys-usb.
I had problem to make AEM working, but it seems now to work.
When booting I should have my two VMs "netVM and proxyVM" running ... Not the 
case anymore.
My wifi device doesn't seems to be up as it was before (internal not usb).

I have removed sys-usb: same pb

TemplateVM are still able to run
StandaloneVM are not running (cannot execute qrexec-daemon)
netVM and proxyVM same pb than above.

Thx

-- 
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/f5422734-1f7a-4839-bf59-50276206303e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-14 Thread Vít Šesták
Good point, I forgot this one. of course, it would, but I am not sure if Qubes 
is ready for that.

But it could be useful to use 32-bit stubdoms for those reasons. They do rather 
I/O-bound work (=> minimal performance penalty) and they don't need so much 
memory to utilize more than 32-bit pointers. (Also, using 32-bit pointers can 
make a minor performance gain.)

On other VMs than stubdoms, it is not so easily deployable, because user might 
have some 64-bit only software there. At least, it is impossible to deploy it 
automatically (via update) without breaking anything.

It is possible to use 32-bit stubdom on a 64-bit system?

Regards,
Vít Šesták 'v6ak'

-- 
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/4e004690-cbab-4742-b625-0d583159dde1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: No more boot after update

2018-01-14 Thread erikmunkandersen
Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:
> Hello,
> 
> I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
> The PC is configured with UEFI. 
> 
> The installation goes well. At that time, I can reboot directly to Qubes.
> 
> However, after I update dom0, Qubes refuse to reboot. The boot is done to 
> Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.
> 
> Result of efibootmgr command is:
> BootCurrent: 
> Timeout: 1 seconds
> BootOrder: 0002,,0005,0001,0007
> Boot* ubuntu
> Boot0001* Hard Drive
> Boot0002* Qubes
> Boot0005* CD/DVD Drive
> Boot0007* Removable Drive
> 
> From my understanding, it says that Qubes is the first one to be booted but 
> the currently booted is ubuntu (which is true :) )
> 
> Do you have any idea for me?
> 
> Thanks
> Bertrand

I experienced similar issues today, it seems like it's the recent updates from 
the current-testing repository with the new kernel. From memory, I can tell 
there were errors of the kind "not enough disk space to create EFI", and I can 
inform the EFI is 95MB in size, strictly only containing Qubes information and 
data since Qubes RC-2. Note to self... use Grub and make it bigger next time... 
urgh...

I'm using Qubes 4 though, but perhaps Qubes 3.2. also got the same kernel 
update 4.14.13?

I suspected a reboot might go bad after seeing the error mentioned above, but I 
tried anyway. Sure enough, now the system can't boot. I tried both adding 

efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1 
"placeholder /mapbs /noexitboot"

and also added the EFI path directly from the UEFI(BIOS). None of the two 
methords workek. 

I'm suspecting you're having this issue too Bertrand Lec? Did you install 
kernel 4.14.13? If you're unsure if you did, try boot from your Qubes 
installer, and pick "Rescue Qubes" option in the Qubes grub boot menu. Then 
select 1 in the entry, type in your encryption password, and then do as the 
text will tell you to chroot into your Qubes system. Once there, use 'sudo 
cat/nano/vi/whatever-prefered' to '/path/to/EFI-file'. 
It should be around /boot/efi/EFI/qubes/xen.cfg

The document should say kernel 4.14.13 if you upgraded the same as I did.

If this is indeed triggered by a too small EFI partition size, then we need to 
make it bigger next time to avoid it happening again. Though, this is not 
enough to recover now that it already happened. I'm still pondering about a 
possible solution. 

In your case though, if you have nothing you want to save on it, you could try 
re-install once more, and ensure that the EFI partition is big enough in size 
by manually creating it yourself during install. Assuming of course, you indeed 
like me have this issue.

-- 
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/fff82484-b6c0-4bcb-8458-5a2b0fbce73f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: GPU?

2018-01-14 Thread Vít Šesták
Qubes does not have GPU virtualization for security reasons. As a result, 
additional GPU is used only in dom0 (od GuiVM in future). GPU might be useful 
for:

* additional output like HDMI (well, good luck…)
* window manager acceleration (but integrated GPU usually does the job well for 
less power)
* GPU passthrough to a VM (It might work, but it is not officially not 
supported and much work will be needed. Also, if the VM can rewrite GPU 
firmware, the GPU can perform a DMA attack during boot.)

When selecting my last laptop, I've decided to choose one without additional 
GPU. First, I don't need it much. Second, it adds some hassle. It would be 
ideal to have it switched off in order not to comsume power (=> lower heat, 
more quiet laptop, better battery life). On the other hand, I remember having 
HDMI output wired to the additional GPU, which was rather PITA. I was able to 
get it somehow working on my old laptop, but it used to crash X11.

HDMI through additional GPU will reportedly get better with Wayland, but we are 
not there yet.

Regards,
Vít Šesták 'v6ak'

-- 
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/2ad472cf-d74c-4a5c-970d-04e9b5018aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - G505s (HD 8650G + R5 M230 dual graphics)

2018-01-14 Thread 'Emil Novik' via qubes-users
Qubes 3.2 with all templates updated, using fedora-26-minimal, debian-9 and 
whonix upgraded to Debian 9 too.
Coreboot 4.6 with seaBIOS and option ROM for the integrated HD 8650G 
graphics(1002:990b). Didn't add the option ROM for the discrete R5 M230 
graphics(1002:6665) as it didn't work at all, so no discrete graphic support 
sadly.

Mostly works fine, but has some issues :
- Can't use any HVM(crashes the computer every time).
- Net VMs based on Fedora can't use my AR9287, but it's not the original card 
from the laptop.
- USB 3.0 ports only working as 2.0.
- "xen-pciback.hide=(Discrete:Graphics.PCIAddress)" has to be added to the grub 
command on boot or the laptop will just crash on startup every time when Qubes 
tries to initialize the card.
- Need to fix the boot as explained by qmastery 
https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ

Thanks to the other G505s owners for their help, mainly to Awokd who gave a lot 
of his time to find out what to do with my uncooperative machine.

---
Emil Novik

-- 
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/56wLBz2l-Vy1IUEhQOcgjshspUHrOAp1_WHSZcfxQQaacNg6dl-TKD-iOwhcKbcI22liKgemdBcDZMAAq0cDwy4ks1kczz7l2z37S3Pa2tM%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-_INVALID_-20180114-115601.cpio.gz
Description: Binary data


Qubes-HCL-LENOVO-_INVALID_-20180114-115601.yml
Description: Binary data