Re: [qubes-users] Qubes 3.1 and 3.2(rc2) video driver question

[Dima Puntus]

On Mon, Aug 8, 2016 at 10:45 AM, Andrew David Wong  wrote:

>
>
> On 2016-08-08 10:31, Dima Puntus wrote:
> > On 2016-08-07 09:29, Dima Puntus wrote:
> >> Hi,
> >>
> >> I'd like to know if there's a way to fix the terrible screen tearing
> >> that I'm getting both on internal laptop screen and external monitor.
> >>
> >> System info:
> >>
> >> HP Elitebook 2570p: *Intel HD4000 graphics* CPU i7-3840QM
> >>
> >> I know there's an Intel Graphics driver for Linux package by 01 dot org,
> >> but I'm unable to install it in dom0 due to multiple dependencies which
> >> are missing. What's the best approach to update the video driver?
> >>
> >> Thank you Dimitry
> >>
> >
> > Are you, by any chance, referring to this?
> >
> > https://github.com/QubesOS/qubes-issues/issues/1028
> >
> >
> > No, the issue is probably more related to vsync and the video driver
> > itself. Whenever moving stuff across the screen or watching videos I can
> > always spot a misalignment between the top and bottom halves of the
> > screen. Needless to say that the issue doesn't exist in Windows so it's
> not
> > a hardware problem. Also, I see it when using some linux distros but not
> > all. For example, in Mint 18 and KDE NEON seem to be tear free. Wayland
> > video server also fixes the issue. My guess is, qubes uses an older intel
> > driver by default. So my question - is it possible to update it in dom0?
> Is
> > there a guide?
> >
> > Thanks, Dimitry
> >
>
> Yes, here you go:
>
> https://www.qubes-os.org/doc/software-update-dom0/
>
> P.S. - Please keep the list CCed, and please don't top post.
>
>
> Sorry to resurrect this thread. The link above doesn't really help
> (probably because I'm a newbie and missing some solid background in linux
> and xen). Here's the driver I'm trying to install -
> https://01.org/linuxgraphics/downloads
> (intel-linux-graphics-installer-1.4.0-23.intel20161.x86_64.rpm). So far I
> was able to download it through one of the VMs, then copy to Dom0. It's
> missing a dependency - libproxy-mozjs 0.4.10. I can download and copy it to
> Dom0, but for some reason Dom0 doesn't even see the file, let alone install
> it. What am I missing? I really need a decent video driver, the default one
> is only good for terminal.



> Appreciate your help

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

[qubes-users] Display Calibration and Audio Equalizer for Dom0 ?

[Connor Page]

I have calibrated my yellow screen using argyllcms. I don't attach usb devices 
to dom0 so installed it in sys-usb as well. used 
https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as 
a rough guide. to get the calibration done you just need to run dispcal and 
then transfer the calibration file to dom0. then test it with "dispwin xxx.cal" 
in dom0. if happy, create an autostart item with that command (probably, using 
the full path to the calibration file) and you're done.

I went further and created an icc profile for use in firefox and photo 
software. note that some displays use proprietory colour-mixing algorithms so 
Linux tools may be ineffective with them :( (e.g., pentile matrix on some very 
high resolution screens)

-- 
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/c473caf8-240d-420e-b08b-77a0c998543e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Suggestions for running media server?

[Connor Page]

No. 4 makes sense. sys-usb shouldn't know the encryption keys. encrypted block 
device can be attached to a server vm where it would be appropriately decrypted 
and mounted, possibly from dom0 via qvm-run (you can start a vm, attach 
storage, decrypt and mount it by a short script using qvm-* command line tools) 
. server software should be run as a different user that can't login or use 
sudo. enabling services is a bit tricky in template-based vms, so the easiest 
solution is to create a small template with just the bare necessities for the 
server software, enable the service in it and then use it just for one server 
vm.
I would suggest attaching that server vm to a separate firewall vm. that way 
allowing incoming traffic in iptables should be both easier and more secure. 
firewall rules are created in different scripts in proxyvm vs netvm and appvm. 
follow Qubes documentation and don't forget to make scripts executable :)
although I used to run file and web servers on a Qubes PC I now tend to think 
that Qubes is meant to protect clients, not servers. 

P.S. Qubes networking uses NAT so LAN won't actually see any broadcast messages 
from the server unless it runs in a netvm.

-- 
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/4ab36370-8472-4b28-b72c-f337654b3bfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Suggestions for running media server?

[Anon]

I'm looking for some suggestions for running a "maximally-secure" media
server that will access an encrypted USB hard drive for it's storage. It
can and probably should be read-only to the media-server software.

A few possibilities I can think of listed from assumed lowest security
to highest security:

1) run the media server in the sys-usb VM.
2) stop sys-usb VM and run another VM that doesn't start on boot but has
access to all the USB devices and is run manually after boot
3) run another VM that only has one "locked down" dedicated USB device
and remove that device from sys-usb VM permanently
4) run another VM that accesses the storage through sys-usb (I am
unfamiliar with this, but assmue it's possible)

The media-server software will by non-proprietary (DLNA compliant) and open.

All thoughts are welcome, including those that say "don't do it." If
there's something else I should be reading instead, please let me know.

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/nqcr7n%24d6s%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Broken applications menu/shortcuts with xfce

[kij7u5]

On 09/03/2016 05:43 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Sep 03, 2016 at 05:11:38AM +1000, kij...@larky.me wrote:
>> I installed 3.2rc3 from scratch today after having been on 3.1. I
>> restored my appvms from 3.1 but not my fedora-23 template.
> 
>> After installing some packages into my (new) fedora-23 template none of
>> the app shortcuts for any VM based on that template work. They launch
>> the VM but no applications launch.
> 
>> qvm-run does work and is the only way I can launch most things right now :)
> 
>> I have run qvm-sync-appmenus fedora-23, tried deleting/moving
>> appmenus.whitelist and various folders containing .desktop files and
>> have only made the problem worse in that there are lots of things
>> missing from my xfce menu but still none of the things on there work.
> 
>> I could use some help. Any thoughts/advice would be most welcome.
> 
> Check to what command those .desktop files points - should have
> something like Exec=qvm-run  Try to call that exact command manually
> and see if you'll get some error. If not (but still application do not
> launch), add "-p" option to get more details.
> 
> 

Thanks.

With -p I see the error 'no module named qubes' and suddenly it's clear
this is all my fault and I know what I did wrong.

My first step in modifying the fedora template was to link
/usr/bin/python to
python3 rather than python2.

Oops. I didn't think about how that'd affect qubes at all. Perhaps
#!/usr/bin/python2 would make more sense? But no matter.

Changed it back so python > python2. It's all working again. I think I
didn't even need to backup the .desktop files I deleted because
qvm-sync-appmenus does whatever it has to do.

-- 
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/afacd67c-f1be-c753-09c8-a32a26f380eb%40larky.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: epoxy on ram to prevent cold boot attacks?

[Anon]

Marek Marczykowski-Górecki:
> If you (or someone else) plug a malicious USB device that will exploit
> some bug in one of million USB device drivers, it can do whatever it
> want with the other USB devices on the same bus. And if that USB
> controller live in dom0, it's game over even without injecting malicious
> keystrokes.
> PS/2 is much better, because you can't connect anything else than input
> devices there, and attack surface is much smaller.

After having read the entirety of the PC security paper Joanna wrote a
while back, I was shocked to see how poor PC security really is. I found
it one of the most profound papers I've ever read. As far as I'm
concerned, it should be required reading for anyone capable of
understanding even the basics.

What you wrote reminds me of that feeling and how wide open and
vulnerable things really are for those that know what they're doing.
It's amazing to me things have been "allowed" to get this bad.

All genuine efforts into making things better are very much appreciated
and needed by all of us. 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/nqcosk%24rm2%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Announcement: Qubes OS 3.0 reaches EOL on 2016-09-09

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As a reminder, Qubes OS 3.0 reaches EOL on 2016-09-09. If you're a current 3.0
user, we strongly urge you to upgrade to a newer release before 2016-09-09. You
can read the full announcement here:

https://www.qubes-os.org/news/2016/09/02/qubes-os-3-0-eol-on-2016-09-09/

Please feel free to use this thread to discuss the announcement.

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

iQIcBAEBCgAGBQJXydAtAAoJENtN07w5UDAwZzUP/3S7ZjRLcb4kKmwfa+Ydqot3
0BSsqfXW4btI6/CNB36u3oVBqRiokeJhpOIaXgsri3RYAabwyhD9EnSHhn3kE0Zg
a3hfM0K4Tk4wA7fdgEk7SsISw4jP3ILJ6/bFI5EHVwJRtb7la7tXFKSFUyTtZhfU
qr/oD1/BawH1CQymm+0xivsmqrfKXGzVV25qaBAf3h+174MeIsKYspxu73xFUPZ0
GPgBQO2AARnsFW8lluH5VrMTtZpiU8RGNf+Y0QiKOYTJcXCMbN4S5FQNhDGDtm0N
XMiHfnIcyvLJqOkhXVangumk/gcOQ+mFBcz47Owffby6f1Z15KsxXxYxL0A0Qr5s
CHIwtEQrmYpxfmUoEY8d9u/sYdHM9IpYOtUGV5mLxilmFC9NM2u1MlLiLW+4KDkr
wy0y+ibd4IKOpv4ubRWrt+q4J3xp1hFYm6IhZG24JHFlwhaTRtgx8e7JLYB/DD1u
xEJvF3f5L034E/tpgmDQ7jzZ4gHz4Q+Wk17UnKjreJ0iNV7cvbyqHn0zVQVbs1Tx
CRKtRk0i5mnkcSha8Ma1PAw+tPJy+xBiRZgZyyuT2gxYT0N/PNSUNb4MVkVTXD3H
hWYDwuzzXJX51OM7deGXghIYVK37wbgcEU8q2OdIF7YIc+xzbdO1Xy67BbnU9i9h
EXIfzuToXQat6smhuYlL
=O8HS
-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/411efa89-a79e-a096-a85a-8708c9481941%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Broken applications menu/shortcuts with xfce

[kij7u5]

I installed 3.2rc3 from scratch today after having been on 3.1. I
restored my appvms from 3.1 but not my fedora-23 template.

After installing some packages into my (new) fedora-23 template none of
the app shortcuts for any VM based on that template work. They launch
the VM but no applications launch.

qvm-run does work and is the only way I can launch most things right now :)

I have run qvm-sync-appmenus fedora-23, tried deleting/moving
appmenus.whitelist and various folders containing .desktop files and
have only made the problem worse in that there are lots of things
missing from my xfce menu but still none of the things on there work.

I could use some help. Any thoughts/advice would be most welcome.

-- 
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/8053e414-a5f2-2d4c-fbda-f4b4e58a0e53%40larky.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firewall rules

[katerimmel]

> On 07/14/2016 04:51 PM, katerim...@sigaint.org wrote:
>>> On 07/14/2016 10:39 AM, katerim...@sigaint.org wrote:
 Good day
 I'm using a VPN in sys-net and would setup firewall rules to stop
 internet
 connection if VPN crash. In sys-net isn't possible to insert ip
 addresses,
 then I did it in sys-firewall. With some tests I saw that if VPN
 disconnect suddenly, sys-net finds my wifi network and doesn't break
 the
 connection, as I would. How can I solve this? (in the proxyVMs all
 work
 well)

 Thank you

>>> Take a look at https://www.qubes-os.org/doc/vpn/
>>>
>>> For leak protection and security it is best to set up a vpn client in a
>>> proxy vm, between sys-net and the appvms. You can follow the
>>> instructions from the doc "Using iptables and openvpn", or use the
>>> firewall script as an example. The two critical commands that prevent
>>> leaks (in the proxy vm configuration) are:
>>>
>>> iptables -I FORWARD -o eth0 -j DROP
>>> iptables -I FORWARD -i eth0 -j DROP
>>>
>>> This means that no forwarding can take place involving the
>>> upstream/clearnet interface eth0, so the only way out is through the
>>> vpn
>>> tunnel.
>>>
>>> Chris
>>>
>> Hi Chris
>> Thank you for the explanation, I want to know if I can use firewall tab
>> in
>> sys-net (or sys-firewall) like I have done in proxyVM because I have
>> also
>> a VPN in sys-net. If it isn't possible, do I change ip tables in sys-net
>> while in all the other proxyVMs I use firewall tab?
>>
>> Regards
>>
>
> The firewall tab (in any vm) is not a good place to add this restriction
> even if it did accept that kind of rule (which it does not). The best
> way is to run the vpn client in a separate proxy vm, and set the
> firewall rules with the qubes-firewall-user-script in that vm as shown
> in the doc.
>
> You can try to use qubes-firewall-user-script in the netvm, but I think
> this approach is untested. Of course, by Qubes standards it is insecure.
>
> Chris
>

Hi
I see also other commands but haven't understood what mean (qvpn group?)

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

Re: [qubes-users] [3.2rc2] Pulseaudio 100% CPU load at dom0

[entr0py]

David Hobach:
> On 08/31/2016 08:14 PM, entr0py wrote:
>> Eva Star:
>>> 3.2rc2 - clean install (on 3.2rc1 with updates I do not have this
>>> problem)
>>> 
>>> At dom0 pulseaudio proccess always eat 100% of CPU. If I kill it,
>>> then it starts again! Please, help. Hot to fix this issue or how
>>> to disable pulseaudio start after kill.
> 
> Same problem here, only by updating though.
> 
>> Had similar symptoms on Qubes 3.1. If you have multiple audio
>> adapters (ie Onboard + HDMI), disable one. (On KDE, it was
>> PulseAudio Volume Control > Configuration. Don't know XFCE.)
> 
> I also have multiple (incl. external). Disconnecting the external one
> does not appear to help though.
> 
> Pulseaudio child processes constantly die and get started again, i.e.
> the PID is changing every 1-2s. I guess that's not normal? Sound in
> VMs is stuttering.
> 
> rsyslogd also eats quite a lot of CPU, but I bet it's due to the
> pulse logs.
> 
> Sample log and /etc/pulse/default.pa attached.
> 
> Anyone got an idea?


In my case, the Onboard and HDMI adapters kept trying to connect, kicking out 
the other adapter. The machine would basically lock up every few seconds and 
CPU would max out. Same symptoms as you describe with the PIDs.

What I did specifically was go to Configuration tab and set Profile to 'Off'. 
One of the dom0 updates caused this setting to revert to its default. Perhaps 
you've got another adapter besides the USB, or the machine keeps looking for 
the disconnected adapter?

-- 
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/31a88ccf-899f-1748-385f-ff90b5d3b778%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anonymizing MAC adress through dvm ?

[nishiwaka46]

Thank you very much for your support :) I understand better how Qubes handles 
MAC addresses now thanks to you, I was curious about 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/ee8bda36-0533-4e7f-b6f9-8c33c35e03b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

[johnyjukya]

> On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz@gmail.com
> wrote:
>
>> An actual protection would be some kind of a chemical that would destroy
>> the ram chips if they ever reach certain (lower than room) temperature.
>
> the epoxy is likely to damage them in most means of removal.

I guess most people have shinier (literally, on the contacts) new hardware
than I do, but I know now and then I need to re-seat my RAM chips when the
system gets cranky.  Epoxy would a pretty costly measure (probably
destroying the motherboard as well as the RAM).  I guess I'd have to get a
shinier new mobo in that case.  :)

I think case security and case (and room) intrusion detection is a bit
more "civilized."

> i know of things that can do their damage when they reach a certain
> temperature or higher. never heard of one set off by going below a certain
> temp.

While interesting, that seems like a bad idea.  Unless you're UPS'd up and
never need to modify your hardware, insert/remove a card, whatever, you're
gonna have a bad day eventually and lose your ram/mobo.

> erasing on power loss would be good too, esp if the attacker doesnt know
> about it.

This, I do like, possibly hooked into case intrusion.  I might just look
into that myself, see if there's certain RAM pins that can be safely
grounded to wipe the RAM in a case of power outage.  I expect it's more
difficult than that, and that the RAM would have to be actively wiped,
since a power-off should basically be more or less equivalent to grounding
all the RAM pins, no?

Now, frying the memory with a high voltage zip from a charged up cap, say,
on some chip-enable line or whatever, if there is a case intrusion without
the proper trick done to disable it (such as a 16-dip-switch combination
lock that has to be set properly) might be kind of cool.  :)  You'd want
some gate to isolate that line (or thew whole chip) from the motherboard,
to protect it.

Maybe a capsule of acid on the ram chips (and contained to only affect
them) that gets popped on command.  It'd be fun to burn the sticky fingers
of any intruder, too.  :)  Getting a bit fanciful here...

On that same line of thought, sending 120V to the case if it's opened
while the power is on (which is the mode of action for a cold boot attack,
I assume?) might be fun.  You might want to remove your Underwriter's Lab
logo from the PC if you rig that up, lol.  Getting into "Home Alone"
territory.

If you keep your PC on when you're away from it (which I think is safer,
and I guess is the situation when you need protection from a cold boot
attack), you could do something like immediately start wiping the RAM upon
case intrusion.  That'd be harmless in the case of legitimate maintenance,
too.  Seems much cleaner.

I wonder what the most straight forward method of stopping all
multi-tasking and starting to wipe the ram would be.  Could a dom0 bash
script, watching an intrusion detection device, simply do an "xl pause" or
whatever on all VM's and start writing to some /proc memory device?

(That's probably not going to work, you'd need something more
ring-zero-ey...?  Perhaps in a device driver.  When I try to use my
on-board NVidia, it does a good job of locking up the computer and wiping
the RAM itself, after awhile, lol.)

It'd have to be reasonably fast at starting its work.  And writing to
4g/8g of memory is going to take some time, in the best case.  Which adds
points in the favour of the more destructive high-voltage zap method. 
(Maybe not a sequential write, but a bit more randomized one would thwart
any attacker better?)

There may be some existing work done on this for xen; I might do a bit of
research and report back if I find anything useful.

Interesting subjects to ponder.

In my case (pun intended), there's not anything sensitive or incriminating
on my drive or in memory; it's more a matter of protecting privacy and
attempting to stop ongoing harassment and illegal surveillance.

Stealing some work designs or code or personal information would be
annoying, but it wouldn't jeopardize my life, land me in jail, or have me
detained for waterboarded or anything.

So knowing someone was tampering is good enough for me, and what I have
personally focused upon.

I'd be interested in others' thoughts on leaving the PC on versus leaving
it off.  Lately, I've been leaving it on, but with an alternative OS
(another Linux) whose sole purpose is to know if somebody's been mucking
around.  My actual useful drive, data, passwords, go with me.

It's only slightly inconvenient, but so far it has been the quickest route
towards some peace of mind until I'm 100% confident in physical security
and tamper detection.

Sorry for any digression.

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 

[qubes-users] Blue/Purple Lock Flashing On-screen

[anthonythomassweeney]

For some reason a blue-purplish lock is flashing on my screen well browsing the 
computer. It only seems to happen when sys-Whonix is running, although, I could 
be wrong. Anyone know how to fix this? 

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

Re: [qubes-users] QubesOS under VMware - I know I know ...

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-01 23:51, p.@.com wrote:
> On Thursday, September 1, 2016 at 7:20:45 PM UTC+1, Andrew David Wong
> wrote:
>> Note that Qubes can be installed to a portable USB drive. It will run
>> more slowly from such a device, but it can make testing more accessible,
>> since it doesn't disturb your existing OS.
>> 
>> At least one user has reported success with booting Qubes under VMware,
>> but others have not been able to replicate these results:
>> 
>> https://github.com/QubesOS/qubes-issues/issues/2249
> 
> Thanks Andrew for the hint with USB. I imagine every time you reboot your 
> laptop to run your disk installed OS you loose everything you configured
> in your USB-based Qubes ?
> 

No, the installation is persistent. It's a standard installation, only with a
removable USB storage device as the installation target instead of an internal
drive. There's also a Live USB option, which is not persistent, but it hasn't
been updated in a while, so I recommend using a current release instead.

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

iQIcBAEBCgAGBQJXyTl4AAoJENtN07w5UDAw90kP/RItJOr3WtxvX2sLD2WrLnts
bqHtwNmhmAhq/FNCtAv4lS3LnrJeNTBrjZiloIhh1lHTveFqk5fo6UVd+FID0JWO
zABeQcLdr1yW2P6VFUQ6dAoT5YyMa8mdlJI28QwVecwX/qMBf8rENbUlOthC8/jM
LHvz1A94jS8tMm5SjH7Em+E31BqFUTTB73GID8+WNEB4aI6S4pnhEpawGpotS14h
8uPY7cuWznyrPmgYOHQouusco37pXZTjCbx8KLrcVWERZhuOOBIljI8cF/IxgiEB
Ko12gLVaZhNQT2erEJO8EpBICULAFR7jxdP7Zxqk6vCwx0GgGpc0kFARDtNuT0vZ
VeUmuX6eQQ+iLMLeVTEONyytMSI/+VDA4Q4V7XJgHMGxf1ARtTnlF/bNdlfuoAoJ
O9145XpM9UzKLOPMsZ7eXW68egOfvVww41+Mc74KWkxH7bJjfL2c8YhCUE8DPNTW
NtETcOSuaE6oYJ7i+H65DzK4ZSUFvaITAsVS8ZL7BSbPX9joP38oN5bkOBrk5Blp
j4dhpPaINEgi05c5w1mH5EhEkH4R4zi0JQTQK9uykaLbMeOswEwd/YJ2zUdsnjUa
d+6FZM9kDXYAS7VM9muxrTSrNMZU6d3PcGBRmdz0Tl2wzQLV4IU8rOhfJnWVOWzV
ASJbRhy1Vs87pkSApSd5
=9VdQ
-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/fb6321bc-eb89-d572-c64a-ba5dbae3904f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QubesOS under VMware - I know I know ...

[p.@.com]

On Friday, September 2, 2016 at 2:55:42 AM UTC+1, Drew White wrote:
> On ESXi I installed directly on ESXi 5.5, worked first time.

Which QubesOS version did you install on ESXi ?

Best regards
Przemek


-- 
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/726e6a02-13bb-41c0-9cc5-c662ca190914%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QubesOS under VMware - I know I know ...

[p.@.com]

On Thursday, September 1, 2016 at 7:20:45 PM UTC+1, Andrew David Wong wrote:
> Note that Qubes can be installed to a portable USB drive. It will run
> more slowly from such a device, but it can make testing more
> accessible, since it doesn't disturb your existing OS.
> 
> At least one user has reported success with booting Qubes under
> VMware, but others have not been able to replicate these results:
> 
> https://github.com/QubesOS/qubes-issues/issues/2249

Thanks Andrew for the hint with USB. I imagine every time you reboot your 
laptop to run your disk installed OS you loose everything you configured in 
your USB-based Qubes ?

-- 
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/d4a1b94c-31f2-4c48-b5c4-6cab5cb5cf44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.