Re: [qubes-users] Re: QUBES 3.2 won't install... EFI_MEMMAP is not enabled... ESRT header is not in the memory map

2016-10-17 Thread Robert Mittendorf

Am 10/16/2016 um 12:59 AM schrieb raahe...@gmail.com:

On Saturday, October 15, 2016 at 6:05:39 PM UTC-4, aldenj...@gmail.com wrote:

I have the same issue!

see if you can select legacy boot mode in your bios and then install qubes.
I had a similar issue with Qubes 3.2 but not 3.1. For me the issue was 
the GPU. Increasing the memory from 256 MB to 512 MB solved the issue 
(non-discrete GPU, of course)


--
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/6a542cdb-3c5e-82d1-a012-8fdaa724f407%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Group/Hide VMs (e.g. mark arbitrary VM as "internal")

2016-10-17 Thread Robert Mittendorf

Am 10/11/2016 um 08:05 PM schrieb Unman:

qvm-prefs  -s internal True

Simple as that ? - thank you!
I checked the config files and did not find the "internal" switch

--
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/1f7e7c1a-6dfd-61da-2ce8-2cfbd9c02dd8%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Thoughts about installed software

2016-10-17 Thread Robert Mittendorf



However I would not use the "move to VM" command like this, as I
experienced those requests getting lost One time files were
actually deleted, since that time I always use copy instead of
move.

Sounds troubling. Do you remember the last Qubes release version
where you experienced this kind of data loss?
[...][...]
qvm-move-to-vm *should* be safe since R3.1
(unless the destination VM was debian-7 based, which had an old glibc
without syncfs() support).

Rusty

3.1 - but I dont remember src & dest types


My thoughts are more about continuing the attack to other QubesVMs or
even other systems by means of installed Software like a VNC client.

But I only ever allow the ports I require to be used at that time. I do have 
one area that is set up as a complete, but they can only talk to each other, 
nothing else.

So if you configure Qubes correctly, including the VMs, it will be very 
difficult to actually attack other VMs in the way I think you may be thinking 
it's easy?
Good point, Drew. The problem is reduced significantly if you reduce the 
firewall exceptions to a minimum.



--
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/17c46299-307c-4f0e-e04a-d62e6baee4d7%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM

2016-10-17 Thread Robert Mittendorf


Currently your easiest option is not to click on the links, but to 
copy-paste them to an open dispVM. Small sacrifice for a major 
security gain.


Well, the "easiest" option is to use a net-vm directly. What is the 
security gain? Its a dispVM after all.


--
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/cdf8657f-cf4f-63d8-563b-15d04af59a0d%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: USB over IP (Network Gateway)

2016-10-17 Thread doriss . lane
Hi! I am Doris from Eltima Software. 
Did you try to use it on Qubes? What exact issues appeared? 
You may send me your logs on doriss.l...@eltima.com and our team will try to 
solve the appeared issue. 

Regards,
Doris.

-- 
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/628f588d-a035-4b3c-9cef-56647ccef918%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to solve ProxyVM (sys-firewall) becomming non-functional at runtime

2016-10-17 Thread Robert Mittendorf


Am 10/13/2016 um 04:12 PM schrieb Manuel Amador (Rudd-O):

On 10/11/2016 09:42 AM, Robert Mittendorf wrote:

Hey folks,

sometimes the sys-firewall (more likely a service within it) crashes
and does no longer allow connected VMs to resolve DNS.
The ProxyVM must be the responsible entity, because the connection
will be fine again If I restart the sys-firewall.

You're onto it.  I think I fixed this yesterday:

https://github.com/QubesOS/qubes-core-agent-linux/pull/20
Quick-reading you link I dont think that this is the issue. My 
obervation is that it happens after several hours/days of a flawlessly 
working ProxyVM, not at boot.


--
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/c1fd7dc8-e572-897c-7ef8-215cd6a04479%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Is Qubes R3.2 still in testing branch?

2016-10-17 Thread Pawel Debski

On 2016-10-17 08:39, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-16 22:51, Pawel Debski wrote:

On 2016-10-16 23:22, Marek Marczykowski-Górecki wrote:

On Sun, Oct 16, 2016 at 08:21:17PM +0200, Pawel Debski wrote:

Folks,

I'm planning R3.1 -> 3.2 upgrade and need explanation:

|sudo qubes-dom0-update --enablerepo=qubes*testing --releasever=3.2
qubes-release|

why do I need to enable testing repo? I thought that R3.2 has already been
released as stable.

You're right, testing repo is no longer needed. Instruction fixed.

The thing is, that I was getting errors until I enabled testing repo. With 
--enablerepo=qubes*testing the upg went on.


What errors did you get?


About packages not existing in repo. As I've already run first stage of 
the upg with --enablerepo=qubes*testing the exact errors are hard to 
recollect. My assumption (perhaps wrong) was that the packages are still 
in testing repo.


Is there any log file I can paste the errors from?


Z powazaniem / Best Regards
Mit freundlichen Gruessen / Meilleures salutations
Pawel Debski


--
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/c8cae1fe-a772-a5aa-544d-cc2260e1ed5d%40econsulting.pl.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net doesn't detect wifi

2016-10-17 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-17 08:24, katerim...@sigaint.org wrote:
> Sorry, maybe it is a bug
> There is network manager applet but it is invisible
> 

Yes, this is a known issue:

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

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

iQIcBAEBCgAGBQJYBWt/AAoJENtN07w5UDAwqNMQALPL2wjGIEUVuDygVn494HRJ
nnsXOGqj9xbsa/bDQp5zkhNIqmvP5ieWpe7BjsLzYG02Nl89glApQqDAThuS4/sf
h+Trexc2YfZyeuV469l2h5PoKSx4lXErmtD0lQIJUOsfnKLR4/jRRHdRwio8Pp42
BiZ77mrdiGx0/y/CdQh3y9BF5oMMGB4iakDpsgBCf3NNCsEvybtyfzbQ8zqiDBOX
9LXCZaCYc5zH+zRx3g2umm9IHg10r2hi8YtKRsiV3cKrgLXgM13+p6KLfeCIDfwF
KYB8k7SEOOpXRrdj7Dy4/aMrxZgMW1QVDC47IA/4q59MpZP2nkNDseDWRTq0Qq1Y
XjLjjREdoy76O4OZYslI8H2+UHerbtX5cMDj9RJvtKF/PFGgRjkfK2nLAqfK2b4Y
vldziMb1aAFhG4P1WQiX/VRznoUWUCKVC8UkyG2H3ccl+VVCArQ/XmMfbe/qfkCg
+1lik3IBA9QptHuBzXywnHrKu4nvEhNl06cq1c/dAYpQYKr9fGrQM12nJcV5cYO0
FYEIH7oLlX/5FD3VYkxx1r4bs/MOjMqbSMa79Wr+9S1ZFlq/JPsCx98nzcafpTVc
CwV0jQng/6wsMHyY/0ZN5u/rSWOVF/m+TKt34FSRKuYGZOhDx0e0qAnGXt1l1by5
NPI52w74Dpt3Ok+q/Nd4
=MUyS
-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/96c3a404-b050-d6aa-59d3-0d1feaf9d91b%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?

2016-10-17 Thread Emil Cronjäger


Marek Marczykowski-Górecki:
> On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote:
> Take a look at those instructions (in order):
> https://www.qubes-os.org/doc/upgrade-to-r3.0/

That got me a shell in one of the two VM's - thanx! There were some
problems with the ip-commands though, but I managed to get the data out,
and put it into a fresh VM.

The other VM (also standalone), however, wont help me with a shell:

connected to domain [domain-name]
error: operation failed: PTY device is not yet assigned

I am not sure or how to determine it, but it *might* be a debian-based
VM, if that is to any help.
It is not crucial for me to get the VM up and running, but I need to get
data out of it somehow.

> That should work - those VMs will be set to use your default template.
> 
> 

Yup, it 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/da6f51de-4ca4-c6f9-c915-a646b2861311%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?

2016-10-17 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Oct 17, 2016 at 11:08:35PM +, Emil Cronjäger wrote:
> 
> 
> Marek Marczykowski-Górecki:
> > On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote:
> > Take a look at those instructions (in order):
> > https://www.qubes-os.org/doc/upgrade-to-r3.0/
> 
> That got me a shell in one of the two VM's - thanx! There were some
> problems with the ip-commands though, but I managed to get the data out,
> and put it into a fresh VM.
> 
> The other VM (also standalone), however, wont help me with a shell:
> 
>   connected to domain [domain-name]
>   error: operation failed: PTY device is not yet assigned
> 
> I am not sure or how to determine it, but it *might* be a debian-based
> VM, if that is to any help.

Standalone (PV) VM, right? Or maybe some HVM?

> It is not crucial for me to get the VM up and running, but I need to get
> data out of it somehow.

If you just want the data, create new VM, start it, and then attach the
old VM private.img and/or root.img to the new one as additional device:

qvm-block --attach-file new-vm /var/lib/qubes/appvms/old-vm/private.img

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYBV54AAoJENuP0xzK19csi8UIAJtW6Yj8/xFst44BqegUSxDZ
j0WzxGSPXFWMesqSeB6rvsZFftK0oSdyWK2QxYuo8FhmI2pD8PPMB6C/9WKpSM5D
cSkBFubZRAr4eolrArTF1spOtJTit/QvIqlWQhbKpR2Lquf+f8x5n5oEG81Ar0si
VJvgEhdXE1Y/uJX97YBBpqCSo5SvWbADJ2fN09yNFMbuADKBdqvwr8zv9WnGkJvl
1LK0BM9yvwGPAyA1h8uze5KqpoFUK/Tw61GD2LkAHtpL2AoAY3ch+N4B/CsKcwki
nFRRIWUO/RjDhAmseXAY0IjASeEh5/XbPmkq8S6AUJMyRTEUheWXJjsoq5FGSbI=
=4mtR
-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/20161017232754.GM15776%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Persistant routes on Qubes are not persistant?!

2016-10-17 Thread johnyjukya
> Hello,
>
> I need to add some static routes since I'm using a network with different
> GWs. For that reason I've tried to add some static routes through the
> NetworkManager which maps all the configuration into a file called
> qubes-uplink-eth0 . Strangely and since this file is within the private
> disk image, one would expect that the changes are be preserved after a
> reboot, unfortunately this has not been the case. Everytime there's a
> reboot the file gets overwritten somehow.
> Does anyone know if there's a way to preserve static routes on Qubes or is
> this simply a limitation?

That seems quite odd.

Is the symlink for /etc/NetworKManager/system-connections ->
/rw/config/NM-system-connections in place?

Is /rw/config/NM-system-connections indeed a valid directory, writable by
root, etc.?  Is /rw properly mounted to /dev/xvdb?  If you go into
/etc/system do you see a file for each network adapter (i.e. "Wired
Connection 1")?  Is that file rw by root only?  When you modify settings
in the network-manager taskbar icon, does the network's config file change
accordingly?  (It's text-based, easy to view.)

I use a couple of different static network configurations through
NetworkManager, and they stick around just fine.  What template are you
using?

JJ

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


[qubes-users] Inconsistent Screen Resolution for Fedora VMs

2016-10-17 Thread xmeehan
I just did a clean install of Qubes 3.2. For some reason the resolution off 
apps in Fedora VMs is wildly inconsistent. The borders of the windows, dom0, 
and the Debian VMs are correct but the apps in Fedora VMs range from consistent 
with the others to so low as to be almost unusable. I can't figure out what 
causes them to change and xrandr outputs the same thing no matter what the 
displayed resolution is.

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


[qubes-users] Dom0 "ghost" updates

2016-10-17 Thread Alex
Hi everyone,
in the last months I've been getting a lot (say, twice a week?) of
notifications of dom0 updates available which turn out to be false. I run
$ sudo qubes-dom0-update
but it tells me that there are no updates available.

I can't really recall exactly when this started, nor can I connect the
beginning of this with any specific events. I did some manual RPM
installations in dom0, related to Xorg and some Radeon drivers, which
have been ultimately undone; I don't know if this may have affected the
situation.

I believe I remember that it's the firewallVM that does the actual
update check for dom0, so I ask: is there anything that needs to be
synchronized? My firewallVM is based off Fedora 24 (not the default
template, but the old Fd-23 manually updated to 24), and dom0 has Fedora
23 (Qubes is R3.2).

If you have any other ideas for further debug (like "please check these
two files they should match" or "make sure this command returns zero")
let me know.. I know nothing about yum/dnf/rpm as a system.

TIA,
-- 
Alex

-- 
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/ec09e17a-6a59-8c2f-bfb7-795f69244560%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Is Qubes R3.2 still in testing branch?

2016-10-17 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-16 22:51, Pawel Debski wrote:
> On 2016-10-16 23:22, Marek Marczykowski-Górecki wrote:
>> On Sun, Oct 16, 2016 at 08:21:17PM +0200, Pawel Debski wrote:
>>> Folks,
>>>
>>> I'm planning R3.1 -> 3.2 upgrade and need explanation:
>>>
>>> |sudo qubes-dom0-update --enablerepo=qubes*testing --releasever=3.2
>>> qubes-release|
>>>
>>> why do I need to enable testing repo? I thought that R3.2 has already been
>>> released as stable.
>> You're right, testing repo is no longer needed. Instruction fixed.
> 
> The thing is, that I was getting errors until I enabled testing repo. With 
> --enablerepo=qubes*testing the upg went on.
> 

What errors did you get?

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

iQIcBAEBCgAGBQJYBHI2AAoJENtN07w5UDAwdaoP+wXrdSOLHhdnVuhOCTsJsJr6
HmxjFry58fMhhqNr4yhVTfOt5UbuN/HCXTGXaIF2qy/Qp6pswZJpLKEvaypRdyxH
PSpmjkbQgwwMY1JUD/+PJm1fn7y0iSy0+QvBdvlug/1mcpAc03A/Ajyl8bSkdRMb
AFWo18pXoz9nAYemOaUvCbMcmJSdkO07hAYLCrPs970tS2ByXPzh8GCyvMnJa2tc
PyHA9GPVsfLzORojj/6TfeAmCiup/gPwdz0f7Fb9fJhOwBrcZ4elQib5UsNePAEY
Fg5+7wGHD8s4FtKGD4kbeccvSOux8QNWzJgkNNv8oZQvxTh59plNs+4gYcldOHlT
3OAzc2uyXT5PEhn25bVdH3Nc3urTPKabjJlf5dfjFLSBckmM5Nur/uDNf4lEvD/2
yyB1L1JEpY1ZsrmYePHwk2EEc55bm6MkTay66FwiklumG32gwLzqrFqu7T7pxrHl
+Pap9p0APU9KYb6EAg4IPmVeZTjdvOgtmnELBhXWlG3zH7QlMX4zPHYeTwiKX9pp
SuGS5qfZeYSUmaxmqFLCQrmbF7365sDqvNMIHOX/RZ6pubNzFT85dFjjeHl0Aiz5
mWHmbYIz4VF6tkZvEuilhxKdoqXMHyPmNB8zUYp/vVVoZwHJ/m2Z8YEWwyIPn9Zr
bchocc2E+CVhmU6mhoXL
=d0iS
-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/5e36f1dc-16f0-904c-db80-b608bc73c408%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Dom0 "ghost" updates

2016-10-17 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-16 23:35, Alex wrote:
> Hi everyone,
> in the last months I've been getting a lot (say, twice a week?) of
> notifications of dom0 updates available which turn out to be false. I run
> $ sudo qubes-dom0-update
> but it tells me that there are no updates available.
> 
> I can't really recall exactly when this started, nor can I connect the
> beginning of this with any specific events. I did some manual RPM
> installations in dom0, related to Xorg and some Radeon drivers, which
> have been ultimately undone; I don't know if this may have affected the
> situation.
> 
> I believe I remember that it's the firewallVM that does the actual
> update check for dom0, so I ask: is there anything that needs to be
> synchronized? My firewallVM is based off Fedora 24 (not the default
> template, but the old Fd-23 manually updated to 24), and dom0 has Fedora
> 23 (Qubes is R3.2).
> 
> If you have any other ideas for further debug (like "please check these
> two files they should match" or "make sure this command returns zero")
> let me know.. I know nothing about yum/dnf/rpm as a system.
> 
> TIA,
> 

I get them too. It's a known issue:

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

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

iQIcBAEBCgAGBQJYBHLSAAoJENtN07w5UDAwTV0P/juT+CQKj8kBzyV/eSKhEdvk
W+jyZ3zpnft2NG768A8bhe/BESRKfZVQJ2haxgvs52kINqht+9F0X2qZGOcoyvWP
WNr1jQj19OSotfYbpcpizMUdqJ9uCaSxGvxQ8B9ifRjtWVg4hR7eSTyBOzfjkLTE
0jEw//fdOavwzenluDjTJNvh/eI5HPpphPYuSCayEyQ40K/Z+pHYS8UAKMg5y00Z
oiN+fqcbcsRifltxAacSWduOIzGIsyU4CjD3ZK9vGJIji/OK7va6ScdfsK5MmLsr
I4CvW8QMC5AdpQP7qiH5CyM7dt+ALCx+amEdOJ8BkZw7YGcaJJxk0arHPLUv3LwR
OapQMbjaJlbG41iP/Bpzj0LgrfH1Y85kOCXXFCJUQsbpuOz5oQ0Hp5Ni107D6XK9
Dxy79C63CetKNjDC0es1RUNM9veXr4R3kKORpo5uhkwE3y5kR+RyytkVufl5lC9O
w0XHAu2I8kpJ8nrfLY6Oi1MG1LSpIrfbwPaPP7AgAHQ8sUgtjNgvr8QaAtWCNS2a
rtlcTuE4g7W4Cfh/Dct66OKKmEt6rS9Tk0RMh/zoEU/95MgVpW7RfQUYCegBuHUq
plLgQr1Ddm+OAeeWw6XQjpFYNVAjI31C+Vs7zEGRYwVZ4EIgxaRQ2m2q5zlAWB4Z
OYDMay5YchmzIY2taxDQ
=bVAu
-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/27ade2b2-0cd3-2de4-2a8e-682b33f461c5%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Dom0 "ghost" updates

2016-10-17 Thread Alex
On 10/17/2016 08:42 AM, Andrew David Wong wrote:
> On 2016-10-16 23:35, Alex wrote:
>> [...]
>
>
> I get them too. It's a known issue:
>
> https://github.com/QubesOS/qubes-issues/issues/2086
>
Thank you for the reply; I don't know wether the two issues are related
(the icon persisting seems more of a GUI problem, while the notification
reappearing smells more of a misaligned database situation), but thank
you for filing the issue too.

-- 
Alex

-- 
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/4d5b738a-6ca9-db83-06ef-8f6902057b5c%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread Holger Levsen
On Mon, Oct 17, 2016 at 02:12:52PM -, johnyju...@sigaint.org wrote:
> Lines of code added/removed:

interesting numbers, thanks for posting them here.

> Now, about 4.7.  Note that the page for only lists individual names, does
> not list any company affiliations or employers at all.  An odd
> change/omission?

could there be a simpler explaination?

> Xen is a much bigger and faster-moving target than I ever expected for a
> hypervisor.

indeed, same here.

> Is it possible to have a secure environment, where you don't fully trust
> the hardware/software?

no, especially assuming s#fully## ;-p

>  And unless you've designed the hardware and
> software yourself (or they're both open and heavily and transparently
> reviewed), and your never let either out of your sight and protection, how
> can you ever fully trust hardware/software?

you can't.

and yeah, that's sad. luckily the real world is mostly not *that* black
and white.

long story short: I'd argue that *noone* should fully trust computers.
however, this doesn't make them completly useless ;-)


-- 
cheers,
Holger (SCNR)

-- 
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/20161017143310.GA22301%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread johnyjukya
>> Now, about 4.7.  Note that the page for only lists individual names,
>> does
>> not list any company affiliations or employers at all.  An odd
>> change/omission?
>
> could there be a simpler explanation?

Certainly.  Maybe some intern generating the stats page was too lazy to
summarize it by company.  Maybe they stopped tracking company affiliation.
 Maybe it's just an oversight.

Given the state of computer/network/software security these days and the
NSA's reputation, I thought it was worth pointing out.  :)

>> Xen is a much bigger and faster-moving target than I ever expected for a
>> hypervisor.
>
> indeed, same here.

Wiki on Microkernels is consistent with my understanding:

> In terms of the source code size, as a general rule microkernels tend to
be smaller than monolithic kernels, usually sizing at under 10,000 lines
of code.

Xen's Wiki page states:

> Xen Project is a hypervisor using a microkernel design

It's a bit disingenuous to call Xen a Microkernel, at 150,000+ lines of code.

I hope to dig through the sources a bit tonight, and see how much of that
is truly the core kernel/security bits, and how much of that is qemu
drivers and stuff.  Maybe there is a lean, well-reviewed core that we can
all trust, with a lot of supporting drivers and such.  Although the fact
that those acknowledgement pages are careful to point out "Microkernel
core" vs. auxiliary stuff.

>> Is it possible to have a secure environment, where you don't fully trust
>> the hardware/software?
>
> no, especially assuming s#fully## ;-p

Not with existing hardware/software/operating systems, but can we get
there?  Is there even a path forward? :)

Sadly, there doesn't seem to be any viable Xen alternatives.  (I guess one
could always create alternatives from forks of Xen or the various other
hypervisors/kernels out there; although securing/improving/auditing Xen is
probably less work.)

>>  And unless you've designed the hardware and
>> software yourself (or they're both open and heavily and transparently
>> reviewed), and your never let either out of your sight and protection,
>> how
>> can you ever fully trust hardware/software?
>
> you can't.
>
> and yeah, that's sad. luckily the real world is mostly not *that* black
> and white.

True, security isn't an on/off binary thing, it's more of a probability to
be combined with your risk profile.  Qubes certainly increases your odds
at having some security by a fair bit.

Probably minor in comparison to all the holes, bugs, bad design choices,
and vulnerabilities in PC hardware (and software bugs/backdoors), but
every little bit helps.

> long story short: I'd argue that *noone* should fully trust computers.
> however, this doesn't make them completly useless ;-)

Very good point.  I've overly-trusted computers, and have been hacked so
badly in the past few years that computers have basically become useless
to me.  But I'm also a pretty low-valued target, lol, so I'm trying to
rebuild my confidence in my setup for work (and personal) sanity and
dignity.

It's awfully hard not to rely upon computers on a daily basis for work,
personal, communications, media purposes.

Stumbled across this, rather interesting:

https://en.wikipedia.org/wiki/Exokernel

JJ

-- 
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/31ab8b2a2629b9c5dfb22e8b0eaa4824.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM

2016-10-17 Thread David Hobach



On 10/17/2016 09:42 AM, Robert Mittendorf wrote:



Currently your easiest option is not to click on the links, but to
copy-paste them to an open dispVM. Small sacrifice for a major
security gain.


Well, the "easiest" option is to use a net-vm directly. What is the
security gain? Its a dispVM after all.



The data copied to that VM (i.e. the pdf file or whatever you opened) 
must be considered leaked if the VM gets compromised via e.g. drive-by 
exploits.
Agreed, it's limited to that data, but nevertheless an unexpected 
potential impact. And depending on your data it can be critical.


 From a usability point of view you'll also get annoyed if you cannot 
print in dispVMs just because your firewall rules allowing connectivity 
to your printer aren't inherited, but those to allowing connectivity to 
the internet suddenly are in place.


Moreover your netVM is also inherited and firewall rules can have a 
different meaning depending on your netvm (just imagine the same private 
subnets being used for 2 different networks), i.e. it makes sense to 
inherit firewall rules, if you do it for netVMs.


Btw inheriting netVMs makes a lot of sense if you imagine one Tor proxy 
VM and one directly connected one. So a dispVM from a Tor connected VM 
would spawn a direct internet connection in your case... Currently it 
fortunately does not.




--
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/1b04afd0-8e3f-087b-9db1-a381495deb64%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread johnyjukya
>> 1) XEN is developed by people working for a company based in
>> the U.S.

Some fun stats for Xen 4.6 changesets, as used by Cubes:

Lines of Code: ~150,000

This is from

https://wiki.xenproject.org/wiki/Xen_Project_4.6_Acknowledgements

and related pages (and similar pages with 4.6 replaced by 4.x):

Lines of code added/removed:

Vers People Empl Added  Rempved NSA-Add NSA-Rem
4.4  81 29   38048  25989   121
4.5  10239   80906  141593  67142645
4.6  96 30   124035 90299   459 193
4.7  10236   106606 37160   ?   ?

Now, about 4.7.  Note that the page for only lists individual names, does
not list any company affiliations or employers at all.  An odd
change/omission?

So the NSA barely contributed for 4.4, contributed a significant amount
for 4.5, a bit for 4.6, and then either stopped contributing, or are doing
so in a non-transparent way through individuals for 4.7.  :(

I can't say that's confidence-inspiring.  Xen's change from 4.6 to 4.7 to
not listing employers almost has a slight "warrant canary" feel to it.  :S
 The source is open, I guess, but still, smart people can sneak in subtle
backdoor bugs.  As we have seen.

Also, out of those 100 individuals, what are the odds that the NSA could
sneak in a few apparently unaffiliated "representatives" to submit some
subtle changes.

Now, I'm sure a good many of the people at NSA just want a stable,
reliable, professional operating system to use for their work, and
contribute back to Linux in turn to make it better.

It'd be refreshing and inspiring to see them fixing our critical tech
tools rather than hopelessly busting them.  Go America.

But given their history of sneaking in back doors through subtle code
bugs, it does make one a bit, err, cautious.

Xen is a much bigger and faster-moving target than I ever expected for a
hypervisor.

After discovering I was being victimized by some keylogging and some other
covert surveillance hw/sw, I spend a fair bit of time about how to use a
computer with confidence, assuming that you can't necessarily trust the
hardware nor software.

Is it possible to have a secure environment, where you don't fully trust
the hardware/software?  And unless you've designed the hardware and
software yourself (or they're both open and heavily and transparently
reviewed), and your never let either out of your sight and protection, how
can you ever fully trust hardware/software?

(For example, things such as a password safe on a memory key can help
partially thwart even a hardware keylogger, since online/etc. passwords
are never typed.  Can this type of small success be achieved for a whole
system?  It's daunting.)

Related:

http://invisiblethingslab.com/resources/bh08/part2-full.pdf

JJ

-- 
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/6fc41c35e0c90896e50fc5892626c230.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Persistant routes on Qubes are not persistant?!

2016-10-17 Thread 4m3ap1+btc4yln3rc8lw via qubes-users
Hi,

Does anyone knows how to achieve this on Qubes?

Thanks






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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


[qubes-users] sys-net doesn't detect wifi

2016-10-17 Thread katerimmel
Sorry, maybe it is a bug
There is network manager applet but it is invisible

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


Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM

2016-10-17 Thread Robert Mittendorf


The data copied to that VM (i.e. the pdf file or whatever you opened) 
must be considered leaked if the VM gets compromised via e.g. drive-by 
exploits.
Agreed, it's limited to that data, but nevertheless an unexpected 
potential impact. And depending on your data it can be critical.
Well, that is why it is a distinct DispVM. If I open a legit PDF from my 
mail client in a DispVM (say dispvm1) and I open a non-legit URL in a 
DispVM, this will not be the same dispVM and thereby not leak the PDFs 
data. If the PDF itself is malicious, I most likely will not care about 
the leak. Only exception: A legit PDF gets infected and is then mailed 
to me. Usually that would allow the attacker to leak the PDF from the 
system it was send from in the first place.
 From a usability point of view you'll also get annoyed if you cannot 
print in dispVMs just because your firewall rules allowing 
connectivity to your printer aren't inherited, but those to allowing 
connectivity to the internet suddenly are in place.

agreed, basically.


Btw inheriting netVMs makes a lot of sense if you imagine one Tor 
proxy VM and one directly connected one. So a dispVM from a Tor 
connected VM would spawn a direct internet connection in your case... 
Currently it fortunately does not.

agreed.

Well, I was actually suprised that there is more than 1 DispVM. Do the 
child-DispVMs use the fedora-23-dvm template as well?


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


Re: [qubes-users] Anonymize MAC address

2016-10-17 Thread Chris Laprise

On 10/16/2016 02:02 PM, pl1...@sigaint.org wrote:

On 10/15/2016 08:59 AM, pl1...@sigaint.org wrote:

Anyone?


Instructions for MAC anonymization have just been updated:

https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Chris


Ok, is recommend to use debian as sys-net
My question is about already used mac-spoof in sys-net, please can you try
to give me an answer if it is possible?

pL11



Maybe someone involved in the macchanger instructions can chime in with 
advice.


My personal recommendation would be to use Network Manager, as the 
Macchanger script is prone to breakage and lists these limitations:


 * This does not randomize your MAC Address on sleep and wake state
   (only on restarting the |sys-net| VM)
 * The |sys-net| networking VM takes longer for device drivers to start
   up than usual, this delayed startup may cause the first attempt of
   |sys-whonix| to connect to Tor to fail

I started about 2 years ago trying to get Macchanger to work 
consistently. None of the different approaches really did the job. It 
should be handled by the system's  network configuration daemon, which 
is Network Manager.


Chris

--
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/9a4b1571-5742-a5e7-d194-3bcb8b1eb369%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re:Persistant routes on Qubes are not persistant?!

2016-10-17 Thread 4m4wzj+81e4x9zkjcyco via qubes-users
Yes, the symlink is in place:

ls /etc/NetworkManager/system-connections
131205 lrwxrwxrwx 1 root root 32 Oct 17 21:17 
/etc/NetworkManager/system-connections -> /rw/config/NM-system-connections/


The /dev/xvdb is properly mounted on /rw :

/dev/xvdb on /rw type ext4 (rw,relatime,discard,data=ordered)
 
I don't have a /etc/system directory on my system, are you referring to the 
unit files?
For the sys-firewall I'm using the default template - > fedora-23

When I set the routes by hand via NetworkManager they are reflected on the 
qubes-uplink-eth0 file:
(...)
[ipv4]
address1=10.137.1.8/32,10.137.1.1
dns=10.137.1.1;10.137.1.254;
dns-search=
may-fail=false
method=manual
never-default=true
route1=192.168.0.0/16,10.137.1.1
route2=172.16.0.0/16,10.137.1.1
#---EOF---
 
The file before the sys-firewall is rebooted has the following checksum and 
md5sum:

2551335477 425 qubes-uplink-eth0
83b37a6b68007838efb1e9e9fbc841f4  qubes-uplink-eth0

As soon as the sys-firewall  is booted the file with the NW configuration is 
overwritten :

[ipv4]
method=manual
may-fail=false
dns=10.137.1.1;10.137.1.254
addresses1=10.137.1.8;32;10.137.1.1
#---EOF---

As you can see the configuration was not preserved.
Therefore something is clearly overwritten the NM configuration, the problem is 
to know what and how to avoid it, preserving the NM config.


So in short, I cannot tell what process have been changing the NM configuration 
at every boot. It would be great if someone from the Qubes support would be 
able to shed some light on this.






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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


Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-17 Thread Chris Laprise

On 10/16/2016 08:50 AM, 4lpt9o+3m11o9qubb38o via qubes-users wrote:

You don't need to manually add the iptables rules. When enable the 
'qubes-yum-proxy' on the VPNVM the rule to iptables is automatically added:

Chain PR-QBS-SERVICES (1 references)
  pkts bytes target prot opt in out source   destination
 0 0 REDIRECT   tcp  --  vif+   *   0.0.0.0/0
10.137.255.254   tcp dpt:8082
   


And also the corresponding rule on the INPUT chain:

Chain PR-QBS-SERVICES (1 references)
  pkts bytes target prot opt in out source   destination
 0 0 REDIRECT   tcp  --  vif+   *   0.0.0.0/0
10.137.255.254   tcp dpt:8082

So you don't need to do this by hand.

@Manuel I agree with you, the instructions on the Qubes VPN doc. don't outline 
this step. And this is necessary to have the updates working while forcing all 
the traffic through the VPN.
Can someone add some references on the VPN article 
(https://www.qubes-os.org/doc/vpn/) in the same manner as this page reflected 
in this page - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy . 
Since anyone following the VPN article,as it is, would not have the yum/apt 
updates working.



Although following the doc would leave the updates working (user is 
instructed to create a new VPN VM, not use existing sys-firewall) it 
would be nice to be able to update over a VPN tunnel. I'll create an 
issue for updating the doc.


Chris

--
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/3cff8ec6-510e-34a6-9681-4ff01d223c9c%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] TVM ASLR-exploit-proof?

2016-10-17 Thread 0923718973178347240243
Hello Rudd-O,

here is an interessting concept, in some way they reach the RAM randomization 
by one central DLL (for Windows Plattforms only), but it works direct on the 
fly for all apps and libs!!!

http://www.morphisec.com/how-it-works/

Wow, not bad!

This will be much more robust.
And in parallel they keep the honypot, to run the law enforcement procedures 
against intruders.

Here are some critical view to ASLR:

http://blog.morphisec.com/aslr-what-it-is-and-what-it-isnt/

But for sure, the randomization will need a good non-deterministic random 
generator and a fast random update sequence (in Seconds) because 4 GB are quite 
endless...

Would it makes sense to implement a similar fast not-deterministic randomization
tech into the Qubes to overcome some standard template vulnerabilities, with 
smart countermeasurements?

Kind Regards
 

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


[qubes-users] how to integrate 3-year old backed up VM's into new system?

2016-10-17 Thread Emil Cronjäger
Hi,

I have a 3-year old backup of an old Qubes system that I cannot access
on my new, up-to-date system.

Two templates are standalone VM's: I can integrate them with the
Qubes-backup tool, so they appear in Qubes Manager, but they wont start:
"ERROR: Cannot execute qrexec-daemon!"

Two VM's are based on out-dated templates (fedora-18-x64) and cannot be
restored. I can restore them still, with the "ignore missing" option,
but I guess this wont make them boot?

Any suggestions?

Best regards,
Emil


-- 
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/db36114d-35ab-7218-13e8-0d1a3e9ca9b4%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] TVM ASLR-exploit-proof?

2016-10-17 Thread 10378213217831783789
Hello,

Tails is also using ASLR security tech now...

https://fossbytes.com/tails-2-6-secure-linux-os-snowden-updated-tor-and-kernel/

Kind Regards

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


Re: [qubes-users] how to integrate 3-year old backed up VM's into new system?

2016-10-17 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Oct 17, 2016 at 07:50:26PM +, Emil Cronjäger wrote:
> Hi,
> 
> I have a 3-year old backup of an old Qubes system that I cannot access
> on my new, up-to-date system.
> 
> Two templates are standalone VM's: I can integrate them with the
> Qubes-backup tool, so they appear in Qubes Manager, but they wont start:
> "ERROR: Cannot execute qrexec-daemon!"

Take a look at those instructions (in order):
https://www.qubes-os.org/doc/upgrade-to-r3.0/
https://www.qubes-os.org/doc/upgrade-to-r3.1/
https://www.qubes-os.org/doc/upgrade-to-r3.2/

Especially the first link have steps for recovering from your situation.

> Two VM's are based on out-dated templates (fedora-18-x64) and cannot be
> restored. I can restore them still, with the "ignore missing" option,
> but I guess this wont make them boot?

That should work - those VMs will be set to use your default template.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYBUB3AAoJENuP0xzK19csiFkIAI/QKzWZckvhk/f77ib7wvDS
33AY5h342ZJhmIK8dGyP8yJVHxxYAr4p1UPqM59hQlgTy4hWPwcWjS4MF5SV5x6K
QyYTuuVBjyz2oaA1z+r5rmFpJWnTHapk+h1Z/epmy4iNZ0UH2QKxU10C//BLpx4W
dVkFixv7aaeRjuIjPDtfYYfnQ7A5H3VYZPgvMwvF27z2wnHYqEW995TevkGwDpSi
9pMOj+uGGODIM8ytz9b0MGMlcXejIAhIZ2MfG99oBRcK09BNNS+/38I4AUMQ992a
XhGi9Eqji0ddH6WX3ICU7zGzRc/LnYDCy2MOuTXuNaJa2lg0JaQp2qpdmj/V1gA=
=LRLN
-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/20161017211952.GK15776%40mail-itl.
For more options, visit https://groups.google.com/d/optout.