On 2017-01-19 9:39 AM, Антон Чехов wrote: > On Thursday, January 19, 2017 at 5:25:00 PM UTC+1, Reg Tiangha wrote: >> On 2017-01-19 9:18 AM, Антон Чехов wrote: >>> On Wednesday, January 18, 2017 at 5:35:53 PM UTC+1, Reg Tiangha wrote: >>>> On 2017-01-18 7:14 AM, Антон Чехов wrote: >>>>> Hello, >>>>> >>>>> I am testing coldkernel and I have a few questions. Does or should it >>>>> work with a vpn gateway? Do I have to change some config file or special >>>>> permissions? >>>>> I did not use grsec much in the past so I am in the process of learning.. >>>>> I could connect to my coldkernel appvm via vpn gateway after freshly >>>>> compiling and starting the appvm. After reboot none of my coldkernel >>>>> appvm is connecting to the internet via vpn gateway anymore but >>>>> connecting to clearnet without a proxyvm. >>>>> >>>> >>>> To get the coldkernel working properly with net/proxyVMs and usbVMs, you >>>> need to add at least two more drivers to the kernel's .config file: >>>> >>>> CONFIG_XEN_BLKDEV_BACKEND=m >>>> CONFIG_XEN_NETDEV_BACKEND=m >>>> >>>> The easiest way to do that is to add those two lines to the >>>> coldkernel.config file *before* running "make qubes-guest" >>> >>> Thanks for your answer. I added the lines to the coldkernel.config and >>> compiled the kernel again (in the existing coldkernel-template). Don't know >>> if that's a mistake? Upon starting an appVM with coldkernel the VM pauses >>> (yellow) and the log is giving me loads of this: >>> "grsec: denied priority change of process rtkit-daemon:1115 (...)" >>> This applies to the templateVM as well so I am asking myself what's best >>> practice of updating the coldkernel template? >>> It is obvious that I don't know my way around grsec and I have to do more >>> research into how to do things. >>> >> >> Yeah, I get that too. I think you can ignore it in the sense that the >> VMs will still work despite the error, although I don't know if there >> are really any adverse effects. >> >> I haven't tried to fix it myself, though, but I assume a PAX exception >> would need to be set for the daemon in order to "fix" it (not hard to >> do, but I lack the time to troubleshoot at the moment). >> >> What the rtkit-daemon is: >> >> "RealtimeKit is a D-Bus system service that changes the >> scheduling policy of user processes/threads to SCHED_RR (i.e. realtime >> scheduling mode) on request. It is intended to be used as a secure >> mechanism to allow real-time scheduling to be used by normal user >> processes." >> >> I don't know how it affects the operations of VMs though and whether or >> not it being denied by the grsec kernel is actually a big deal. > > But I can't start neither the AppVm nor the template anymore so it is kind of > a big deal, don't you think? > That's why I am asking how to update. > Do I have to start over from scratch or should it work from the template? > Apparently something went wrong although everything looked fine during the > process of compiling. >
My templates and AppVMs start up just fine despite having that error. What do you mean when you say yours don't? As in, they don't start up at all, or they do but the indicator on Qubes Manager for that VM is yellow instead of green and never changes even after the CPU usage drops to 0%? And what VMs are you running the kernel on? Are they Debian based or Fedora based? And what versions of those distros? -- 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/o5qqb9%24sg0%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
