[qubes-users] Re: Debian Template (and sub-vms) non interactive after package updates

['v3g4n' via qubes-users]

On 12/13/2016 08:33 PM, qubenix wrote:
> Boris Kourtoukov:
>> On Tuesday, December 13, 2016 at 3:11:12 PM UTC-5, qubenix wrote:
>>> Boris Kourtoukov:
 On Tuesday, December 13, 2016 at 2:49:23 PM UTC-5, qubenix wrote:
> Boris Kourtoukov:
>> This is similar to what happened with the Whonix discussion here: 
>> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ
>>
>> I am getting to this point:
>>
>> ```
>> ...
>> Waiting for VM's qrexec agent...connected
>> --> Starting Qubes GUId...
>> Connecting to VM's GUI agent: .connected
>> --> Sending monitor layout...
>> --> Waiting for qubes-session...
>> ```
>>
>> And then it waits forever. Attempting to open an app in any of the sub 
>> VMs fails with no (visual) feedback. 
>>
>> The Debian TemplateVM starts and runs. And if I get into it via:
>>
>> `virsh -c xen:/// console debian-9`
>>
>> I am able to run commands as root. 
>>
>> Unfortunately doing a dist-upgrade and checking for broken/unmet 
>> dependencies resulted in nothing (dist-upgrade updated 0 packages.) 
>> Everything appears to be installed correctly. 
>>
>> (I did a check with `debsums --changed` as well. it came up empty.)
>>
>> Any thoughts on what else to debug?
>>
> >From this discussion:
> https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com
>
> Start your template from gui or dom0 cli as you did. When you get to:
>
>> --> Waiting for qubes-session...
>
> `Ctrl-c` to stop the endless wait you described. Then (still from dom0) 
> do:
>
> qvm-run -p -u root debian-9 "apt-get update && apt-get install -t
> stretch xserver-xorg-core -y && apt-get dist-upgrade -y"
>
> Restart your template and see that you get display again, should fix it.
>
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

 It said the package was already at latest version. I proceeded to 
 `--reinstall` it and still no luck. Still sticks on waiting for 
 qubes-session.

>>> What version do you have installed?
>>>
>>> -- 
>>> qubenix
>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>>
>> 2:1.19.0-2
>>
> Ah, I think you need the repo `stretch-testing` from qubes. So do:
> 
> qvm-run -u root debian-9 'echo "deb [arch=amd64]
> http://deb.qubes-os.org/r3.2/vm stretch-testing main" >>
> /etc/apt/sources.list.d/qubes-r3.list'
> qvm-run -p -u root debian-9 "apt-get update && apt-get dist-upgrade -y"
> 
> Hopefully that will fix it. Sorry I forgot the repo had to be changed.
> 
Thanks for your post, it helped me get my debian 9 template back up and
running!

-- 
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/fdb55d7d-46fb-87fc-46d5-409295f428d3%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to manually remove a VM?

['v3g4n' via qubes-users]

On 12/19/2016 02:29 AM,
almightyl...@gmail.com wrote:
> So I made a HVM Template and renamed it through VM Manager, something went 
> wrong and the VM Manager did not reflect the name change. (Can't seem to 
> reproduce this bug)
> 
> I was just wondering if I've successfully removed the HVM Template manually. 
> The process I went through was:
> 
> 1. Remove template folder from /var/lib/qubes/vm-templates
> 2. Remove old template reference from VM Manager (or manually from qubes.xml)
> 3. Remove template's *.desktop files from ~/.local/share/applications
> 
> Is there any files I have missed? Also, perhaps a short doc with this would 
> be useful for when things go wrong and a VM needs to be manually removed.
> 
> Thanks
> 
I will let someone more knowledgeable on the manual removal process
answer, but why not just remove it using Qubes VM Manager? Just curious
about the manual process?

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

Re: [qubes-users] How to manually remove a VM?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-18 18:29, almightyl...@gmail.com wrote:
> So I made a HVM Template and renamed it through VM Manager,
> something went wrong and the VM Manager did not reflect the name
> change. (Can't seem to reproduce this bug)
> 
> I was just wondering if I've successfully removed the HVM Template
> manually. The process I went through was:
> 
> 1. Remove template folder from /var/lib/qubes/vm-templates 2.
> Remove old template reference from VM Manager (or manually from
> qubes.xml)

How did you perform this step? Did you manually edit qubes.xml?

> 3. Remove template's *.desktop files from
> ~/.local/share/applications
> 

I can't immediately think of anything else to remove. At any rate,
these should be the most important ones.

There's also:

qvm-remove --just-db 

which only removes the entry from the Qubes Xen DB without removing
any files. What exactly does "Xen DB" refer to in this context, Marek?

> Is there any files I have missed? Also, perhaps a short doc with
> this would be useful for when things go wrong and a VM needs to be
> manually removed.
> 
> Thanks
> 

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

iQIcBAEBCgAGBQJYV3gLAAoJENtN07w5UDAwzQAP/2mHEAZRHbCJDWvUB+MQ8QFt
oECgQ/sDRQOY9W1j6FPaVLAgCtFFUHFeBvbjezFTddutOqh4Y+s8Z+CiDu0gFQ99
LuDg+JhQc84ibGz+5YvZUJW2YROtKNY/mVwBsNw8BlFjlsns3TmxQgmcjXMQOAXQ
vGiO3mbxDZRDZ/1v8DtW1hCtlLxb/slUQsBGKaiRxYLYSMR/jHNNsMX5WKw0iubH
J0S7Iae94R/inhthDWr5vAvtvTJZrkzih4QUoKszHBpqVFW1rZV8ewg8FUZAayGR
+zmXLHCtlMnAMruqQXY6xbNreF3sb4fAckpHzKCWhZ88QM0HRSeIBJeEjoP0xMa0
ABUWAWCnSg3EJ+5aQH8Cl6SOoCo/xmiArlVbpFMgh7ymuqI7++XbxXXSDrz6L5ZG
pRT8Gt3mf3Y4ymjDgh2e6StezQ2l2iXOg4rpG83IT2jwpb4vUiYukNj8zUKCLTdo
n1z2hDtA6v4CMz8X6wF7KLcqMR++XNIzaDCRCgMGB6xezhipw7jyIVJHYIODnY1Q
OB06ciLmmq0aCWFLJ2t2SLm11iBPkK5YryUZxmhe+Lr+i2b18IUaRCwi88+auyhO
WEz44PJqiJq32YU0FHWXDs6EncqcZuCN7+Rt76fY9bzLxldCTcVdPboRSgaKasK/
eWeuHk1j65B/9m8yipf+
=sOuC
-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/27888952-d92f-0411-dcdc-b3c8d4a9fb12%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fedora 23 EOL December 20; Update Your Templates!

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-18 17:27, iamthech...@gmail.com wrote:
> Is there a guide to update an existing VM to Fedora 24 while
> preserving it's contents? I upgraded the template per the
> instructions [1], but can't figure out how to upgrade my existing
> VMs while saving their data.
> 
> I can do a fresh Qubes install if necessary but would rather avoid
> it, if possible.
> 
> [1] https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/
> 

If you're referring to TemplateBasedVMs such as AppVMs, then there's
no need to upgrade them. One of the main features of the template
system is that you only have to update and upgrade the templates, and
all VMs based on those TemplateVMs will get their root filesystems
from the TemplateVMs. So, just make sure that your TemplateBasedVMs
are based on your Fedora 24 TemplateVM(s), and you're good to go.

If, on the other hand, you're referring to Fedora StandaloneVMs, then
the procedure for upgrading those is the same as for TemplateVMs,
except that StandaloneVMs can't be `qvm-trim`ed (AFAIK).

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

iQIcBAEBCgAGBQJYV3EeAAoJENtN07w5UDAwLrsP/1gWnNwxn9xSr9m+8Zn5yuDV
vHLYyOIi2lc9RQ/1P5Eaicn/Dj+IwZaKXCEIsJF5/kye+JrdZ0MSBbhq4fUa5Kg5
0g07N0tguAu4Bp6auzthAnqDV+OuFNbOkNNnB+mt2kl3vsK+oeGNGmNakXP7CXWo
XsOhAZvhSzMVwo773nmgoTUGP7nI4GaYCGPVJJuE3CVOxYDYAihfnXTLgcEXi2t/
nh5uKomznLeAGclnY35uQXlRxMYswMrvpp8zAWWyRA0CDuLlLPV01H+dV+u8X3dt
cSwO8jRyCgsDoLdmMwOD7VCAN1uTdKXjhlS+FgozzQlh7WBC6dOlQ/qGBGQzj0qJ
f7b3x9blQxnJqUm36JLZhLnJapKQYEfwo4Fy8Bi8+/YBJzvHuBZBKi/6OP+fbfyr
7omTLUjsdAftSrQpnZ3AMZHxnu6hjop7xVA3eJrap9tDIDauTKZRFviYD5lO8gi2
/tzFBoMncAA3W7QUvwc3oTV22KO8iiz/4oEwYKd9QmIEiH9v39RFmdgNTxbzkdO5
5O1CLLH/JBJbWOfUQPsWFoiQ/yyPdWzDmO24MXNiN3Fm+esFuMY1+xZShbus70Fw
spruwnS05MYXWCQCvgA5TE/u/teS1HBCQWPOoAqRgXidEz6Lpp1tY8lEpV1fnk5u
l7oljTE9qALbkEVaR7yx
=ze63
-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/7d345d5f-e324-59d9-5752-ad194950096c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firewall Rules for Printer Access?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-18 15:16, superlative wrote:
> Hi, I read the instructions to configure a printer here 
> https://www.qubes-os.org/doc/network-printer/ . It says to 
> configure the Firewall to allow printer access. But when I get to 
> the template VM firewall rules, it asks for an URL or IP Address, 
> and I'm not sure how to add an address for my printer which is not 
> on the Internet. How do I "allow network access from the template 
> VM to [my] printer"?
> 
> Thank you.
> 

If it's a network printer, then you probably want to allow access to
whichever IP address it has on your local network, e.g., 192.168.1.102.

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

iQIcBAEBCgAGBQJYV22xAAoJENtN07w5UDAwpZUP/20Y6crlGyhZFxJ3hdeQeqV9
vQ+xlh4+jAtNM6phAtSnQw50FvZHvYM7YyOhKBejcIURshcXy0AaxLrJfDUBh/SX
p8vv4/ciQrE4j6dAjCLKuiPcIJhDLImnjJY+EbL13gYFhww2ZGQrTi4/CYhmam2q
yoidp2ju9OJQTC2mFaFUdYcsrkyH6YM06AwJp+qZb2/Zy72fj4Guc4Nz/KUr42Wo
Yfu1reluqG604z2Q9obfGYjz4Ou1K2bwkdsgob+nm5weLF+qD4RozKo+TvJc7kEN
0yPTp4X/ApuAWh1YIc+tiCiqm3BFCubhRhYNdtYLWW+/h5EGDm1O7BObwtJOCfkI
DlthIgpZ234i6++8PZrkQUea8vljDHWbwnBlPyN6T3uRoRpcmDfAZE9BIrfACW/c
FgiUIJsbSFuqsi6yjG7KlpxqK+RE1To1irXvQfUgpTO73OFavH4uxrLzlq18FkSc
azIod7E6pGhUABLrsk6qqt670sRk2tSg6TEdwBwzFZ0iS2KZY/35xfePk+65rB1c
sTrWzYCAvRbKZFN2I0cQYwF4gbwibKsBlUyM1N2Edn1pdGtlhkNPecn3aBmLkSpR
1oVpv0+QiDMv14Lg2Hu6E6WvxGmNUUJTXnMjQBGBzdUNYf3o3WSZHIgLUCmeldz/
HlLyBHO5qJ9OswK8YAwL
=9gFH
-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/a51c5efa-4427-0e1e-ad67-e70480c25fc2%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Screensavers : Qubes Questions!

[taii...@gmx.com]

As a tip if you desire to attempt gpu passthrough do not buy an NVIDIA 
card as they like to introduce driver "bugs" that make it difficult to 
try and entice you to buy a quadro.


--
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/706309c5-3b81-ac38-fd3f-217f2cdaae4e%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes refuses to boot

[taii...@gmx.com]

On 12/18/2016 07:32 PM, Chris Laprise wrote:


On 12/18/2016 05:15 PM, iReallyWantQubesToWork wrote:
I burned the Qubes ISO to a USB (using Rufus) and completed the 
installation without any problems, except that Qubes refuses to boot 
on the installed drive. I installed it onto my external HDD and have 
also installed it onto a 32 GB USB, but neither work, so the USB 
drive isn't the problem. I have also tried to boot it from several 
different computers, all with the same result. When I try to boot 
from the completed installation, all I get is a period and blinking 
underscore/console cursor that doesn't respond to keyboard input. I 
never see the GRUB menu. However, if I boot from the USB installation 
in Windows VMWare/VirtualBox or QEMU emulator, I can see the GRUB 
menu fine. My main computer has an Intel i7 2670QM CPU btw. Any help 
would be appreciated




Do you know if your system is set to boot in BIOS or UEFI mode? Maybe 
switching to BIOS/legacy mode would help.


Chris


Try enabling EFI-CSM mode in your BIOS configuration.

"awesomebunny777" damn thats a cool unique handle, takes me back to the 
earlier days of the internet before everyone on a mailing list had both 
a first and a last name.


--
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/8cc91302-199b-7d6d-2275-4f2ae0c496bd%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Screensavers : Qubes Questions!

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Mike,

Thanks for the questions. My replies are inline below. I'm also CCing
the qubes-users mailing list so that others can join and benefit from
the discussion. You can read more about our mailing lists here:

https://www.qubes-os.org/mailing-lists/

On 2016-12-18 19:28, Mike Mez wrote:
> Hello Sir. I saw you recently on the Screensavers! I have a few
> questions, and am hoping you can fill in some gaps.
> 
> 
> Before the questions, here is some context. I recently said enough
> is enough with Windows 10, and started looking towards alternative
> OSes, the big one being the many Ditros of Linux. Yet I can't totally
> be rid of windows 10, as the programs I use as my dally drivers such
> as 3ds Max, Photoshop, and Unreal 4 are basically windows only. As
> such I've also been looking into type one hypervisors like KVM and
> Xen. Hopefully you can see where I'm going with this. This is where
> my main interest in this OS comes in.
> 
> 
> It sounds to me like your group have basically made a VM OS. I'm
> imagining clicking an icon which I have designated as to be opened
> under a windows kernel (such as windows 10). Let's say click on a 3ds
> max Icon which opens up  just that application (not a windows VM
> window) calling on the hardware as if windows was bare metal, yet at
> the same time I can open Firefox and its running sandboxed under
> Qubes kernel all on the same machine with whatever hardware.  That's
> the dream, at least. (A Qubical with windows. :P)
> 
> 
> 
> 
> *(Compound) QUESTIONS! - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - *
> 
> *1.   *Would it be possible for me to use Qubes with a sandboxed 
> windows kernel so that I could boot windows based programs (or even
> Apple) inside the OS?  Is the dream I've written about above even
> possible in Qubes right now? In the future? At all?
> 

Basically, yes. You can use Qubes to run Windows programs in lightweight
AppVMs:

https://www.qubes-os.org/doc/windows-appvms/

Currently, Windows 7 is in testing. Support for Windows 8.1 and 10 is in
development. There is currently no Mac OS support.

> *2.   *You mentioned  during the interview that you came to Qubes
> as a lifelong widows user. I am in the situation when it comes to
> this as a lifelong windows user. What would you say is the learning
> curve for using Qubes is? How easy would it be for someone who is
> slightly technical, yet not IT, to problem solve a problem in Qubes?
> In windows I Ctrl+Alt+Del and go through that rigmarole.
> 

It depends highly on the individual, but if you're coming from a purely
Windows background, the biggest thing might be adjusting to a Linux
environment. In general, the most important qualities will be
perseverance, a willingness to learn, and the ability to solve your own
problems. (Of course, the mailing lists are here to help, but things
generally don't work very well if someone makes no effort and expects to
be spoon-fed solutions.)

> *3.   *I understand your OS is security based, and that is super
> cool. Yet security is useless if there is nothing to protect. "Out of
> the box" what can Qubes run?
> 

It's better to turn this question around: What *can't* Qubes run? It
sounds like the main problem in your case may be the lack of 3-D support:

https://www.qubes-os.org/doc/user-faq/#can-i-run-applications-like-games-which-require-3d-support

To get around this problem, you would have to attempt GPU passthrough,
which is not supported (but which some users have managed to achieve on
their own).

> *4.   *How easy is it to upgrade the OS? Does it require a
> reformatted drive or can I update at any time with no worries on
> existing data?
> 

The vast majority of new releases can be upgraded in-place without
affected existing data, programs, or settings. However, it's always
prudent to perform a backup before you upgrade any OS.

> *5.   *Is there anywhere other than your site where I can read up
> more about this OS?
> 

The main source of information about Qubes OS is the Qubes website, but
these mailing lists are an invaluable source of information, as well.
Whenever you have a question about Qubes, it's a good idea to search the
mailing lists to see whether you question has already been asked and
answered.

> *6.   *Does this OS work with the KDE Plasma Gui?
> 

Yes: https://www.qubes-os.org/doc/kde/

> *7.   *Anything else you can say about Qubes that I haven't
> asked?
> 

Please read through our documentation to learn more:

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

> Thank you for your time!
> 

Thanks for your interest in Qubes!

> 
> -Mike Mez
> 

Best,
Andrew

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

iQIcBAEBCgAGBQJYV2bXAAoJENtN07w5UDAwMVUQAIbHJSZUGIPtnJ8XOpfywCtG
CxbzKVZT2o2oTKNjK+M0vE2cFqjugWdhDW+vcTyWjk/oQedzUxgrjJ88zIGAdhVg

[qubes-users] Re: trying to use lxsession

['digitaldijjn' via qubes-users]

the only thing I found on the net is to do with broken desktop environments due 
to hardware limitations. I'm assuming the issue is with the fact that vms don't 
have a desktop manager. 

I just need a workaround so that I can mod the appearance. 

-- 
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/cef4abd0-326f-49fa-b821-88790d107ee8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to manually remove a VM?

[almightylaxz]

So I made a HVM Template and renamed it through VM Manager, something went 
wrong and the VM Manager did not reflect the name change. (Can't seem to 
reproduce this bug)

I was just wondering if I've successfully removed the HVM Template manually. 
The process I went through was:

1. Remove template folder from /var/lib/qubes/vm-templates
2. Remove old template reference from VM Manager (or manually from qubes.xml)
3. Remove template's *.desktop files from ~/.local/share/applications

Is there any files I have missed? Also, perhaps a short doc with this would be 
useful for when things go wrong and a VM needs to be manually removed.

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/65ffe4eb-85b6-434c-b043-0767fc202a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] trying to use lxsession

['digitaldijjn' via qubes-users]

I'm trying to use lxsession in order to use lxappearance in all my vms. I'm 
mainly just trying to alter the color scheme. when I tried to run it I get this:

** Message: main.vala:99: Session is (null)
** Message: main.vala:100: DE is (null)
** Message: main.vala:104: No session set, fallback to LXDE session
** Message: main.vala:110: No desktop environnement set, fallback to LXDE
** Message: main.vala:131: log directory: /home/user/.cache/lxsession/LXDE
** Message: main.vala:132: log path: /home/user/.cache/lxsession/LXDE/run.log

and then nothing, doesn't even return to the command line unless I ctrl-c

I tried running lxappearance without it but it doesn't seem to stick. 

any ideas?

-- 
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/c20a183c-9748-43b1-ba95-377e91b07882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fedora 23 EOL December 20; Update Your Templates!

[iamthechong]

Is there a guide to update an existing VM to Fedora 24 while preserving it's 
contents? I upgraded the template per the instructions [1], but can't figure 
out how to upgrade my existing VMs while saving their data.

I can do a fresh Qubes install if necessary but would rather avoid it, if 
possible.

[1] https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/

-- 
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/b303f059-7e7f-4dd2-8236-0d1a13883907%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes refuses to boot

[Chris Laprise]

On 12/18/2016 05:15 PM, iReallyWantQubesToWork wrote:

I burned the Qubes ISO to a USB (using Rufus) and completed the installation 
without any problems, except that Qubes refuses to boot on the installed drive. 
I installed it onto my external HDD and have also installed it onto a 32 GB 
USB, but neither work, so the USB drive isn't the problem. I have also tried to 
boot it from several different computers, all with the same result. When I try 
to boot from the completed installation, all I get is a period and blinking 
underscore/console cursor that doesn't respond to keyboard input. I never see 
the GRUB menu. However, if I boot from the USB installation in Windows 
VMWare/VirtualBox or QEMU emulator, I can see the GRUB menu fine. My main 
computer has an Intel i7 2670QM CPU btw. Any help would be appreciated



Do you know if your system is set to boot in BIOS or UEFI mode? Maybe 
switching to BIOS/legacy mode would help.


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/40730c54-05bc-2bab-b175-bfa4f5517676%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: BIOS Security Settings?

[raahelps]

On Sunday, December 18, 2016 at 11:15:59 AM UTC-5, 
'0194358'019438'0194328'01943 wrote:
> Hello,
> 
> does a BIOS password (against BIOS changes), gives a higher system security, 
> or it is more like a security fake and could be easily bypassed?
> 
> Should I switch the IME off?
> 
> Kind Regards

it can be bypassed and yes I believe most oem machines have backdoors.  I know 
a trick to bypass my dell desktop with a usb stick.  afterwards the bios passwd 
still prompts. It still errors if you type wrong passwd and works if typing 
correct one.  But if you leave it blank it passes lol

But I feel its still an extra layer of security, for a persistent and advanced 
attacker it might just mean 10 mins more of their time, but for someone else 
just being nosey, or if 15 mins is too long, it might mean not getting in at 
all. As an above poster noted too you could become aware of a change if it 
happens.


This topic makes me think of all the newly found exploits in grub passwords or 
some encryption password prompts like on ubuntu.   I always feel they are there 
on purpose.  Thinks like hitting backspace 20 times or holding enter down for 
some seconds.  simples of the simplest backdoors going years and years 
unnoticed.  It makes sense they would be undermined cause in so many irc 
chatrooms they are always being undermined.  You are either considered a 
criminal for wanting measures like this,  or naive for wanting something so 
trivial.

It basically depends on if it is too cumbersome for you to be bothered with or 
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/48d6e2d5-edc1-41cf-bc1f-50e9f9edff3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] using salt to install software in template-vms

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Dec 18, 2016 at 11:41:20PM +, john.david.r.smith wrote:
> On 18/12/16 23:04, Marek Marczykowski-Górecki wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On Sun, Dec 18, 2016 at 10:47:36PM +, john.david.r.smith wrote:
> > > hi.
> > > currently i am trying to configure salt to create and setup all my 
> > > templates
> > > and vms.
> > > 
> > > i managed to create the vms and do the config in dom0.
> > > 
> > > then i tried to install software in my template-vms, but this failed.
> > > 
> > > my top:
> > > base:
> > >   tmp-salt: #this is a template (a clone of fedora-23)
> > > - q
> > >   app-salt: #this is an appvm (based on fedora-23)
> > > - q
> > > 
> > > my q.sls:
> > > /home/user/q:
> > >   file.touch
> > > pkgs:
> > >   pkg.installed:
> > > - pkgs:
> > >   - htop
> > > 
> > > both vms (tmp-salt, app-salt) contain the file q.
> > > no vm has the software installed (this is expected for the appvm).
> > You mean template too? Check salt output
> > (/var/log/qubes/mgmt-tmp-salt.log) for details - maybe this package is
> > unavailable, or there was some network problem.
> 
> ok, it was a problem with one of the packages from the list (i omitted all
> but one in this mail)
> it was the package vim.
> if i omit it, all other packages get installed.
> strangely i can install vim via `dnf install vim` or `yum install vim`.
> what could be the reason for this?

I think the package is called 'vim-enhanced' and provides virtual name
'vim'. Not sure why virtual name does not work with salt, but I've see
such thing before. Maybe there some option for pkg.installed?

> > > both vms have an empty folder from their configuring salt management vm.
> > > as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a
> > > torvm and sys-firewall.
> > > 
> > > what am i doing wrong?
> > 
> > You mean /srv there? This is expected. Configuration is copied
> > temporarily there, into /tmp. This is how salt-ssh works. And thanks to
> > salt-ssh, you don't have to install salt in every template to use it to
> > manage VMs. Just default template is enough.
> 
> i mean the folder /home/user/QubesIncoming/disp-mgmt-tmp-salt
> (it still is created with my now working sls)

Ah, yes. Internally qvm-copy-to-vm mechanism is also used, which copy
the files there. Probably should be cleaned up after the operation...

- -- 
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

iQEcBAEBCAAGBQJYVyF0AAoJENuP0xzK19csV5EIAJg7MJxPaSqMmd/KcKJeukiZ
eubQ/s75838gr4ABwHTfUN4PBScZPUPLqcAfkMLqaSvgH/inYGP9UAKbIZzBykLm
FlYuqaO22ZFXHJfTTNEaZ0c44YH9PUzKalLiVP+h0qKTyJPj9TQo7OT+yYZe++79
ZEIeSoFeT4U1snE+/2wukkyVPFowuG4/CTQ2zJv9r0+GM/i7X8/SuIU2e7p2+qNF
JzbVAA4QKVJQ/6fCkd7ZTvn7/MTa/FojsXQLKjXDc6eM1AlNKrzgjmc1d5n1Y9V7
40l4hKujdhapXj7u1tOJkpSQ8PhCks5dbyPU/oN0K5MC4des0pIOmUrdCZ0KJy8=
=uJG9
-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/20161218235323.GZ1239%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Firewall Rules for Printer Access?

[raahelps]

On Sunday, December 18, 2016 at 6:16:08 PM UTC-5, superlative wrote:
> Hi,
> I read the instructions to configure a printer here 
> https://www.qubes-os.org/doc/network-printer/ . It says to configure the 
> Firewall to allow printer access. But when I get to the template VM firewall 
> rules, it asks for an URL or IP Address, and I'm not sure how to add an 
> address for my printer which is not on the Internet. How do I "allow network 
> access from the template VM to [my] printer"?
> 
> Thank you.

you would only allow temporary network access to the templatevm to test the 
printer.  you can right click the templatevm name in qubes-manager and hit edit 
firewall rules.

after shutting down the template set your appvm firewall rules accordingly and 
restart it.  default is to allow all outgoing so you shouldn't have to worry 
about setting anything, unless you've made custom changes.

-- 
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/643cd140-d3f9-4a81-b831-275a65749b8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] using salt to install software in template-vms

[john.david.r.smith]

On 18/12/16 23:04, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Dec 18, 2016 at 10:47:36PM +, john.david.r.smith wrote:

hi.
currently i am trying to configure salt to create and setup all my templates
and vms.

i managed to create the vms and do the config in dom0.

then i tried to install software in my template-vms, but this failed.

my top:
base:
  tmp-salt: #this is a template (a clone of fedora-23)
- q
  app-salt: #this is an appvm (based on fedora-23)
- q

my q.sls:
/home/user/q:
  file.touch
pkgs:
  pkg.installed:
- pkgs:
  - htop

both vms (tmp-salt, app-salt) contain the file q.
no vm has the software installed (this is expected for the appvm).

You mean template too? Check salt output
(/var/log/qubes/mgmt-tmp-salt.log) for details - maybe this package is
unavailable, or there was some network problem.


ok, it was a problem with one of the packages from the list (i omitted 
all but one in this mail)

it was the package vim.
if i omit it, all other packages get installed.
strangely i can install vim via `dnf install vim` or `yum install vim`.
what could be the reason for this?


both vms have an empty folder from their configuring salt management vm.
as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a
torvm and sys-firewall.

what am i doing wrong?


You mean /srv there? This is expected. Configuration is copied
temporarily there, into /tmp. This is how salt-ssh works. And thanks to
salt-ssh, you don't have to install salt in every template to use it to
manage VMs. Just default template is enough.


i mean the folder /home/user/QubesIncoming/disp-mgmt-tmp-salt
(it still is created with my now working sls)

-john

--
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/ea9d7bc6-877a-1728-09e7-0a7cfb363999%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Firewall Rules for Printer Access?

[superlative]

Hi,
I read the instructions to configure a printer here 
https://www.qubes-os.org/doc/network-printer/ . It says to configure the 
Firewall to allow printer access. But when I get to the template VM firewall 
rules, it asks for an URL or IP Address, and I'm not sure how to add an address 
for my printer which is not on the Internet. How do I "allow network access 
from the template VM to [my] printer"?

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/c129c20c-f88a-4960-a003-871f1658188e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: HCL - Custom AMD APU build

[superlative]

On Thursday, December 15, 2016 at 1:12:29 AM UTC-8, Andrew David Wong wrote:
> It's just a matter of your personal privacy needs. There might be
> unique serial numbers associated with your physical hardware. For
> most people, this isn't a problem, but if you're a human rights
> activist living under a totalitarian regime who communicates online
> under a pseudonym, for example, then it's conceivable that the regime
> might use this information to link the psuedonym under which you
> submit the .cpio.gz file to the identity under which you purchased the
> hardware.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org

Thanks for letting me know. I wonder if installing a script to run such a 
command to find serial numbers is how governments deanonymize Tor users?

I'll definitely not be submitting that information. Thanks for letting me know 
how much of a risk it is.

Cheers

-- 
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/caf8ecda-b120-43bf-a512-902b52d9f532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] using salt to install software in template-vms

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Dec 18, 2016 at 10:47:36PM +, john.david.r.smith wrote:
> hi.
> currently i am trying to configure salt to create and setup all my templates
> and vms.
> 
> i managed to create the vms and do the config in dom0.
> 
> then i tried to install software in my template-vms, but this failed.
> 
> my top:
> base:
>   tmp-salt: #this is a template (a clone of fedora-23)
> - q
>   app-salt: #this is an appvm (based on fedora-23)
> - q
> 
> my q.sls:
> /home/user/q:
>   file.touch
> pkgs:
>   pkg.installed:
> - pkgs:
>   - htop
> 
> both vms (tmp-salt, app-salt) contain the file q.
> no vm has the software installed (this is expected for the appvm).

You mean template too? Check salt output
(/var/log/qubes/mgmt-tmp-salt.log) for details - maybe this package is
unavailable, or there was some network problem.

> both vms have an empty folder from their configuring salt management vm.
> as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a
> torvm and sys-firewall.
> 
> what am i doing wrong?

You mean /srv there? This is expected. Configuration is copied
temporarily there, into /tmp. This is how salt-ssh works. And thanks to
salt-ssh, you don't have to install salt in every template to use it to
manage VMs. Just default template is enough.

- -- 
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

iQEcBAEBCAAGBQJYVxYWAAoJENuP0xzK19csxIYH/jVc2/B0jqQd8nKMtJA1WKdU
s9SxtQTWIOS6WHfbSp43H8/XNRvzv/4gJlx2ISe7zC8khGe25oJ5NiYh7xDqZWi7
Pat17q086NAEeyVctr5hBZvKFJCHEfzyAsZCkRQ58Tw0S0fq1SXPOywJ7jpTfDXh
dDe4vFFaTOKAM8fTajRS8H57MXwxqnq6qM+13gzfkoljc1tejCosvp/blr7VZVGv
msfNBfWwY6OIrGT/csXhdMZ6tE0ZBt3iEOaAczogTQP9VgYYSGurX+SdVDry7RGn
mE6QEnOOrS+0IQJ4dTZTh9S7MEo8g32QcQikSSmCapUhzP+s/y4QvCrjmA0SjdM=
=9Drv
-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/20161218230453.GY1239%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] using salt to install software in template-vms

[john.david.r.smith]

hi.
currently i am trying to configure salt to create and setup all my 
templates and vms.


i managed to create the vms and do the config in dom0.

then i tried to install software in my template-vms, but this failed.

my top:
base:
  tmp-salt: #this is a template (a clone of fedora-23)
- q
  app-salt: #this is an appvm (based on fedora-23)
- q

my q.sls:
/home/user/q:
  file.touch
pkgs:
  pkg.installed:
- pkgs:
  - htop

both vms (tmp-salt, app-salt) contain the file q.
no vm has the software installed (this is expected for the appvm).
both vms have an empty folder from their configuring salt management vm.
as updatevm i tried a tor-gw, an updatevm (based on fedora-23) behind a 
torvm and sys-firewall.


what am i doing wrong?

-john

--
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/2e751f4e-17d7-a46a-234d-c3b35df6386b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Atheros ath9k wireless pci-e not functional in Fedora-24 template

[entr0py]

Marek Marczykowski-Górecki:
> On Sat, Dec 17, 2016 at 10:56:12AM -0800, 3n7r0...@gmail.com wrote:
>> On Friday, December 16, 2016 at 8:36:53 PM UTC, 3n7r...@gmail.com wrote:
>>> ath9k is a well supported driver in Linux. Present in kernel since 2.6. 
>>> (https://wireless.wiki.kernel.org/en/users/drivers/ath9k) Card is 5+ year 
>>> old implementation.
>>>
>>> Tested and working in a Fedora-25 LiveCD without any additional 
>>> configuration. (Kernel 4.8)
>>>
>>> In Qubes 3.1, added as PCI device to a Fedora-24 TemplateVM. (Kernel 4.1) 
>>> ath9k driver is correctly loaded but device does not show up in `iwconfig`.
>>>
>>>
>>> $ lspci -k | grep -A 3 -i network
>>> 00:00.0 Network controller: Qualcomm Atheros AR5418 Wireless Network 
>>> Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01)
>>> Kernel driver in use: ath9k
>>> Kernel modules: ath9k
>>>
>>>
>>> $ iwconfig
>>> lono wireless extensions.
>>>
>>>
>>> [1.980648] pcifront pci-0: Installing PCI frontend
>>> [1.980706] pcifront pci-0: Creating PCI Frontend Bus :00
>>> [1.980732] pcifront pci-0: PCI host bridge to bus :00
>>> [1.980736] pci_bus :00: root bus resource [io  0x-0x]
>>> [1.980740] pci_bus :00: root bus resource [mem 
>>> 0x-0xf]
>>> [1.980743] pci_bus :00: root bus resource [bus 00-ff]
>>> [1.980877] pci :00:00.0: [168c:0024] type 00 class 0x028000
>>> [1.981171] pci :00:00.0: reg 0x10: [mem 0xf7d0-0xf7d0 64bit]
>>> [1.983450] pci :00:00.0: supports D1
>>> [1.984459] pcifront pci-0: claiming resource :00:00.0/0
>>> [2.028350] alg: No test for crc32 (crc32-pclmul)
>>> [2.07] intel_rapl: Found RAPL domain package
>>> [2.033344] intel_rapl: Found RAPL domain core
>>> [2.131727] EXT4-fs (xvdb): mounted filesystem with ordered data mode. 
>>> Opts: discard
>>> [2.140627] cfg80211: Calling CRDA to update world regulatory domain
>>> [2.146866] cfg80211: World regulatory domain updated:
>>> [2.146873] cfg80211:  DFS Master region: unset
>>> [2.146875] cfg80211:   (start_freq - end_freq @ bandwidth), 
>>> (max_antenna_gain, max_eirp), (dfs_cac_time)
>>> [2.146898] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
>>> 2000 mBm), (N/A)
>>> [2.146903] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 
>>> KHz AUTO), (N/A, 2000 mBm), (N/A)
>>> [2.146908] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 
>>> 2000 mBm), (N/A)
>>> [2.146912] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 
>>> KHz AUTO), (N/A, 2000 mBm), (N/A)
>>> [2.146918] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 
>>> KHz AUTO), (N/A, 2000 mBm), (0 s)
>>> [2.146923] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 
>>> 2000 mBm), (0 s)
>>> [2.146927] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 
>>> 2000 mBm), (N/A)
>>> [2.146932] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), 
>>> (N/A, 0 mBm), (N/A)
>>> [2.176424] ath9k :00:00.0: Xen PCI mapped GSI17 to IRQ31
>>> *[2.314703] BUG: unable to handle kernel paging request at 
>>> c96c0040
>>> *[2.314712] IP: [] iowrite32+0x38/0x40
>>> [2.314718] PGD 3fdd1067 PUD 3fdd0067 PMD 3ade1067 PTE 8010f7d00075
>>> *[2.314723] Oops: 0003 [#1] SMP 
>>> [2.314726] Modules linked in: ath9k(+) ath9k_common ath9k_hw ath 
>>> mac80211 cfg80211 rfkill intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp 
>>> crct10dif_pclmul crc32_pclmul crc32c_intel pcspkr xen_pcifront xenfs 
>>> dummy_hcd udc_core xen_privcmd u2mfn(O) xen_blkback nf_conntrack_pptp 
>>> nf_conntrack_proto_gre nf_conntrack xen_blkfront
>>> *[2.314748] CPU: 0 PID: 214 Comm: systemd-udevd Tainted: G   O  
>>>   4.1.24-10.pvops.qubes.x86_64 #1
>>> [2.314763] RSP: e02b:88003cab7870  EFLAGS: 00010296
>>> [2.314766] RAX:  RBX: 88003c2ed3a0 RCX: 
>>> 0004
>>> [2.314769] RDX: c96c0040 RSI: c96c0040 RDI: 
>>> 
>>> [2.314772] RBP: 88003cab78a8 R08: 000186a0 R09: 
>>> 88003d001800
>>> [2.314775] R10: 88003d001800 R11: 5dc5 R12: 
>>> 
>>> [2.314778] R13: 0100 R14: a027b550 R15: 
>>> 88003c910028
>>> [2.314783] FS:  7f502afb68c0() GS:88003f80() 
>>> knlGS:
>>> [2.314788] CS:  e033 DS:  ES:  CR0: 80050033
>>> [2.314791] CR2: c96c0040 CR3: 3c9a5000 CR4: 
>>> 00042660
>>> [2.314794] Stack:
>>> [2.314797]  a02910b5 8098  
>>> 88003c910028
>>> [2.314802]  88003c910078 0100 a027b550 
>>> 88003cab78c8
>>> [2.314807]  a0239de2 88003c910078 88003c910028 
>>> 88003cab78e8
>>> [2.314813] Call Trace:
>>> [2.314820]  [] ? 

[qubes-users] Re: Nvidia drivers in dom0 still works? (need to get a GTX 1070 off the ground)

[Mathew Evans]

Just to update.

I am currently running Nvidia drivers without a issue.

dom0 Kernel: 4.4.31-11
Nvidia: 375.20
Kernel-module: compiled in dom0; 

Quick Guide:
1. dom0:   qubes-dom0-update install gcc devel-kernel ksmod linux-headers
2. appvm:  download NVIDIA-Linux-375.20-install.run (any appvm)
3. dom0:   qvm-run --pass-io  'cat /PATH/TO/NVIDIA.run' > NVIDIA.run
4. dom0:   ./NVIDIA.run --ui=none --no-x-check --keep --extract-only 
5: dom0:   cp NVIDIA-*/kernel/;  IGNORE_XEN_PRESENCE=y CC="gcc 
-DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" make module;
6: dom0:   cp nvidia.ko /lib/modules/4.4.31-11.pvops.qubes.x86_64/extra/.
7: dom0:   depmod -a; modinfo nvidia (all working will show up fine)
8: dom0:   EDIT GRUB or EFI; add rd.driver.blacklist=nouveau
9: dom0;   reboot and enjoy nvidia support.

additional: you can install nvidia extra apps etc.. if you so wish just run 
./nvidia.run --no-kernel-module -a


Hopefully this will help those of you wanting Nvidia driver instead of Nouveau.
Please note this is a ruff write up and guide not a perfect solution, and 
assumptions are made that you are always fimilar enough with *nix operating 
systems to figure out that parts i've missed out or aint put in detail.

-- 
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/5821c9b3-27a8-4853-9933-1a6e406bef57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes refuses to boot

[iReallyWantQubesToWork]

I burned the Qubes ISO to a USB (using Rufus) and completed the installation 
without any problems, except that Qubes refuses to boot on the installed drive. 
I installed it onto my external HDD and have also installed it onto a 32 GB 
USB, but neither work, so the USB drive isn't the problem. I have also tried to 
boot it from several different computers, all with the same result. When I try 
to boot from the completed installation, all I get is a period and blinking 
underscore/console cursor that doesn't respond to keyboard input. I never see 
the GRUB menu. However, if I boot from the USB installation in Windows 
VMWare/VirtualBox or QEMU emulator, I can see the GRUB menu fine. My main 
computer has an Intel i7 2670QM CPU btw. Any help would be 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/10af587a-a614-4008-921b-b8291aa9a8f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: BIOS Security Settings?

[taii...@gmx.com]

On 12/18/2016 03:29 PM, Nicklaus McClendon wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/18/2016 03:17 PM, taii...@gmx.com wrote:

Some laptops such as dell latitudes/precisions have a "master
recovery password" that is generated from the current serial number
of the laptop (so do thinkpads) "Cannot be bypassed" - well you
could always clip on a eprom writer to the chip correct? I assume
then you could force it to spill.

Entering the password on a latitude/precision then resets the
serial number and you have to re-enter it, you're now thinking that
you could simply do this to make a code that no one knows however
on the pre-boot authentication screen it helpfully provides the
current serial number.

BIOS passwords and PBA schemes are simply another layer in
security, ideally you would have both a password and a smart-card
so somebody can't simply do shoulder surfing password recovery and
then be able to steal your laptop. (Most business laptops have a
contact-smart card reader).


Yes you should switch off ME, although "Disabled" means something
different to intel than it does to you and me - it isn't really
off. If you do that you will have to blacklist intel_ips kernel
module to prevent log spam of "ME Hung"

There is a project from some coreboot developers that is able to
nerf (not remove) ME from most systems (caution - may brick your
mobo - do not perform without an external eeprom flashing device)
although of course you're still stuck with the proprietary bios and
FSP on anything recent.


I was unaware that the master recovery password existed for Thinkpads
and hadn't been able to find any sort of thing when I searched
previously, I'd be interested to see your source. The official Lenovo
help page suggests that it does not exist.
https://support.lenovo.com/us/en/documents/ht036206#super
You could clip on analysis tools, as I mentioned as "digital analysis
of the chip itself", perhaps analog analysis is more correct in this cas
e.

- -- 
kulinacs 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAlhW8ZAACgkQuXLc0JPg
MlZbnQ/9Eoc7DwTp66EaV+tOWNaCKvaP5C1x3N8ObSlvUMxn/Lphl3chrgA5yrbW
zwMhnZrBPjpzL4a7WHcAg/1tAOoo+zX1yQLXttO8TqAnnthJMgBdd0RA5fBCAccu
KAFrwqQB8y/7m1ZQtSzA+pd/JXuStqfI6Z8NXybU1BaOWq0/HMaJeplPj5ch6ZtV
4/vB7Ox9ot92QULLIbEKpBcmnBT9hSKdfSHI+LdBBZK25oYK7E8YuGe4EwPyqvYj
EFz/tKBEKAq+gvsTb7qj0L8ZyCHUSRF3YxXfTfltAaZFFcblywc3DOIEnz/Xi1un
mL/uMgb6ssqAwYUcm2CAUNIBMKhpSroPAi2J88kZq5u/ii7p50Ay+Hg8teXl1cpg
gloWsEIuFtda9O3qt7GEO/CftlX9s47PN/eZz+txZsVLucXjdKcoKy+NUUzClqzC
7RI4aOcddNzUP1Uk2Dvt/cnXuUBSq/+H5L96IhFhI6g6DzzDcZ1I6LOydOrys6bm
cWoUyvvnKEKfdxpEdTIY2aS1MtvJyqV2AZGRIDShQYwNv7v/kG1tCjD8xncUAdrF
RJ7Tvfiqsh4VQRsWmYsbuIVe8bH3s33Q3RMXEj7OXAgPWQy8QyDlwbf6/+Yhaei9
gpeDvwSq99+YyM0uQfWqW+NEIX0Xi1rlcUuIVLf+D/eGo0+qfys=
=nDod
-END PGP SIGNATURE-


Hmm my mistake then (if we trust what superfish lenovo says)
I had recalled someone a few years back telling me that there was one.

BTW It seems there is a ready made tool for resets
http://www.ja.axxs.net/
neato.

--
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/fdf5979a-076b-5bb1-0dc1-89cccdd26853%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: [qubes-users] Qubes using Cloudflare - Why?

[taii...@gmx.com]

On 12/17/2016 10:52 PM, Andrew David Wong wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 18:33, taii...@gmx.com wrote:

How come you guys use cloudflare?

The main reasons are:

1. A core tenet of the Qubes philosophy is "Distrust the
infrastructure," where "the infrastructure" refers to things like
hosting providers, CDNs, DNS services, package repositories, email
servers, PGP keyservers, etc. (This includes Cloudflare, of course.)
We focus on securing the endpoints instead of attempting to secure
"the middle" (i.e., the infrastructure), since one of our goals is
for users to have to entrust their security to as few entities as
possible (ideally, only themselves).

Users can never fully control all the infrastructure they rely
upon, and they can never fully trust all the entities who do control
it. Therefore, we believe the best solution is not to attempt to
make the infrastructure trustworthy, but instead to concentrate on
solutions that obviate the need to do so. We believe that many
attempts to make the infrastructure appear trustworthy actually
provide only the illusion of security and are ultimately a
disservice to real users. Since we don't want to encourage or
endorse this, we make our distrust of the infrastructure explicit.

2. It's free (as in beer). We'd have to spend either time or money to
implement a solution ourselves or pay someone to do so, and we can't
spare either one right now.

3. It has low admin/overhead requirements, which is very important,
given how little time we have to spare.


They have a dangerous monopoly on internet services and
discriminate against people using VPN's and the like, by insisting
that you enable javascript and perform a captcha even for simply
viewing a website and by subverting them a hostile actor would
effectively own most of the internet.

I'm not sure about VPNs, but we explicitly whitelist Tor exit nodes in
Cloudflare, so there should be minimal (if any) CAPTCHAs if you browse
our website over Tor (which is much better for strong privacy than
using a VPN).

As for enabling Javascript, this shouldn't be much of a problem for
Qubes users, since they can simply use a DispVM, or have a dedicated
VM for untrusted browsing.

In general, though, I agree that Cloudflare has some undesirable
qualities. If you're aware of a similar solution that doesn't suffer
from these drawbacks (and that satisfies the three requirements listed
above), then by all means, please let us know.


They also have a curious policy in regards to protecting terrorist
  websites, I do not think that that is done out of some want for
total freedom of speech as that reasoning wouldn't mesh with the
other decisions they make.

I don't know anything about this, but if it's true, it's certainly
troubling. Again, if you're aware of a similar solution that doesn't
have such problems (and that satisfies the three requirements listed
above), then by all means, please let us know.


Pre-emptive q/a: "it is okay because we have gpg key verified
downloads" Which is fine, until someone changes the signature
files and the key id that users should fetch.

This is why users are explicitly instructed to verify key fingerprints
using out-of-band (i.e., multiple) channels:

https://www.qubes-os.org/doc/verifying-signatures/


"web of trust key signing protects you" Which again, is fine,
until the key server you use runs cloudflare as well,

We don't really rely on WoT so much as verifying key fingerprints, but
isn't the point of WoT that it doesn't have to assume trustworthy
keyservers?


or you're stuck at the catch-22 of verification with trusting
trust and besides most users don't check that anyway.

Are you referring to the classic "Reflections on Trusting Trust"
paper? It's not clear to me what you have in mind here.


"without cloudflare someone could just get a corrupt CA to issue a
fake cert so hey it doesn't matter" And that would be detected
with certificate patrol.

There are still a lot of infrastructure-related problems (i.e., attack
vectors) that this doesn't rule out, like an attacker gaining access
to the server itself.


"butyou ask for a change that may only provide minor
protection!" Security isn't about 100%, it is about layering until
you are not the path of least resistance - 99.9%

True, but it's also about the cost-benefit analysis, and in our case,
the costs of implementing and maintaining a solution ourselves are too
high right now.


https://en.wikipedia.org/wiki/Cloudflare#Criticism_.26_Controversies
If that hacker didn't use the exploit for a super petty reason we
probably would have never known.

I can't tell which incident this is referring to, but, in general, I
think the principle of distrusting the infrastructure applies here.


Other associated problems: * The qubes-os.org site certificates
are only 2048bit, not good enough.

My impression is that many reputable 

Re: [qubes-users] Re: BIOS Security Settings?

[Nicklaus McClendon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/18/2016 03:17 PM, taii...@gmx.com wrote:
> Some laptops such as dell latitudes/precisions have a "master
> recovery password" that is generated from the current serial number
> of the laptop (so do thinkpads) "Cannot be bypassed" - well you
> could always clip on a eprom writer to the chip correct? I assume
> then you could force it to spill.
> 
> Entering the password on a latitude/precision then resets the
> serial number and you have to re-enter it, you're now thinking that
> you could simply do this to make a code that no one knows however
> on the pre-boot authentication screen it helpfully provides the
> current serial number.
> 
> BIOS passwords and PBA schemes are simply another layer in
> security, ideally you would have both a password and a smart-card
> so somebody can't simply do shoulder surfing password recovery and
> then be able to steal your laptop. (Most business laptops have a
> contact-smart card reader).
> 
> 
> Yes you should switch off ME, although "Disabled" means something 
> different to intel than it does to you and me - it isn't really
> off. If you do that you will have to blacklist intel_ips kernel
> module to prevent log spam of "ME Hung"
> 
> There is a project from some coreboot developers that is able to
> nerf (not remove) ME from most systems (caution - may brick your
> mobo - do not perform without an external eeprom flashing device)
> although of course you're still stuck with the proprietary bios and
> FSP on anything recent.
> 
I was unaware that the master recovery password existed for Thinkpads
and hadn't been able to find any sort of thing when I searched
previously, I'd be interested to see your source. The official Lenovo
help page suggests that it does not exist.
https://support.lenovo.com/us/en/documents/ht036206#super
You could clip on analysis tools, as I mentioned as "digital analysis
of the chip itself", perhaps analog analysis is more correct in this cas
e.

- -- 
kulinacs 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAlhW8ZAACgkQuXLc0JPg
MlZbnQ/9Eoc7DwTp66EaV+tOWNaCKvaP5C1x3N8ObSlvUMxn/Lphl3chrgA5yrbW
zwMhnZrBPjpzL4a7WHcAg/1tAOoo+zX1yQLXttO8TqAnnthJMgBdd0RA5fBCAccu
KAFrwqQB8y/7m1ZQtSzA+pd/JXuStqfI6Z8NXybU1BaOWq0/HMaJeplPj5ch6ZtV
4/vB7Ox9ot92QULLIbEKpBcmnBT9hSKdfSHI+LdBBZK25oYK7E8YuGe4EwPyqvYj
EFz/tKBEKAq+gvsTb7qj0L8ZyCHUSRF3YxXfTfltAaZFFcblywc3DOIEnz/Xi1un
mL/uMgb6ssqAwYUcm2CAUNIBMKhpSroPAi2J88kZq5u/ii7p50Ay+Hg8teXl1cpg
gloWsEIuFtda9O3qt7GEO/CftlX9s47PN/eZz+txZsVLucXjdKcoKy+NUUzClqzC
7RI4aOcddNzUP1Uk2Dvt/cnXuUBSq/+H5L96IhFhI6g6DzzDcZ1I6LOydOrys6bm
cWoUyvvnKEKfdxpEdTIY2aS1MtvJyqV2AZGRIDShQYwNv7v/kG1tCjD8xncUAdrF
RJ7Tvfiqsh4VQRsWmYsbuIVe8bH3s33Q3RMXEj7OXAgPWQy8QyDlwbf6/+Yhaei9
gpeDvwSq99+YyM0uQfWqW+NEIX0Xi1rlcUuIVLf+D/eGo0+qfys=
=nDod
-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/f7c5e8c9-7a04-e0f5-5857-6ff59179c015%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Chainloading to the Qubes bootloader

[justin . holguin]

On Tuesday, December 6, 2016 at 12:18:09 PM UTC-8, justin.h...@gmail.com wrote:
> My primary OS is Ubuntu and it's likely to stay that way (I need 
> vagrant/virtualbox for work), but I'd like to spend some time using Qubes 
> when I can. 
> 
> In my ideal setup, my laptop would boot into Ubuntu by default, but have a 
> grub entry to switch over to the Qubes bootloader on demand.
> 
> This setup isn't covered by https://www.qubes-os.org/doc/multiboot/ so I 
> figured I'd give it a shot myself.
> 
> I installed Qubes, but elected not to make the install device bootable (since 
> I want to keep Ubuntu in charge of booting). Then I found the Qubes 
> bootloader partition at /dev/sda7 and attempted to add a chainloader entry to 
> /etc/grub.d/40_custom like this:
> 
> menuentry "Qubes Chainloader" {
>   insmod chain
>   insmod ext2
>   set root=(hd0,gpt7)
>   chainloader /EFI/qubes/xen-4.6.1.efi
> }
> 
> I can select 'Qubes Chainloader' at the grub menu, but it just flashes a 
> message (I think it's something like "Loading xen-4.6.1.efi") for the 
> briefest instant before dumping me back into grub. For what it's worth, I 
> know it's at least finding the .efi file because it no longer complains that 
> it can't.
> 
> TL/DR: what can I put in /etc/grub.d/40_custom to chainload the Qubes /boot 
> partition at /dev/sda7?

Just closing the loop here. I couldn't get Qubes to boot in the original setup, 
so I decided to try again from scratch and ended up finding a pretty easy 
solution that works well for me.

1. I installed Ubuntu 16.10 with the default partition scheme.
2. I used gparted to free up 60gb of free space at the end of the drive for 
Qubes.
3. I ran the Qubes installer and let it automatically manage that 60gb. I 
didn't change any settings in the partition screen (including bootloader).

**note** at this point, I could use my BIOS menu to boot either Ubuntu or Qubes 
if I wanted, so I could have stopped.

4. I went back to the Ubuntu USB key and ran Boot-Repair 
(https://help.ubuntu.com/community/Boot-Repair) to add entries for Qubes to 
grub.
5. I changed the default boot device in my BIOS back to Ubuntu's boot partition.

The result was that Ubuntu's grub menu is the default, and it includes entries 
for Qubes that work as expected.

-- 
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/29f628c2-fadd-4ac0-ab93-1cf4ca874914%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] off topic - invite codes to 'riseup'

[magicmoon45869]

How are u supposed to get these codes?
No contacts via riseup yet. 

-- 
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/1fd9606e-4ee4-4bfa-a88d-82c7aa52a980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: off topic - invite codes to 'riseup'

[magicmoon45869]

I need 2 invite codes to get rise up email. Please share if you know how I 
could get these?? 
Email me at magicmoon45...@gmail.com
Thanks, Moon

-- 
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/a1da0868-c074-40d9-bc9a-155e0c2e8f2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: BIOS Security Settings?

[Nicklaus McClendon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/18/2016 01:26 PM, Grzesiek Chodzicki wrote:
> W dniu niedziela, 18 grudnia 2016 17:15:59 UTC+1 użytkownik 
> '0194358'019438'0194328'01943 napisał:
>> Hello,
>> 
>> does a BIOS password (against BIOS changes), gives a higher 
>> system security, or it is more like a security fake and could be 
>> easily bypassed?
>> 
>> Should I switch the IME off?
>> 
>> Kind Regards
> 
> Usually, the BIOS password can be reset by using a jumper on the 
> motherboard, a dedicated button, or by removing the CMOS battery
> so it's trivial to bypass. However if one day you notice that the 
> password is gone or that it has changed, that's a good indicator 
> that somebody accessed your pc.
> 
In Lenovo Thinkpads (mentioning as they tend to be popular for Qubes)
however, the supervisor BIOS password is stored in an EEPROM chip and
cannot be bypassed without digital analysis of the chip itself. So,
more secure against a standard attacker, but by no means secure
against a dedicated one.

- -- 
kulinacs 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAlhW4x4ACgkQuXLc0JPg
MlYAeRAApBziRvsaUCGsWbUetc8Z0wEAHhoQrOYU9GdO5/FyRU0QtALMDBcjv/6z
sYc5udhPn9lJoR9Ak65e+BRcR0zjWZ/jrkhan1GSvBV1B+Wma0jUyrLeVImq/gDj
Bn3ZxPsDCWhX5kClAFAa1f+ckUgY8s+ksgpHC4aui/FcJGGBUO7P1KpC3US4MO8+
pBj2E0Aw5pcUqiqfk7MoKpaaGh16IzOyhm5EWkT2xOFTayQJPuMUec1F92N/8ikU
SrVeC0VCCeIDD3DHoeGHa+4fu1+nurmGbwgICwWHRGHqqtdCG+IalUhEMsSF2oa0
oV5IbpvtdevnrE6JSv1AmLMe5w4tUDRryP6MUsd8BQHUwTfxDI9Lxbd9ip1oS2Uh
fog2n7mxgkGqKfx5yY/kAiVWPYBoYp2gNy4K6XzYX0j7eZlHM36K5hQSH0C+FSu1
i/3OonmeBZ3PfOiF+GRw7tT6jq4lLxC0P2fkueiruHDX6hUjGs+qbhQbsjQWtufY
KtPbmo/vR7QWvne4rs2Vcz1b5qgpO4c69MD68Fy0ks+xsbAhZ/WeARfCPGpqHhFR
CMwvEzkWsf/nYnj0+AetiIkJB9dbCUdPeSiwxy1Q5tzgkQii5daRbY15v8igH73l
96fl7Mp96ERzMDEhC7fq2D1K0A7a3YEzQx7e+GiYhIezysy44/g=
=jsc7
-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/888f56ef-2aad-5a6d-dae5-08127cd83d80%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: BIOS Security Settings?

[Grzesiek Chodzicki]

W dniu niedziela, 18 grudnia 2016 17:15:59 UTC+1 użytkownik 
'0194358'019438'0194328'01943 napisał:
> Hello,
> 
> does a BIOS password (against BIOS changes), gives a higher system security, 
> or it is more like a security fake and could be easily bypassed?
> 
> Should I switch the IME off?
> 
> Kind Regards

Usually, the BIOS password can be reset by using a jumper on the motherboard, a 
dedicated button, or by removing the CMOS battery so it's trivial to bypass. 
However if one day you notice that the password is gone or that it has changed, 
that's a good indicator that somebody accessed your pc.

-- 
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/018afa23-1ba1-4909-bb59-931fff67916a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: SUCCESS: GPU passthrough on Qubes 3.1 (Xen 4.6.1) / Radeon 6950 / Win 7 & Win 8.1 (TUTORIAL + HCL)

[celaaerab]

Le mercredi 22 juin 2016 11:26:50 UTC-4, Marcus at WetwareLabs a écrit :
> Hello all,
> 
> I've been tinkering with GPU passthrough these couple of weeks and I thought 
> I should now share some of my findings. It's not so much unlike the earlier 
> report on GPU passthrough here 
> (https://groups.google.com/forum/#!searchin/qubes-users/passthrough/qubes-users/cmPRMOkxkdA/gIV68O0-CQAJ).
> 
> I started with Nvidia GTX 980, but I had no luck with ANY of the Xen 
> hypervisors or Qubes versions. Please see my other thread for more 
> information 
> (https://groups.google.com/forum/#!searchin/qubes-users/passthrough/qubes-users/PuZLWxhTgM0/pWe7LXI-AgAJ).
> 
> However after I switched to Radeon 6950, I've had success with all the Xen 
> versions. So I guess it's a thing with Nvidia driver initialization. On a 
> side note, someone should really test this with Nvidia Quadros that are 
> officially supported to be used in VMs. (And of course, there are the hacks 
> to convert older Geforces to Quadros..)
> 
> Anyway, here's a quick and most likely incomplete list (for most users) for 
> getting GPU passthrough working on Win 8.1 VM. (works identically on Win7)
> 
> Enclosed are the VM configuration file and HCL file for information about my 
> hardware setup (feel free to add this to HW compatibility list!)
> 
> TUTORIAL
> 
> Check which PCI addresses correspond to your GPU (and optionally, USB host) 
> with lspci.Here's mine:
> ...
> 
> 
> # lspci
> 
> 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> Cayman XT [Radeon HD 6970]
> 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles 
> HDMI Audio [Radeon HD 6900 Series]
> Note that you have to pass both of these devices if you have similar GPU with 
> dual functionality.
> 
> Edit /etc/default/grub and add following options (change the pci address if 
> needed):
> 
> GRUB_CMDLINE_LINUX=" rd.qubes.hide_pci=03:00.0,03:00.1 
> modprobe=xen-pciback.passthrough=1 xen-pciback.permissive"
> GRUB_CMDLINE_XEN_DEFAULT="... dom0_mem=min:1024M dom0_mem=max:4096M"
> 
> For extra logging:
> 
> 
> GRUB_CMDLINE_XEN_DEFAULT="... apic_verbosity=debug loglvl=all 
> guest_loglvl=all iommu=verbose"
> 
> There are many other options available, but I didn't see any difference in 
> success rate. See here:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
> http://wiki.xenproject.org/wiki/Xen_PCI_Passthrough
> http://wiki.xenproject.org/wiki/XenVGAPassthrough
> 
> Update grub:
> 
> # grub2-mkconfig -o /boot/grub2/grub.cfg
> Reboot. Check that VT-t is enabled:
> 
> # xl dmesg
> ...
> (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
> (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables enabled.
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> Check that pci devices are available to be passed:
> 
> # xl pci-assignable list
> :03:00.0
> :03:00.1
> Create disk images:
> 
> # dd if=/dev/zero of=win8.img bs=1M count=3
> # dd if=/dev/zero of=win8-user.img bs=1M count=3
> Install VNC server into Dom0
> 
> # qubes-dom0-update vnc
> Modify the win8.hvm: Check that the disk images and Windows installation 
> CDROM image are correct, and that the IP address does not conflict with any 
> other VM (I haven't figured out yet how to set up dhcp) Check that 'pci = [ 
>  ]' is commented for nowStart the VM ( -V option runs automatically VNC 
> client)
> 
> # xl create win8.hvm -V
> 
> If you happen to close the client (but VM is still running), start it again 
> with
> 
> 
> # xl vncviewer win8
> Note that I had success starting the VM only as root. Also killing the VM 
> with 'xl destroy win8' would leave the qemu process lingering if not done as 
> root (if that occurs, you have to kill that process manually)
> Install WindowsPartition the user image using 'Disk Manager'Download signed 
> paravirtualized drivers here (Qubes PV drivers work only in Win 
> 7):http://apt.univention.de/download/addons/gplpv-drivers/gplpv_Vista2008x64_signed_0.11.0.373.msi
> Don't mind the name, it works on Win 8.1 as well.
> For more info: 
> http://wiki.univention.com/index.php?title=Installing-signed-GPLPV-drivers
> 
> Move the drivers inside user image partition (shut down VM first):
> 
> # losetup   (Check for free loop device)
> # losetup -P /dev/loop10 win8-user.img   (Setup loop device and scan 
> partition. Assuming loop10 is free)
> # mount /dev/loop10p1 /mnt/removable  ( Mount the first partition )- copy the 
> driver there and unmount.
> 
> Reboot VM, install paravirtual drivers and reboot againCreate this script 
> inside sys-firewall (check that the sys-net vm ip address 10.137.1.1 is 
> correct though):
> 
> fwcfg.sh:
> #!/bin/bash
>    vmip=$1
> 

[qubes-users] Re: VmCL for Coldkernel Debian 8 Qubes R3.2

[Reg Tiangha]

On 2016-12-17 2:59 PM, podmo wrote:
> Reporting success with Coldkernel on Qubes R3.2 with Debian 8 template.
> Followed the steps in
> https://coldhak.ca/blog/2016/12/12/coldkernel-qubes-1.html and worked
> first try. I did some further tweaking afterwards to allow me to lock it
> down a bit more in the future with TPE and keep my template minimal.
> 
> In the linux-4.8.13 directory structure:
> Copied u2mfn.c to drivers/misc and set up references in Kconfig and Makefile
> make menuconfig
> 
> GRKERNSEC_TPE_ALL=y   [kernel.grsecurity.tpe_restrict_all]
> GRKERNSEC_TPE_INVERT=y[kernel.grsecurity.tpe_invert]
> PAX_MEMORY_SANITIZE=y [not sure if Xen sanitizes freed memory within 
> the
> VM, appears to only be on shutdown]
> PAX_MEMORY_STACKLEAK=y
> CONFIG_XEN_BLKDEV_BACKEND=m   [believe this is necessary for the USB VM,
> crashed Qubes Manager on attaching USB device to other VM without it]
> CONFIG_XEN_NETDEV_BACKEND=m   [and this for Net VM]
> CONFIG_U2MFN=y[to let me avoid DKMS]
> 
> fakeroot make bindeb-pkg -j 4 LOCALVERSION=-coldkernel-grsec-1
> KDEB_PKGVERSION=4.8.13-coldkernel-grsec-1
> 
> Then, copied the following to minimal template:
> linux-image-4.8.13-coldkernel-grsec-amd64.deb
> paxctld_1.2.1-1_amd64.deb
> paxctld.conf
> /usr/share/initramfs-tools/hooks/qubes_vm
> /usr/share/initramfs-tools/scripts/local-top/qubes_cow_setup
> 
> Added the following file on minimal:
> /etc/sysctl.d/81-grsec.conf
>   kernel.grsecurity.deny_new_usb = 0
>   kernel.grsecurity.tpe_invert = 1
>   kernel.grsecurity.tpe_restrict_all = 1
> 
> And ran on it:
> 
> sudo dpkg -i paxctld_1.2.1-1_amd64.deb [or use one from testing repository]
> sudo apt install grub2-common
> 
> sudo groupadd -g 9001 grsecproc
> sudo groupadd -g 9002 tpeuntrusted
> sudo groupadd -g 9003 denysockets
> sudo cp paxctld.conf /etc/paxctld.conf
> sudo paxctld -d
> sudo systemctl enable paxctld
> sudo dpkg -i linux-image-4.8.13-coldkernel-grsec-amd64.deb
> sudo mkdir /boot/grub
> sudo update-grub2
> 
> sudo shutdown -h now
> 
> Changed it to use PVGRUB2 and minimal template worked too. Applied it to
> sys-net, sys-firewall, sys-usb and all function (after adding some
> packages I missed, etc.) except with two issues so far:
> 1. qvm-copy-to-vm completes successfully but throws an error to the
> console at the end about failed to open /proc: permission denied.
> 2. On full reboot, all sys-VMs start automatically but networking doesn't
> work right until I shut down whonix and firewall, then start them back up
> in the proper order. Not sure if it's because they are just booting too
> fast or if some trigger isn't getting communicated properly.
> 
> 

Thanks! I guess those missing Xen modules were what was needed for proxy
and netVMs to work. Haven't tested sys-usb yet, but I got that same
problem you had where Qubes Manager would crash when attaching devices
so if you say it's now fixed, I'll believe it.

I managed to get dispVMs to work as well, but I had to trick Qubes
Manager to do it. For whatever reason, when you run
qvm-create-default-dvm, it'll take whatever kernel is set to default
under Global Settings and apply it to future dispVMs. So if you have it
set to use a normal kernel, it'll always use a normal kernel for
dispVMs; changing the kernel on the template or the generated dvm
template has no effect. So if you set the default kernel to PVGRUB2 in
Global Settings before running qvm-create-default-dvm, that'll allow
future dispVMs to boot with the coldkernel (just make sure to switch it
back when you're done so your other VMs will boot normally).

Also, from the Gentoo Grsecurity handbook, some other sysctl options
people might want to play with:

Secure chroot:
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_shmat = 1
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_findtask = 1

According to the Arch wiki, these settings may have problems with
containers, but if you don't use them in your vm, then you might as well
set them:
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_restrict_nice = 1

Lock Settings to prevent them from being changed (only activate when
you're sure you've got everything set up the way you want to):
kernel.grsecurity.grsec_lock = 1

-- 
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 

Re: [qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Dec 18, 2016 at 04:34:39PM +, Doug Hill wrote:
> 
> 
> Colin Childs:
> > Hi everyone,
> > 
> > Sorry for not getting on this list sooner, however it looks like testing
> > of coldkernel on Debian is largely going well! I see the most recent
> > issue from foppe, and will be attempting to reproduce later this evening.
> > 
> > If you run into issues that require coldhak attention, please do not
> > hesitate to open tickets at
> > https://github.com/coldhakca/coldkernel/issues, or email us directly at
> > cont...@coldhak.ca.
> > 
> > Thanks, and happy testing!
> > 
> 
> Hi,
> 
> Running into a problem when runnning "make qubes-guest" on a stock
> debian-8 template.
> 
> Below are the last few lines of the output. Thanks!
> 
>   CC [M]  fs/xfs/xfs_buf_item.o
>   CC [M]  fs/xfs/xfs_extfree_item.o
>   CC [M]  fs/xfs/xfs_icreate_item.o
>   CC [M]  fs/xfs/xfs_inode_item.o
>   CC [M]  fs/xfs/xfs_rmap_item.o
>   CC [M]  fs/xfs/xfs_log_recover.o
>   CC [M]  fs/xfs/xfs_trans_ail.o
>   CC [M]  fs/xfs/xfs_trans_buf.o
>   CC [M]  fs/xfs/xfs_trans_extfree.o
>   CC [M]  fs/xfs/xfs_trans_inode.o
>   CC [M]  fs/xfs/xfs_trans_rmap.o
>   CC [M]  fs/xfs/xfs_sysctl.o
>   CC [M]  fs/xfs/xfs_ioctl32.o
>   LD [M]  fs/xfs/xfs.o
>   LD  fs/built-in.o
> scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed
> make[2]: *** [bindeb-pkg] Error 2
> Makefile:1317: recipe for target 'bindeb-pkg' failed
> make[1]: *** [bindeb-pkg] Error 2
> make[1]: Leaving directory '/home/user/coldkernel/linux-4.8.13'
> Makefile:61: recipe for target 'qubes-guest' failed
> make: *** [qubes-guest] Error 2
> user@debian-8-coldkernel:~/coldkernel$

Relevant error is probably earlier. I guess it's about disk space - it
require 4GB or so to build.

- -- 
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

iQEcBAEBCAAGBQJYVrvMAAoJENuP0xzK19csBjYH/jajqTdkc7/eedgVVFCqT4sg
OdIkQkcJgGv2tEwMnPmMcA/U8CMc7sRN51UV/hr9b0IM2VhZy21oPgtXpf6hXdGD
1Z4ZEtl6Jo12UM07jAbKbOGGnJJMcU5Sy+PalbI2/365zefX7ALkzlOQpMA6y0Zv
e2y7zBIn5SDIusLkBah2juhv4SGVFVSvmUZ+xgmScun2qHfa2YDbLv6oS/aUAOa5
cijINdbB2flz9mIMqhaIuOty0330LbMbKJ0vWXni/TUgEY2ZCWyUN0XO2TcU8I9X
TStuyGfuE3sah2/CpO9Kx7QNNvCzVzTpfy2u/YKVEP0Mbjrudw7op6y2YqewVM8=
=UsAL
-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/20161218163939.GX1239%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Doug Hill]

Colin Childs:
> Hi everyone,
> 
> Sorry for not getting on this list sooner, however it looks like testing
> of coldkernel on Debian is largely going well! I see the most recent
> issue from foppe, and will be attempting to reproduce later this evening.
> 
> If you run into issues that require coldhak attention, please do not
> hesitate to open tickets at
> https://github.com/coldhakca/coldkernel/issues, or email us directly at
> cont...@coldhak.ca.
> 
> Thanks, and happy testing!
> 

Hi,

Running into a problem when runnning "make qubes-guest" on a stock
debian-8 template.

Below are the last few lines of the output. Thanks!

  CC [M]  fs/xfs/xfs_buf_item.o
  CC [M]  fs/xfs/xfs_extfree_item.o
  CC [M]  fs/xfs/xfs_icreate_item.o
  CC [M]  fs/xfs/xfs_inode_item.o
  CC [M]  fs/xfs/xfs_rmap_item.o
  CC [M]  fs/xfs/xfs_log_recover.o
  CC [M]  fs/xfs/xfs_trans_ail.o
  CC [M]  fs/xfs/xfs_trans_buf.o
  CC [M]  fs/xfs/xfs_trans_extfree.o
  CC [M]  fs/xfs/xfs_trans_inode.o
  CC [M]  fs/xfs/xfs_trans_rmap.o
  CC [M]  fs/xfs/xfs_sysctl.o
  CC [M]  fs/xfs/xfs_ioctl32.o
  LD [M]  fs/xfs/xfs.o
  LD  fs/built-in.o
scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed
make[2]: *** [bindeb-pkg] Error 2
Makefile:1317: recipe for target 'bindeb-pkg' failed
make[1]: *** [bindeb-pkg] Error 2
make[1]: Leaving directory '/home/user/coldkernel/linux-4.8.13'
Makefile:61: recipe for target 'qubes-guest' failed
make: *** [qubes-guest] Error 2
user@debian-8-coldkernel:~/coldkernel$

-- 
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/dec89517-4cbf-91af-b3a5-7414918e77c7%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Installing with new kernel?

[Baguette]

Hello,

I posted a message ten days ago to this list[0] because I am unable to
install, because X just completely fails so the installer doesn't
properly come up.

It seems like there are people who are running newer kernels, but they
install them after they've installed Qubes. Is it possible to bootstrap
the installation with that newer kernel, so I can actually get things
installed? If so, how would I go about doing that?

thanks, I'd really like to get this installed!


0. https://groups.google.com/forum/#!topic/qubes-users/cZwXouFsrU8

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

[qubes-users] BIOS Security Settings?

['0194358'019438'0194328'01943]

Hello,

does a BIOS password (against BIOS changes), gives a higher system security, or 
it is more like a security fake and could be easily bypassed?

Should I switch the IME off?

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/3a95417b-d046-462a-a288-6b22007d6947%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] building ubuntu14 template

[jd87]

 git revert da5ee8fb0Quoting Unman :


On Sat, Dec 17, 2016 at 01:09:38PM -0600, j...@vfemail.net wrote:

hi.
i am trying to build an ubuntu14 template:

From the doc: 'Ubuntu 14.4 LTS (Trusty) can be built with little

effort.'

So i assume it should work.

When executing `make qubes-vm` i get following error:

Ign http://ppa.launchpad.net trusty/main Translation-en
Reading package lists...
# Parse debian/control for Build-Depends and install
/home/user/qubes-builder/qubes-src/builder-debian//scripts/debian-parser
control --build-depends


/home/user/qubes-builder/chroot-trusty//home/user/qubes-src/vmm-xen/debian-vm/debian/control

|\
    xargs sudo chroot /home/user/qubes-builder/chroot-trusty

apt-get 

install -y
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libsystemd-dev
E: Unable to locate package libsystemd-dev
/home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:167:
recipe for target 'dist-build-dep' failed
make[2]: *** [dist-build-dep] Error 123
Makefile.generic:139: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
Makefile:209: recipe for target 'vmm-xen-vm' failed
make: *** [vmm-xen-vm] Error 1

what can i do to fix this?

-joe
 


The error is in building vmm-xen.
I see there was a patch back in July that added libsystemd-dev under
Build-Depends. Clearly this isn't going to work under Trusty as that
package isn't available.
You could try removing those lines from debian/control and seeing if
vmm-xen-vm builds. I'm pretty sure it wont, but don't have time to test
that.
I'll have a look shortly to get Trusty working again.

It isn't yet in the docs but you could also try a 16.4 build. Feedback
would be useful.
unman


i can build ubuntu16, but need 14, since this sadly is the target platform
in one of the projects i am working in.
currently i use an ubuntu14 hvm and ssh -X, but this is annoying.

Some time ago the doc contained something about problems when building
ubuntu 14, but this section was removed.
Hence i assumed this problem was fixed.

i tried removing libsystemd.
i removed the lines :
 * qubes-src/vmm-xen/debian-vm/debian/control:28:    libsystemd-dev,
 * qubes-src/vmm-xen/debian-vm/debian/control:29:   
libsystemd-dev:amd64,

and executed:
 * make clean
 * make qubes-vm

this failed, since some commands used "--enable-systemd
--with-systemd=/lib/systemd/system".

then i tried reverting the commit:
 * git revert da5ee8fb0
and did some merging (mostly i had to guess, since i don't know what)
when building i got a different error:

-> Building core-qubesdb (debian) for trusty vm (logfile:
build-logs/core-qubesdb-vm-trusty.log)
--> build failed!
Perhaps you should add the directory containing `libsystemd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsystemd' found
Package libsystemd-daemon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsystemd-daemon.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsystemd-daemon' found
cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -I../include -I. -g -Wall -Werror -pie -fPIC -O2
`pkg-config --cflags libsystemd || pkg-config --cflags libsystemd-daemon`
`pkg-config --cflags vchan-xen` -DBACKEND_VMM_xen   -c -o db-daemon.o
db-daemon.c
Package libsystemd was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsystemd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsystemd' found
Package libsystemd-daemon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsystemd-daemon.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsystemd-daemon' found
db-daemon.c:32:31: fatal error: systemd/sd-daemon.h: No such file or
directory
 #include 
   ^
compilation terminated.
make[3]: *** [db-daemon.o] Error 1
make[3]: Leaving directory `/home/user/qubes-src/core-qubesdb/daemon'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/user/qubes-src/core-qubesdb'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/home/user/qubes-src/core-qubesdb'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
/home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:192:
recipe for target 'dist-package' failed
make[2]: *** [dist-package] Error 2
Makefile.generic:139: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
Makefile:209: recipe for target 'core-qubesdb-vm' failed
make: *** [core-qubesdb-vm] Error 1

i guess i did forget some stuff, or other commits also use systemd (i guess
this will be the case for some of the 31 commits)

when looking at the old issues from the ml (
https://groups.google.com/d/msg/qubes-users/w0uZNr8nno8/n1fe6dLtBQAJ ):
Achim Patzner wrote:

I tried that last Sunday but it 

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Swâmi Petaramesh]

Le 17/12/2016 à 18:55, Hello Mister a écrit :
> Luks error started way before I even thought of reinstallation attempt.

So I'm very afraid that you definitely lost your data.


ॐ

-- 
Swâmi Petaramesh  PGP 9076E32E

-- 
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/cd9a340d-e56a-0799-0d86-3480090ede27%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Windows 7 HVM & Windows update

[Swâmi Petaramesh]

Le 17/12/2016 à 19:11, entr0py a écrit :
> Fixed! (for now)
> 
> https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-solution/f39a65fa-9d10-42e7-9bc0-7f5096b36d0c
> 
> Windows downloads full list of needed upgrades in minutes. Only one (or two) 
> patches needed.

Hi Entropy,

I could finally get the Windows to update by manually applying most of
the patches mentionned there (at least 4).

Thanks for your help.

ॐ

-- 
Swâmi Petaramesh  PGP 9076E32E

-- 
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/711b22fb-fcc8-867d-f59b-9aa83ba4ff8d%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.