Re: [qubes-users] Mac-Spoofing Doesn’t Work

[Chris Laprise]

On 10/02/2017 11:08 PM, Person wrote:

I followed the directions for enabling mac-spoofing on Qubes, and it didn’t 
work. https://www.qubes-os.org/doc/anonymizing-your-mac-address/

I think I may have done something wrong. I could have not saved the gedit file 
correctly, or I spelled wlpos1 wrong. Or perhaps I didn’t restart sys-net 
enough times.



The doc has two different methods: Network Manager and macchanger. If 
using the first (recommended) you wouldn't need to configure 'wlpos1' 
directly, and it should work as long as your Wifi card has proper 
support for address changes.



--

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

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

Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

[Ron Hunter-Duvar]

On 10/02/2017 08:34 PM, joevio...@gmail.com wrote:

On Saturday, 5 August 2017 11:20:27 UTC-4, the2nd  wrote:

Hi,

i switched to Qubes OS 3.2 on my notebook some weeks ago. Besides some issues i 
had it works very well.

One problem was to get the installer to install qubes on LVM-on-LUKS. I 
preferred this over the default LUKS-on-LVM setup because you dont have to 
encrypt any LV separately.
...
Please note that the current version will probably not work with a default 
qubes LUKS-on-LVM installation. But if some experienced user is willing to help 
testing i'll try to come up with a version that supports this too.

Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
yubikey is connected via USB and needs to be accessable until we got the 
challenge from it. i am still unsure if this is the best method to implement 
this. So if anyone with a deeper knowledge of qubes/dracut does have a 
better/more secure solution i happy about any help.

Regards
the2nd

This is working great for me.
A few questions though:

1)  The default Qubes 3.2 install seems to be LVM-on-LUKS where there is only 
one LUKS encryption and root/swap LVMs within that.  So your instructions work 
with the default install.

...
I'd have to say that the2nd is right. I didn't notice on my first Qubes 
3.2 install, because I only had one encrypted partition on my OS drive 
(skipped a swap partition, despite the installer's whining). Second time 
around I gave in and created one.


lsblk shows sda2 with a luks-encrypted / within it, and sda3 with a 
luks-encrypted swap. If it were LVM-on-LUKS, it would be a single 
luks-encrypted partition two logical volumes within it.


Ron

PS: I'm a Qubes-noob, but long-time Linux user.

--
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/814cee70-0b5c-12a4-ee3e-bdb1f5479f3e%40shaw.ca.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Mac-Spoofing Doesn’t Work

[Person]

I followed the directions for enabling mac-spoofing on Qubes, and it didn’t 
work. https://www.qubes-os.org/doc/anonymizing-your-mac-address/  

I think I may have done something wrong. I could have not saved the gedit file 
correctly, or I spelled wlpos1 wrong. Or perhaps I didn’t restart sys-net 
enough times.

-- 
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/83056a06-fd0d-420e-857b-4bf6792cafed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

[joeviocoe]

On Saturday, 5 August 2017 11:20:27 UTC-4, the2nd  wrote:
> Hi,
> 
> i switched to Qubes OS 3.2 on my notebook some weeks ago. Besides some issues 
> i had it works very well.
> 
> One problem was to get the installer to install qubes on LVM-on-LUKS. I 
> preferred this over the default LUKS-on-LVM setup because you dont have to 
> encrypt any LV separately.
> 
> After fiddling around some other issues i wanted to use my yubikey to unlock 
> the luks partition on boot like i did it before with my ubuntu installation 
> (https://github.com/cornelinux/yubikey-luks).
> 
> After trying this:
> https://github.com/bpereto/ykfde/blob/master/README-dracut.md
> 
> Which did not work and besides this does manage some IMHO useless (someone 
> may correct me if i am wrong) extra challenges within the initramfs.
> 
> And reading this:
> https://groups.google.com/forum/#!searchin/qubes-users/yubikey$20luks%7Csort:relevance/qubes-users/7pIS_grFZ4s/AlCoPuf-BwAJ
> 
> and this:
> https://github.com/QubesOS/qubes-issues/issues/2712
> 
> I came to the conclusion that there is no working solution yet. So i tried to 
> write my own dracut module. The main problem with this was to find the best 
> hook in the boot process to send the user password to the yubikey and unlock 
> the luks partition. After some testing i got a version which works for my 
> purposes.
> 
> You can find the module and some install instructions at: 
> https://github.com/the2nd/ykluks
> 
> Please note that the current version will probably not work with a default 
> qubes LUKS-on-LVM installation. But if some experienced user is willing to 
> help testing i'll try to come up with a version that supports this too.
> 
> Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
> stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
> yubikey is connected via USB and needs to be accessable until we got the 
> challenge from it. i am still unsure if this is the best method to implement 
> this. So if anyone with a deeper knowledge of qubes/dracut does have a 
> better/more secure solution i happy about any help.
> 
> Regards
> the2nd

This is working great for me.
A few questions though:

1)  The default Qubes 3.2 install seems to be LVM-on-LUKS where there is only 
one LUKS encryption and root/swap LVMs within that.  So your instructions work 
with the default install.

2)  It is not clear what can be done if you forget your Yubikey one day and 
want to use the really strong LUKS passphrase from another slot.
Is "Something went wrong" section in which you specify an older initramfs, the 
only way?  Do I need to periodically update this backup "org" initramfs?  And 
it doesn't mention anything about uncommentting the commented crypttab entry 
from the install instructions?

3)  It does seem to hang after timing out.  It will accept the password, but 
will not continue booting.  I can't turn the system on, and come back later to 
use the yubikey.  It seems like it is set to timeout in a minute or so.


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/7f87fd91-f884-4f8e-ba4a-03cf8e447d57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Error Creating Ubuntu VM in Qubes 3.2

[Person]

Apparently the brackets were one of my mistakes. My bad (and thank you for 
pointing that out).

I ran the copy-to-dom0 and attach-to-VM commands again, and dom0 didn’t 
respond. So I opened the Standalone VM and it didn’t register anything to boot 
from, even though I’m sure that I copied the ISO successfully to dom0. When I 
open the dom0 File System, from the Stanalone VM Boot Screen, I can’t find the 
ISO that I copied there.

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

Re: [qubes-users] Error Creating Ubuntu VM in Qubes 3.2

[Unman]

On Sun, Oct 01, 2017 at 09:41:03PM -0600, Ron Hunter-Duvar wrote:
> On 10/01/2017 06:59 PM, Person wrote:
> > The file was in Home/User/Downloads, and I did make sure to include the 
> > command. Also, the Ubuntu file did end in “.iso”.
> > 
> > I did run qvm-start in dom0. I believe I typed “qvm-start  
> > --cdrom=sys-net:/home/user/Downloads/”, or I 
> > did the same thing but replaced “Ubuntu” with “hvm”. (“Ubuntu” is the name 
> > of the standalone VM I made and wanted to attach the .iso to.)
> > 
> > As for the qvm-run error, I have no idea if I entered the location 
> > correctly or not. I typed “qvm-run --pass-io  'cat 
> > /home/user/Downloads/' > 
> > ubuntu-17.04-server-amd64.iso”.
> > 
> > I did copy the template to dom0, but I could not find it in dom0 (when I 
> > open the dom0 Boot Screen where stand-alone VMs look for things to boot 
> > from, I cannot find the template file there) and so was unable to install 
> > it in dom0. I did install Xenial in sys-net, but I couldn’t find the 
> > template when I looked at my list of VMs, even when I use the methods you 
> > listed.
> > 
> > I believe my main problem is copying the files to dom0 in general, because 
> > that is the only way I can make these files into VMs.
> > 
> You didn't actually type the angle brackets <> around the vm and file names,
> did you? If so, that would probably be your problem.
> 
> Ron
> 

Ron's right - the use of angle brackets is a convention to show that a
parameter is to be substituted by an actual value. You also see
underscores used: _qube name_

Dont type them._

Similarly you will see optional arguments in square brackets: like this-
qvm-start [options] 

The options are, well, optional - and you type a VALUE for the vmname:
qvm-start Ubuntu

I hope that's clear - if it is you *should* be able to finally get the
Ubuntu iso copied into dom0.

Finally, you really need to look again at the Qubes documentation. You
install Templates in dom0. So you will need to copy the Template you
downloaded to dom0 and then install it there. If you do that you WILL see
a template available which will allow you to create xenial qubes.

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

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[Person]

I looked at Arm again. It seems that Arm is working, but I don’t know the 
commands to edit the Tor configuration.

Arm mentions a list of problems relating to Tor (http://imgur.com/XrJHKSK). It 
seems that I have relaying disabled, torrc differs from what Tor is using, 
there is insufficient uptime, Tor is preventing utilities like netstat and lsof 
from working, and no armrc is working. Unfortunately, I can’t figure out how to 
solve these problems.

This is the link I found in the bottom of the Arm report: 
https://trac.torproject.org/projects/tor/ticket/3313. I’m not too sure what it 
means.

-- 
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/3edabd63-f513-4262-8784-a8a2f7ccbb31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[Person]

I have successfully changed the NetVM for the Whonix templates, luckily.

To explain what I said eariler, I changed the NetVM of whonix-gw to 
anon-whonix, so that the  “Whonix has no UpdateVM” (I think they mean that the 
whonix-gw template does not use a NetVM with a whonix template) and the Tor 
Control Port errors are gone. However, a Tor Bootstrap problem appears: 
http://imgur.com/1Gut4Tz. This seems to mean that a Tor connection was not 
established.

The three reasons the error message gives me are that my internet is not 
working, Tor is censored in my area, or that my Arm (Tor Controller) 
configuration is off somehow.
The first two reasons do not apply to me because my internet is working, and 
Tor is not censored in my area. So I opened Arm (Tor Controller) to edit the 
configuration of Tor, but Arm was lagging and I couldn’t change anything.

-- 
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/7f377535-d0aa-4e02-88dc-54f47867158f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL — ASUS Q325UA

[Chris Laprise]

On 08/01/2017 09:49 PM, Tao Effect wrote:

Ran into all of the same issues that Mike Freemon experienced:

- 
https://groups.google.com/forum/#!searchin/qubes-users/display$20resolution|sort:relevance/qubes-users/BUe4tFfERtA/buazJHIzCQAJ 

- 
https://groups.google.com/forum/#!msg/qubes-users/Eq2zZU5yXEs/qs94AX1uAAAJ 



But, while attempting to follow Mike's recommendations, I ran into 
additional obstacles as described here:


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

Ultimately I was able to get the laptop working.

HVM: Yes
IOMMU: Yes
SLAT: Yes
TPM: `qubes-hcl-report` says 'unknown`, but I think I remember reading 
somewhere that it does?

Qubes: R3.2
Kernel: Supports the one in unstable (4.8.12-12), and in fact requires 
it for proper screen resolution support

Remark: What I wrote above, including all relevant links




Hi Tao,

Could you post the report's yml file? Thanks...

--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/474193ab-79ff-77ff-5a64-6eeb448dd344%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL Dell Latitude 7480 + dock usb-c problems (dell wd15)

[Chris Laprise]

On 08/20/2017 11:31 AM, cyrinux wrote:

It is a dock in thunderbolt*



Hi cyrinux,

If you'd like this computer to be listed on the HCL page, could you 
attach a yml file from the qubes-hcl-report script?


--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/69cebfb2-21d3-0d05-d273-3b06ff8cb0f8%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?

[Unman]

On Mon, Oct 02, 2017 at 02:18:00PM +, Patrick Schleizer wrote:
> Yethal:
> > W dniu środa, 27 września 2017 14:08:56 UTC+2 użytkownik Patrick Schleizer 
> > napisał:
> >> cooloutac:
> >>> On Sunday, September 24, 2017 at 12:23:39 PM UTC-4, cooloutac wrote:
>  On Sunday, September 24, 2017 at 12:23:23 PM UTC-4, cooloutac wrote:
> > On Sunday, September 24, 2017 at 9:25:24 AM UTC-4, Patrick Schleizer 
> > wrote:
> >> Quote from https://www.qubes-os.org/doc/usb/
> >>
> >>> Caution: By assigning a USB controller to a USB qube, it will no
> >> longer be available to dom0. This can make your system unusable if, for
> >> example, you have only one USB controller, and you are running Qubes 
> >> off
> >> of a USB drive.
> >>
> >> How can one recover from such a situation if there is no PS2
> >> keyboard/mice available?
> >>
> >> I guess... Unless there is a better way...? Boot the system using from
> >> an external disk using a USB recovery operating system... Then modify
> >> the local disk (with broken Qubes)... Then do what?
> >>
> >> Cheers,
> >> Patrick
> >
> > ya that. exactly.
> 
>  that would be the only way I would know of.
> >>>
> >>> sorry i misunderstood.  you could use the qubes keyboard proxy.  or 
> >>> unhide it from dom0.  think they are both explained in the docs there, 
> >>> but don't think either are recommended but if you have no choice.
> >>>
> >>
> >> The Qubes documentation explains how to hide/unhide it with the gui. But
> >> when the disk is not booted (for recovery booted from USB), the gui
> >> cannot be used since it refers to the USB booted and not internal disk
> >> supposed to be recovered.
> >>
> >> To undo it some file on the internal disk needs to be modified. Which
> >> files needs what modification?
> > 
> > Remove rd.qubeshideallusb parameter from grub and then rebuild grub
> > 
> 
> That requires to chroot into the mounted disk system?
> 
> Isn't it difficult to run grub from a chrooted disk without messing up
> bootloader of the disk that was booted or messing up which devices grub
> is referring to?
> 
> > Remove rd.qubeshideallusb parameter from grub [...]
> 
> If that's all... Then why not just do this during normal system boot at
> grub?
> 
> Even if it's not hidden all the time from dom0... Won't the
> keyboard/mice USB controller be quickly assigned to sys-usb, detached
> from dom0 and still leave an unbootable system?
> 
> As I understand the documentation rd.qubeshideallusb is "only" for
> improved security. One can render its system unusable even without using
> rd.qubeshideallusb.
> 

You should be able to fix this in grub: something like this -
Interrupt the boot process and change the parameters to remove 
rd.qubeshideallusb, and add
rd.break=cleanup.
You'll be prompted to decrypt disks and then drop to shell.
The root filesystem will be mounted ro at /sysroot.
umount /sysroot.
Mount it rw somewhere else (e.g /mnt - you'll have to create that)
cd /mnt/var/lib/qubes/servicevms
mv sys-usb sys-usb.bak
umount /mnt

Remount /dev/mapper/blah on /sysroot
exit from the rescue shell

The system should then continue to boot - sys-usb wont be able to start
and so cant claim the usb devices - as you changed the boot parameters
they'll be available in dom0.

I don't currently have a USB keyboard with me so cant check this.
Let me know if it works. It should.

unman

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

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[Unman]

On Sun, Oct 01, 2017 at 06:35:03PM -0700, Person wrote:
> I changed the NetVM of whonix-gw from sys-net  to anon-whonix (so whonix-gw 
> finally has a NetVM that uses Whonix as its template) , and the Tor Control 
> Port problem no longer appears. However, a Tor Bootstrap problem appears: 
> http://imgur.com/1Gut4Tz. 
> 
> I don’t understand why this is happening. My internet connection is working 
> and Tor is not censored in my area. So I opened Arm, but it was lagging and I 
> couldn’t do anything on it.
> 

I don't use Whonix but I can almost guarantee that this is NOT what you
should be doing.
I'd suggest you might get more help over at the Whonix forums that here.
BUT I suspect that they might baulk at your suggestion that you are
"making some templates for myself." Do you really mean this?

I've lost track of what you have done and what you haven't, because you
rarely give enough information to understand what is happening, and
when you do it's quite confusing. I suspect this is because you are
confused yourself.

The one specific error that you mentioned "Cannot dynamically attach to
stopped NetVM" means exactly what it says: You are trying to change the
NetVM of whonix-ws while it is running, and the NetVM you choose is NOT
running. The solution is to start the NetVM you want to use.

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

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Foppe de Haan]

On Monday, October 2, 2017 at 11:35:37 AM UTC+2, Frédéric Pierret (fepitre) 
wrote:
> Le lundi 2 octobre 2017 02:36:48 UTC+2, Reg Tiangha a écrit :
> > On 2017-10-01 10:21 AM, Frédéric Pierret (fepitre) wrote:
> > 
> > > 
> > > Hi, just a small update of current kernel branches status:
> > > 
> > > From our last commits with Reg, the last version of kernel 4.12.14 is 
> > > available and also I created the branch for devel-4.13 (currently version 
> > > 4.13.4).
> > > 
> > > From my side, I had kernel panic in VM with latest version 4.12.14 when 
> > > merging all the options in CONFIG file from stable-4.9 due to 
> > > vlv2_plat_configure_clock related to CONFIG_INTEL_ATOMISP (see 
> > > https://github.com/fepitre/qubes-linux-kernel/commit/3edc1d714539aba669c6c710a09b8022ff8fcaa2).
> > >  This problem was known for several distros with Xen PV DomU (e.g. 
> > > https://bugs.archlinux.org/task/55447 and 
> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711298). So not 
> > > setting this driver solved my problem (even for kernel-4.13+).
> > > 
> > > Best,
> > > 
> > 
> > Perfect! I was trying to figure out why 4.13.4 was panicking when used
> > in a VM too (dom0 seemed to work fine) but didn't have enough time to
> > really dig deep into the kernel options and didn't actually try to boot
> > 4.12.14 either; I just assumed it worked (the last one I tried was
> > 4.12.13). I'm glad you figured it out! Hopefully, there won't be anymore
> > weirdness when 4.14 (the next LTS kernel) comes out.
> 
> I'm having also trouble with kernel 4.13.4 on dom0 only. It complains about 
> out of memory and kill all processes. I need to dig more into this but kernel 
> 4.12.14 works fine :)

It didn't kill processes here, but 4.13(.4) does result in general instability 
(becomes sluggish, then hangs, sometimes reboots), and does complain about 
being OOM on my PC as well. (Ryzen 5 1600, 32gb ram, works fine otherwise.)

-- 
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/afc3ac97-92dc-414f-a920-ca559f9df7f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: timeout on VMstart: cannot execute qrexec-daemon

[evo]

Am 02.10.2017 um 20:17 schrieb Ron Hunter-Duvar:
> On October 2, 2017 10:30:49 AM MDT, evo  wrote:
>>
>>
>> Am 01.10.2017 um 22:06 schrieb evo:
>>> Hello!
>>>
>>> i can not start one of the StandaloneVMs
>>> it just give me a timeout and "cannot execute qrexec-daemon"
>>>
>>> after reboot the same thing.
>>>
>>> logs show the following:
>>>
>>> guid.VM
>>> Icon size: 128x128
>>> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X
>> server
>>> ":0.0"
>>>
>>>   after 31000 requests (31000 known processed) with 0 events
>> remaining.
>>>
>>>
>>>
>>> can somebody help please?
>>>
>>
>>
>> please help somebody, i have my password-manager and other important
>> stuff there and just an older backup :-/
> 
> You might be able to recover the essential files by creating a new VM and 
> copying the private.img and volatile.img files from the old VM 
> (/var/log/qubes/appvms/) to the new one, then booting the new one. 
> This worked for me when I had to reinstall QubesOs.
> 
> As to the error itself, it seems to suggest a missing icon file somewhere. I 
> don't know why that would stop the VM from starting, but qrexec-daemon seems 
> to be rather brittle. No idea how you would fix it. Might require either 
> digging into the code or help from one of the developers to track down and 
> resolve.
> 
> Ron
> 

huh, thank you! the thing with the qrexec seems to be a little creepy...
i will try to restore the whole thing in a new VM

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

Re: [qubes-users] Re: timeout on VMstart: cannot execute qrexec-daemon

[Ron Hunter-Duvar]

On October 2, 2017 10:30:49 AM MDT, evo  wrote:
>
>
>Am 01.10.2017 um 22:06 schrieb evo:
>> Hello!
>> 
>> i can not start one of the StandaloneVMs
>> it just give me a timeout and "cannot execute qrexec-daemon"
>> 
>> after reboot the same thing.
>> 
>> logs show the following:
>> 
>> guid.VM
>> Icon size: 128x128
>> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X
>server
>> ":0.0"
>> 
>>   after 31000 requests (31000 known processed) with 0 events
>remaining.
>> 
>> 
>> 
>> can somebody help please?
>> 
>
>
>please help somebody, i have my password-manager and other important
>stuff there and just an older backup :-/

You might be able to recover the essential files by creating a new VM and 
copying the private.img and volatile.img files from the old VM 
(/var/log/qubes/appvms/) to the new one, then booting the new one. 
This worked for me when I had to reinstall QubesOs.

As to the error itself, it seems to suggest a missing icon file somewhere. I 
don't know why that would stop the VM from starting, but qrexec-daemon seems to 
be rather brittle. No idea how you would fix it. Might require either digging 
into the code or help from one of the developers to track down and resolve.

Ron

-- 
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/F491CFE0-3275-42EE-B90A-F4404A11DB11%40shaw.ca.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: timeout on VMstart: cannot execute qrexec-daemon

[evo]

Am 01.10.2017 um 22:06 schrieb evo:
> Hello!
> 
> i can not start one of the StandaloneVMs
> it just give me a timeout and "cannot execute qrexec-daemon"
> 
> after reboot the same thing.
> 
> logs show the following:
> 
> guid.VM
> Icon size: 128x128
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
> ":0.0"
> 
>   after 31000 requests (31000 known processed) with 0 events remaining.
> 
> 
> 
> can somebody help please?
> 


please help somebody, i have my password-manager and other important
stuff there and just an older backup :-/

-- 
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/4544d82e-f639-fa95-9fde-08317d0be1b9%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?

[Patrick Schleizer]

Yethal:
> W dniu środa, 27 września 2017 14:08:56 UTC+2 użytkownik Patrick Schleizer 
> napisał:
>> cooloutac:
>>> On Sunday, September 24, 2017 at 12:23:39 PM UTC-4, cooloutac wrote:
 On Sunday, September 24, 2017 at 12:23:23 PM UTC-4, cooloutac wrote:
> On Sunday, September 24, 2017 at 9:25:24 AM UTC-4, Patrick Schleizer 
> wrote:
>> Quote from https://www.qubes-os.org/doc/usb/
>>
>>> Caution: By assigning a USB controller to a USB qube, it will no
>> longer be available to dom0. This can make your system unusable if, for
>> example, you have only one USB controller, and you are running Qubes off
>> of a USB drive.
>>
>> How can one recover from such a situation if there is no PS2
>> keyboard/mice available?
>>
>> I guess... Unless there is a better way...? Boot the system using from
>> an external disk using a USB recovery operating system... Then modify
>> the local disk (with broken Qubes)... Then do what?
>>
>> Cheers,
>> Patrick
>
> ya that. exactly.

 that would be the only way I would know of.
>>>
>>> sorry i misunderstood.  you could use the qubes keyboard proxy.  or unhide 
>>> it from dom0.  think they are both explained in the docs there, but don't 
>>> think either are recommended but if you have no choice.
>>>
>>
>> The Qubes documentation explains how to hide/unhide it with the gui. But
>> when the disk is not booted (for recovery booted from USB), the gui
>> cannot be used since it refers to the USB booted and not internal disk
>> supposed to be recovered.
>>
>> To undo it some file on the internal disk needs to be modified. Which
>> files needs what modification?
> 
> Remove rd.qubeshideallusb parameter from grub and then rebuild grub
> 

That requires to chroot into the mounted disk system?

Isn't it difficult to run grub from a chrooted disk without messing up
bootloader of the disk that was booted or messing up which devices grub
is referring to?

> Remove rd.qubeshideallusb parameter from grub [...]

If that's all... Then why not just do this during normal system boot at
grub?

Even if it's not hidden all the time from dom0... Won't the
keyboard/mice USB controller be quickly assigned to sys-usb, detached
from dom0 and still leave an unbootable system?

As I understand the documentation rd.qubeshideallusb is "only" for
improved security. One can render its system unusable even without using
rd.qubeshideallusb.

-- 
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/b2f00cd4-2636-e9da-d349-451d619180fe%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qubes-4.0_sys-firewall_failed

[oliver . niesner]

Hi, i just installed qubes-4.0rc1 and updated everything with testing repo 
enabled.
After that, the sys-firewall failed to start with the following error:

"Snapshot origin LV vm-sys-firewall-private not found in Volumegroup qubes_dom0"
I tried to add a symlink in qubes_dom0, but this doesn't work for me.

Any ideas?

Oliver


lrwxrwxrwx 1 root root 7 Oct  2 11:06 root -> ../dm-4
lrwxrwxrwx 1 root root 7 Oct  2 11:06 swap -> ../dm-5
lrwxrwxrwx 1 root root 7 Oct  2 11:06 vm-debian-8-private -> ../dm-8
lrwxrwxrwx 1 root root 7 Oct  2 11:06 vm-debian-8-root -> ../dm-7
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-fedora-25-dvm-private -> ../dm-15
lrwxrwxrwx 1 root root 8 Oct  2 11:46 vm-fedora-25-private -> ../dm-21
lrwxrwxrwx 1 root root 8 Oct  2 11:46 vm-fedora-25-private-snap -> ../dm-28
lrwxrwxrwx 1 root root 8 Oct  2 12:49 vm-fedora-25-root -> ../dm-22
lrwxrwxrwx 1 root root 8 Oct  2 11:46 vm-fedora-25-root-snap -> ../dm-27
lrwxrwxrwx 1 root root 8 Oct  2 11:46 vm-fedora-25-volatile -> ../dm-26
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-personal-private -> ../dm-11
lrwxrwxrwx 1 root root 8 Oct  2 12:49 vm-sys-firewall-root-snap -> ../dm-25
lrwxrwxrwx 1 root root 8 Oct  2 12:49 vm-sys-firewall-volatile -> ../dm-24
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-net-private -> ../dm-16
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-net-private-snap -> ../dm-13
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-net-root-snap -> ../dm-19
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-net-volatile -> ../dm-20
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-usb-private -> ../dm-23
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-usb-private-snap -> ../dm-14
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-usb-root-snap -> ../dm-17
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-sys-usb-volatile -> ../dm-18
lrwxrwxrwx 1 root root 7 Oct  2 11:06 vm-untrusted-private -> ../dm-9
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-vault-private -> ../dm-10
lrwxrwxrwx 1 root root 8 Oct  2 11:06 vm-work-private -> ../dm-12

-- 
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/b9490297-1088-4c36-959f-53166333ab30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Mobile broadband-not enabled

[beso]

On Monday, October 2, 2017 at 12:01:41 AM UTC+3, One7two99 wrote:
> Hello Beso,
> 
> > Mobile Broadband is enabled in 
> > NetworkManager Applet. 
> > I can create new Mobile Broadband 
> > connection but it keeps connecting 
> > and nothing else
> 
>  I am using mobile broadband within Qubes and am happy to help, but honestly 
> your question/problem is to unqualified. 
> 
> - what version of Qubes are you running?
> - what modell of mobile broadband card are you using? 
> - how is the broadband card connected? Probably as an internal USB device. 
> - are you using sys-usb to connect the card to your sys-net VM? Or are you 
> passing through the whole USB controller?
> - have you tried to boot up a Fedora live Linux and check if your mobile 
> broadband is working there?
> - what does "keeps connecting" means?
> 
> My suggestion:
> Try to get the mobile broadband card working without Qubes (Linux Live Boot 
> from USB-Stick).
> If you got it working try to make it work in Qubes.
> 
> [799]

- Laptop is ThinkPad X1 Carbon 4th gen.
- Qubes release 3.2(R3.2)
- Previous linux distros worked (ubuntu 16.04)
- from qvm-usb I can see that card is: Sierra Wireless Incorporated Sierra 
Wireless EM7455 Qualcomm Snapdragon X7
- do I have to attach it somewhere?
- As I mentioned I can create new broadband connection and even select it from 
applet menu but it keeps connecting(applet shows "circles" as trying connect).
I am trying to make screenshot if it helps

-- 
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/ba7bf835-18f8-43ef-89a7-2868417967ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[fepitre]

Le lundi 2 octobre 2017 02:36:48 UTC+2, Reg Tiangha a écrit :
> On 2017-10-01 10:21 AM, Frédéric Pierret (fepitre) wrote:
> 
> > 
> > Hi, just a small update of current kernel branches status:
> > 
> > From our last commits with Reg, the last version of kernel 4.12.14 is 
> > available and also I created the branch for devel-4.13 (currently version 
> > 4.13.4).
> > 
> > From my side, I had kernel panic in VM with latest version 4.12.14 when 
> > merging all the options in CONFIG file from stable-4.9 due to 
> > vlv2_plat_configure_clock related to CONFIG_INTEL_ATOMISP (see 
> > https://github.com/fepitre/qubes-linux-kernel/commit/3edc1d714539aba669c6c710a09b8022ff8fcaa2).
> >  This problem was known for several distros with Xen PV DomU (e.g. 
> > https://bugs.archlinux.org/task/55447 and 
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711298). So not 
> > setting this driver solved my problem (even for kernel-4.13+).
> > 
> > Best,
> > 
> 
> Perfect! I was trying to figure out why 4.13.4 was panicking when used
> in a VM too (dom0 seemed to work fine) but didn't have enough time to
> really dig deep into the kernel options and didn't actually try to boot
> 4.12.14 either; I just assumed it worked (the last one I tried was
> 4.12.13). I'm glad you figured it out! Hopefully, there won't be anymore
> weirdness when 4.14 (the next LTS kernel) comes out.

I'm having also trouble with kernel 4.13.4 on dom0 only. It complains about out 
of memory and kill all processes. I need to dig more into this but kernel 
4.12.14 works fine :)

-- 
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/0e6db623-d693-45aa-89e7-3f4acf7d828c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: qubes 3.2 - sys-net ath10k_pci swiotlb buffer is full after a couple of s3 suspends (wireless not working)

[Vladimir Lushnikov]

After discussing this issue with some other Qubes users that reported
similar problems, I tried downgrading the dom0 kernel to 4.4.67-13 (and
keeping sys-net as 4.9.45-21, xen at 4.6.6)

That seems to resolve the issue between sleeps. Please let me know if
you need logs.

So it looks like it's a kernel bug introduced between 4.4.x and 4.9.x
series, maybe in the xen pci passthrough driver?

I have not had much time to dig into it fully though.

Kind regards,
Vladimir

Vladimir Lushnikov:
> Hello,
> 
> Recently my "Killer Wireless-AC 1535" card has been playing up after
> resuming from S3. It wasn't 100% stable before but usually I was able to
> fix it by either rmmod'ing the driver (ath10k_pci) or restarting sys-net.
> 
> Qubes OS: 3.2
> dom0: xen 4.6.5, kernel 4.9.35-19
> sys-net: fedora-25, kernel cmdline: nopat iommu=soft swiotlb=8192
> Wireless card: Qualcomm Atheros QCA6174
> 
> This is what a normal kernel log (snippet) looks like on sys-net at startup:
> 
> 
> [2.471771] ath10k_pci :00:00.0: Xen PCI mapped GSI16 to IRQ26
> [2.472419] ath10k_pci :00:00.0: pci irq msi oper_irq_mode 2
> irq_mode 0 reset_mode 0
> [2.686863] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:00:00.0.bin failed with error -2
> [2.686887] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/cal-pci-:00:00.0.bin failed with error -2
> [2.687344] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
> [2.687362] ath10k_pci :00:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
> [2.692190] ath10k_pci :00:00.0: qca6174 hw3.2 target 0x0503
> chip_id 0x00340aff sub 1a56:1535
> [2.692203] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 0 testmode 0
> [2.692700] ath10k_pci :00:00.0: firmware ver
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features
> wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
> [2.759968] ath10k_pci :00:00.0: board_file api 2 bmi_id N/A
> crc32 19644295
> [4.878008] ath10k_pci :00:00.0: htt-ver 3.26 wmi-op 4 htt-op 3
> cal otp max-sta 32 raw 0 hwcrypto 1
> [4.940376] ath: EEPROM regdomain: 0x6c
> [4.940379] ath: EEPROM indicates we should expect a direct regpair map
> [4.940383] ath: Country alpha2 being used: 00
> [4.940385] ath: Regpair used: 0x6c
> [4.964842] ath10k_pci :00:00.0 wlp0s0: renamed from wlan0
> 
> 
> After a couple of S3 resumes (sometimes it works fine for 4-5 resumes):
> 
> [11631.485745] PM: noirq thaw of devices complete after 0.500 msecs
> [11631.485745] PM: early thaw of devices complete after 0.137 msecs
> [11631.494090] PM: thaw of devices complete after 0.164 msecs
> [11631.494168] Restarting tasks ... done.
> [11632.215649] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 26
> for gsi 16
> [11632.215663] ath10k_pci :00:00.0: Xen PCI mapped GSI16 to IRQ26
> [11632.216572] ath10k_pci :00:00.0: pci irq msi oper_irq_mode 2
> irq_mode 0 reset_mode 0
> [11632.428622] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:00:00.0.bin failed with error -2
> [11632.428648] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/cal-pci-:00:00.0.bin failed with error -2
> [11632.428662] ath10k_pci :00:00.0: Direct firmware load for
> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
> [11632.428670] ath10k_pci :00:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
> [11632.428977] ath10k_pci :00:00.0: qca6174 hw3.2 target 0x050s3
> chip_id 0x00340aff sub 1a56:1535
> [11632.428986] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 0 testmode 0
> [11632.429571] ath10k_pci :00:00.0: firmware ver
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features
> wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
> [11632.491890] ath10k_pci :00:00.0: board_file api 2 bmi_id N/A
> crc32 19644295
> [11635.005126] ath10k_pci :00:00.0: swiotlb buffer is full (sz: 1984
> bytes)
> [11635.009958] ath10k_pci :00:00.0: swiotlb buffer is full (sz: 2048
> bytes)
> [11635.009974] ath10k_pci :00:00.0: failed to dma map pci rx buf
> [11635.009993] ath10k_pci :00:00.0: failed to post pci rx buf: -5
> [11635.010058] ath10k_pci :00:00.0: swiotlb buffer is full (sz: 1984
> bytes)
> [11635.010142] ath10k_pci :00:00.0: swiotlb buffer is full (sz: 16
> bytes)
> [11635.010153] ath10k_pci :00:00.0: failed to connect htt (-5)
> [11635.060076] ath10k_pci :00:00.0: swiotlb buffer is full (sz: 1984
> bytes)
> [11635.060160] ath10k_pci :00:00.0: failed to dma map pci rx buf
> [11635.060178] ath10k_pci :00:00.0: failed to post pci rx buf: -5
> [11635.060259] ath10k_pci :00:00.0: failed to dma map pci rx buf
> [11635.060274] ath10k_pci :00:00.0: failed to post pci rx buf: -5
> [11635.067301] ath10k_pci :00:00.0: could not init core (-5)
> [11635.067679] ath10k_

Re: [qubes-users] Re: Has anyone tried to activate SELINUX in Fedora 25?

[pels]

On Thursday, September 28, 2017 at 5:59:09 PM UTC+2, steve.coleman wrote:
> On 09/26/2017 05:35 AM, pels wrote:
> > On Sunday, September 24, 2017 at 6:19:15 PM UTC+2, cooloutac wrote:
> >> On Sunday, September 24, 2017 at 12:17:33 PM UTC-4, cooloutac wrote:
> >>> On Sunday, September 24, 2017 at 12:16:34 PM UTC-4, cooloutac wrote:
>  On Thursday, September 21, 2017 at 4:40:42 AM UTC-4, pels wrote:
> > On Wednesday, September 20, 2017 at 2:54:31 PM UTC+2, cooloutac wrote:
> >> On Wednesday, September 20, 2017 at 4:41:58 AM UTC-4, pels wrote:
> >>> I'd like to activate SELINUX(enforcing) in VMs (f25 and f25-minimal), 
> >>> but fails:
> >>>
> >>> [1.510532] audit: type=1404 audit(1505894636.317:2): enforcing=1 
> >>> old_enforcing=0 auid=4294967295 ses=4294967295
> >>> [1.601491] audit: type=1403 audit(1505894636.408:3): policy 
> >>> loaded auid=4294967295 ses=4294967295
> >>> [1.605815] systemd[1]: Successfully loaded SELinux policy in 
> >>> 95.611ms.
> >>> [1.617897] systemd[1]: Failed to mount tmpfs at /run: Permission 
> >>> denied
> >>> [.[0;1;31m!!.[0m] Failed to mount API filesystems, freezing.
> >>> [1.621206] systemd[1]: Freezing execution.
> >>>
> >>> I had it enabled  in fedora 24 but after upgrading failed
> >>> I create a new template (f25 and f25-minimal) with same effect.
> >>>
> >>> I have tried to reset SELinux to its initial state:
> >>> yum remove selinux-policy
> >>> rm -rf /etc/selinux
> >>> yum install selinux-policy-targeted
> >>> fixfiles -f -F relabel
> >>> reboot
> >>>
> >>> Any ideas?
> >>>
> >>> Thank you very much
> >>>
> >>> Best Regards
> >>
> >>Is this a vm, if so do we really care if systemd is running in it?  
> >>  You sure thats selinux?  what does sestatus say?
> >>
> >> When googling this error seems people have same issue when running 
> >> docker.  And you have to set seccomp to unconfined.
> >
> > Thank you cooloutac
> >
> > -Is this a vm
> > It happens in Templates and VMs.
> >
> > -Is this a vm, if so do we really care if systemd is running in it?
> > The problem is when i enable SELINUX VMs/templates doesn't "boot" or 
> > fail to start.
> > If I disable SELINUX, the templates/VMs start whithout problems and 
> > systemd is activated.
> >
> > -You sure thats selinux?
> > Yes i'm pretty sure, it's exactly the same config that i had in 
> > fedora24.
> > In dom0
> > qvm-prefs -s fedora-25 kernelopts "nopat security=selinux selinux=1"
> > and in VMs/Templats
> > /etc/selinux/config
> >
> > SELINUX=enforcing
> > SELINUXTYPE=targeted
> >
> > Default selinux config
> >
> > -what does sestatus say?
> > I can't execute anything in template/VMs
> > in dom0:
> > qvm-run fedora-25 --nogui -pass-io -u root "sestatus"
> > Error(fedora-25): Domain 'fedora-25':qreexec not connected
> >
> > -When googling this error seems people have same issue when running 
> > docker.  And you have to set seccomp to unconfined
> >
> > Yes, i've read it, but i don't know how disable seccomp and the 
> > consequences...
> >
> >
> > Could you make me a big favour and try to activate SELINUX?
> >
> > Thank you very much
> >
> > Best regards
> 
>  Probably only useful in the template vm.  But still not sure how 
>  beneficial it would be was my point though.  Its probably not compatible 
>  with qubes, sounds like it breaks qrexec, maybe not worth the headache 
>  man.
> >>>
> 
> Try running SELinux in permissive mode then use the SELinux audit2allow 
> to turn the permission violations into new permit rules. Those permit 
> rules will allow the system to boot normally once applied to the system 
> policy. This process may need to be repeated.
> 
> I used to use this script back when I was using tcsh on a stock Fedora 
> system, but it would be trivial to change to bash or just use the 
> command line:
> 
> #!/bin/tcsh
> echo
> # find the avc entries for the application in the log file
> grep "$argv[1]" /var/log/audit/audit.log >  "my$argv[1].out"
> 
> # pass those entries to audit to allow
> cat  "my$argv[1].out" | audit2allow -M "my$argv[1]"
> 
> # display the generated policy so you can learn what its doing
> cat "my$argv[1].te"
> 
> echo
> 
> # Just output to stdout the command needed to commit the new policy,
> # this is for cut and paste command execution
> 
> echo semodule -i my$argv[1].pp
> echo
> 
> Basically you give the script a search string and it grep locates all 
> avc permission violations containing that application-name/error-message 
> and creates a policy file to fix those specific problems, and then it 
> echos the command needed to actually fix it to the console. If you agree 
> with those permissions displa