[qubes-users] How to use the raw vchan library - no Qrexec
I want to experiment a bit with the vchan library and develop a program that make unprivileged VMs communicate without using the network and without Qrexec or any Qubes specific framework. Qubes OS run on top of Xen, so it should be possible to use the vchan library inside the unprivileged domains. 1) In the sites its described a communication between Dom0 and a VM, but I need to establish variuos bidirectional channels between VMs. Is it possible? 2) Does Qubes OS use a different version of the vchan library or set up specific limitations that could make the job harder? 3) In the libs folders I found all the libraries I think I need, but I couldn't find any header (libxenvchan.h, ...) in the VMs systems, so do I need to compile and install Xen from source, to be able to write my own programs, even on Qubes? And if I wanted to distribute a package, the default Debian/Fedora templates would need extra deps? I've tried to write a new header with the `extern` declarations and compile 'node.c' from /xen/tools/libvchan: [https://github.com/xen-project/xen/blob/master/tools/libvchan/node.c] as a test, linking the binary to 'libvchan-xen.so', which I think its Qubes specific and 'libxenvchan.so' in a second attempt. The compilation succeded, but the program couldn't establish any connections between VMs: user@develop:~/myvchan$ ./node server write 3 /data/vchan libxenvchan_*_init: Permission denied user@develop:~/myvchan$ ./node server write 3 libxenvchan_*_init: Permission denied user@develop:~/myvchan$ ./node client read 3 /data/vchan libxenvchan_*_init: Permission denied user@develop:~/myvchan$ ./node client read 3 /local/domain//myc libxenvchan_*_init: No such file or directory user@develop:~/myvchan$ xenstore-exists /local/domain//matrix user@develop:~/myvchan$ echo $? 0 Anyone can explain me what I'm missing and guide me through the right procedure ? -- 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/5a2a4aec-7ff7-4749-a22f-beff4adba51e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Networking doesn't work in Qubes 4.0-rc5
I've been using R4-rc2 for some months and I've just installed the R4-rc5 version, but it's giving me hard times. During the installation it complains about Vt-d and Interrupt Remapping feautures missing and sys-usb didn't work at the beginning, but after I switched to PV mode it works fine, I can connect to my WiFi and sys-net can reach the internet. The point is any other qube, sys-firewall included, can't reach the internet. - I've tried to analyze the traffic with wireshark and it seems that the DNS requests reach sys-net, but no answer is received, while in sys-net everything seems fine (`dig` works). - I've tried to ping sys-firewall and send some packets from sys-net with the Python socket and the packets reach sys-firewall but the `recv()` function stucks in a death loop as nothing is received, so I think somewhere the packets are dropped. - I've tried to clear all iptables chains, but nothing changed. Everything worked in rc1, rc2 and I think also rc3 (I can't remember the last update - current-testing repo), so I really can't figure out what I'm missing. Some major changes concerning networking were introduced in rc5? Anyone is experiencing the same problem? Any suggestions? -- 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/fd89ecb3-6762-4a68-88bf-97f3f864b0d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Failed to verify R4.0 rc2 digests
I've just finished to download all the files for R4.0 rc2, but the verification failed. gpg --verify Qubes-R4.0-rc2-x86_64.iso.asc Qubes-R4.0-rc2-x86_64.iso.DIGESTS gpg: Signature made Sat Oct 21 10:10:36 2017 BST using RSA key ID 9E2795E9 gpg: BAD signature from "Qubes OS Release 4 Signing Key"' -- 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/20feec84-cdaa-4fb8-853f-3aad741a772d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Jupyter notebook
I had the same problem with fedora 25 in R4.0, but I managed to install it in fedora 26 and it 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/e01a150b-002c-4a53-826d-1e5daeb19f31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Properly setup a qube dns cache server
Please, someone? -- 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/8fb316bb-a6d6-404e-8b31-2da2db4d2324%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Properly setup a qube dns cache server
I'm already in the process of implementing this feauture (method A) in R4.0.
> dom0 doesn't store any DNS settings. Each VM forwards packets to the
> next upstream VM and the DNS decision is made at your netvm resolv.conf.
> Dynamic firewalls (iptables in 3.2, netfilter or so in 4.0) managed by
> the dom0 qvm-firewall in your proxsy & firewall VMs ensure only allowed
> traffic is going through. DNS uses dnat rules. Dom0 uses your firewall
> VM to pull updates.
I'm aware of the Qubes networking mechanisms.
What I'm trying to achieve is the following:
1) New fields in 'Qubes Global Settings' menu, under 'System defaults' (Dom0)
that let the user choose the default primary and secondary DNS (now
'10.139.1.1' and '10.139.1.2').
How this will be implemented?
Dom0 will inform the first NetVM backends ('sys-firewall', 'sys-net' or a
VpnVM) of the change though a rpc service and this will trigger
`qubes-dnat-to-ns` which will procede to update the (NAT) iptables.
-> All the DNS requests destinated to '10.139.1.1' and '10.139.1.2' DNAT to
the new DNS backend specified by the user <-
This method doesn't require any changes to the Templates or the AppVMs, but
only to install a rpc service and a custom `qubes-dnat-to-ns` script in the VMs
that provide network (ProxyVMs and NetVMs).
2) New fields in 'VM Settings' menu (Dom0) that let the user choose the primary
and secondary DNS for each VM, if the machine has network.
How this will be implemented?
Dom0 will inform the NetVM backend to which the VM is attached and the (NAT)
iptables will be modified to DNAT all the DNS requests from a the specific VM
vif interface (-i vifX.0) to the new addresses provided.
Again, no changes are required to the Templates or the AppVMs, but only to the
VMs that provide network (ProxyVMs and NetVMs).
*
ISSUES:
1) I solved the first issue and I discovered how to retrieve vif names from xen
database,
2) I still don't know how to make all VMs that provide network launch a script
when a new vif interface came up.
As I said before, I've found the this file
'/etc/udev/rules.d/99-qubes-network.rules' that I believed was the solution,
but it seem not to work at all,
3) My code still rely on files, because the Qubes API and Qubesadmin API has
confused me a lot.
I need to add:
- the attributes 'default_primary_dns' and 'default_secondary_dns' to
'qubesadmin.app.QubesBase' and
- the properties 'primary_dns' and 'secondary_dns' to the base Class that
represent a VM object.
I don't know if I have to modify 'Qubes' or 'Qubesadmin' and if this is enough
for the `qubesd` calls or if it's not possible to add new properties at all.
I really need help from the developers, expecially for the point n.3.
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/7a66a147-8348-4eeb-98f7-bb4b2438a7e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Properly setup a qube dns cache server
I'm already in the process of implementing this feauture (method A) in R4.0.
> dom0 doesn't store any DNS settings. Each VM forwards packets to the
> next upstream VM and the DNS decision is made at your netvm resolv.conf.
> Dynamic firewalls (iptables in 3.2, netfilter or so in 4.0) managed by
> the dom0 qvm-firewall in your proxsy & firewall VMs ensure only allowed
> traffic is going through. DNS uses dnat rules...
>
I'm aware of the Qubes networking mechanisms.
What I'm trying to achieve is the following:
1) New fields in 'Qubes Global Settings' menu, under 'System defaults' (Dom0)
that let the user choose the default primary and secondary DNS (now
'10.139.1.1' and '10.139.1.2').
How this is will be implemented?
Dom0 will inform the first NetVM backends ('sys-firewall', 'sys-net' or a
VpnVM) of the change though a rpc service and this will trigger
`qubes-dnat-to-ns` which will procede to update the (NAT) iptables.
-> All the DNS requests destinated to '10.139.1.1' and '10.139.1.2' DNAT to
the new DNS backend specified by the user <-
This method doesn't require any changes to the Templates or the AppVMs, but
only to install a rpc service and a custom `qubes-dnat-to-ns` script in the VMs
that provide network (ProxyVMs and NetVMs).
2) New fields in 'VM Settings' menu (Dom0) that let the user choose the primary
and secondary DNS for each VM, if the machine has network.
How this is will be implemented?
Dom0 will inform the NetVM backend to which the VM is attached and the (NAT)
iptables will be modified to DNAT all the DNS requests from a the specific VM
vif interface (-i vifX.0) to the new addresses provided.
Again, no changes are required to the Templates or the AppVMs, but only to the
VMs that provide network (ProxyVMs and NetVMs).
ISSUES:
1) I solved the first issue and I discovered how to retrieve vif names from xen
database,
2) I still don't know how to make all VMs that provide network launch a script
when a new vif interface came up.
As I said before, I've found the this file
'/etc/udev/rules.d/99-qubes-network.rules' that I believed was the solution,
but it seem not to work at all,
3) My code still rely on files, because the Qubes API and Qubesadmin API has
confused me a lot.
I need to add:
- the attributes 'default_primary_dns' and 'default_secondary_dns' to
'qubesadmin.app.QubesBase' and
- the properties 'primary_dns' and 'secondary_dns' to the base Class that
represent a VM object.
I don't know if I have to modify 'Qubes' or 'Qubesadmin' and if this is enough
for the `qubesd` calls or if it's not possible to add new properties at all.
I really need help from the developers, expecially for the point n.3.
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/38f7121d-b047-431d-b4c2-aedc2b68a9fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Properly setup a qube dns cache server
I'm already in the process of implementing this feauture (method A) in R4.0.
> dom0 doesn't store any DNS settings. Each VM forwards packets to the
> next upstream VM and the DNS decision is made at your netvm resolv.conf.
> Dynamic firewalls (iptables in 3.2, netfilter or so in 4.0) managed by
> the dom0 qvm-firewall in your proxsy & firewall VMs ensure only allowed
> traffic is going through. DNS uses dnat rules...
I'm aware of the Qubes networking mechanisms.
What I'm trying to achieve is the following:
1) New fields in 'Qubes Global Settings' menu, under 'System defaults' (Dom0)
that let the user choose the default primary and secondary DNS (now
'10.139.1.1' and '10.139.1.2').
How this is will be implemented?
Dom0 will inform the first NetVM backends ('sys-firewall', 'sys-net' or a
VpnVM) of the change though a rpc service and this will trigger
`qubes-dnat-to-ns` which will procede to update the (NAT) iptables.
-> All the DNS requests destinated to '10.139.1.1' and '10.139.1.2' DNAT to
the new DNS backend specified by the user <-
This method doesn't require any changes to the Templates or the AppVMs, but
only to install a rpc service and a custom `qubes-dnat-to-ns` script in the VMs
that provide network (ProxyVMs and NetVMs).
2) New fields in 'VM Settings' menu (Dom0) that let the user choose the primary
and secondary DNS for each VM, if the machine has network.
How this is will be implemented?
Dom0 will inform the NetVM backend to which the VM is attached and the (NAT)
iptables will be modified to DNAT all the DNS requests from a the specific VM
vif interface (-i vifX.0) to the new addresses provided.
Again, no changes are required to the Templates or the AppVMs, but only to the
VMs that provide network (ProxyVMs and NetVMs).
ISSUES:
1) I solved the first issue and I discovered how to retrieve vif names from xen
database,
2) I still don't know how to make all VMs that provide network launch a script
when a new vif interface came up.
As I said before, I've found the this file
'/etc/udev/rules.d/99-qubes-network.rules' that I believed was the solution,
but it seem not to work at all,
3) My code still rely on files, because the Qubes API and Qubesadmin API has
confused me a lot.
I need to add:
- the attributes 'default_primary_dns' and 'default_secondary_dns' to
'qubesadmin.app.QubesBase' and
- the properties 'primary_dns' and 'secondary_dns' to the base Class that
represent a VM object.
I don't know if I have to modify 'Qubes' or 'Qubesadmin' and if this is enough
for the `qubesd` calls or if it's not possible to add new properties at all.
I really need help from the developers, expecially for the point n.3.
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/126d08c0-9846-4c50-832f-b0636a35e973%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Properly setup a qube dns cache server
Up to now, I've thought of 2 possible solutions:
Of course Dom0 or a NetManagementVM (thanks to the new Admin API) has to store
the DNS settings for the VMs with Networking and the easy way is to store only
the infos about VMs that don't use the standars DNS (10.139.1.1 and 10.139.1.2).
So, adjustments have to be made to let the user specify a dnsVM in 'VM
Settings', when Networking in not '(none)' and a default 'DNS Backend' field
(new field in the GUI Qubes Global Settings) where the default value '(none)'
or 'sys-net' corresponds to '10.139.1.1' and '10.139.1.2'.
Method a)
1) Every time a vif+ interface goes up in the FirewallVM (or the NetVM
backend), this would have to run `qubes-setup-dnat-to-ns` like VMs that provide
network do, but this time the script will retrieve the DNS through a rpc
service instead of '/etc/resolv.conf'.
2) The rpc service will ask Dom0 (or the NetManagementVM) to update the net
configurations, so Dom0 will retrive the list of current running VMs attached
to the FirewallVM (or the NetVM backend) and provide it a list of VMs that
don't use the default configurations and their the custom DNS backend IPs.
3) The FirewallVM (or the NetVM backend) will than update the iptables with
secific DNAT of packets destinated to port 53 to specific IPs thanks to the
infos received from Dom0 and maintain the general rule that DNAT all packets
destinated to port 53 of '10.139.1.1' and '10.139.1.2' to the DNS specified in
'/etc/resolv.conf'.
Method b)
Every time a qube is started from Dom0, Dom0 launch a rpc-service in its NetVM
and passes to it any custom DNS configuration, if present, and the rpc service
again, is the one responsible for executing a modified `qubes-setup-dnat-to-ns`
to update the iptables.
So, the current 'sys-firewall' NAT table looks like this:
-N PR-QBS
-N PR-QBS-SERVICES
-A PREROUTING -j PR-QBS
-A PREROUTING -j PR-QBS-SERVICES
-A POSTROUTING -o vif+ -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -j MASQUERADE
-A PR-QBS -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination
10.139.1.1
-A PR-QBS -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination
10.139.1.1
-A PR-QBS -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination
10.139.1.2
-A PR-QBS -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination
10.139.1.2
And, the new 'sys-firewall' NAT table will look like this (with both methods):
-N PR-QBS
-N PR-QBS-SERVICES
-A PREROUTING -j PR-QBS
-A PREROUTING -j PR-QBS-SERVICES
-A POSTROUTING -o vif+ -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -j MASQUERADE
-A PR-QBS -i vifX -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT
--to-destination
-A PR-QBS -i vifX -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT
--to-destination
-A PR-QBS -i vifX -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT
--to-destination
-A PR-QBS -i vifX -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT
--to-destination
-A PR-QBS -i vifY -d 10.139.1.1/32 -p udp -m udp --dport 5353 -j DNAT
--to-destination
-A PR-QBS -i vifY -d 10.139.1.1/32 -p tcp -m tcp --dport 5353 -j DNAT
--to-destination
-A PR-QBS -i vifY -d 10.139.1.2/32 -p udp -m udp --dport 5354 -j DNAT
--to-destination
-A PR-QBS -i vifY -d 10.139.1.2/32 -p tcp -m tcp --dport 5354 -j DNAT
--to-destination
...
# Defaults
-A PR-QBS -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination
10.139.1.1
-A PR-QBS -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination
10.139.1.1
-A PR-QBS -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination
10.139.1.2
-A PR-QBS -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination
10.139.1.2
It seems to me that the first solution is more elegant and flexible, since it
allows the FirewallVM to query other machines than Dom0 for networking
configurations. That is the case described also in the Docs where, thanks to
the new Admin API, a new ManagmmentVM can install a custom Template and manage
all the AppVMs that use that Template and their settings.
ISSUES:
1) I haven't discovered yet, how retrive the vif backend interface name of a
specific VM from Dom0 (querying the Xen DB I think), in order to pass to the
FirewallVM (or the NetVM backend) the infos in this format:
[ ... ].
Now, for testing purposed one could use the format: [ ...
] and the iptables rules: `sudo iptables -t nat -A PR-QBS -s -d
10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination `
2) I don't know if I can use udev rules to or Fedora/Debian cutoms system
launch a script that interact with Dom0 and launch `qubes-setup-dnat-to-ns`.
I've found the file '/etc/udev/rules.d/99-qubes-network.rules' wich cointains
the following line:
SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add",
ENV{ID_NET_DRIVER}=="vif", RUN+="/usr/lib/qubes/setup-ip"
, but it doesn't seem to do anything (I've tried to remove it, restart udev and
start a VMs, but the connection works fine).
[qubes-users] Properly setup a qube dns cache server
I'd like to setup a DNS cache server with a cache application like dnsmasq or similar on a different qube than 'sys-net', so that 'sys-firewall' DNAT all requests to my dnsVM, instead of passing it directly to 'sys-net' and the dnsVM, of course, could pass both 'sys-firewall' or 'sys-net'. I'd like to have an easy way to switch the DNS configurations from dom0, both via cli and GUI, maybe in the 'Qubes Global Settings' with another field in the 'System Defaults' section, that let me switch from 'sys-net' to other qubes. The final goal is to make possible to specify a custom dnsVM backend based on tags and labels, for example to send all request from "trusted" VMs to a dnsVM with where a DNSCrypt is installed and all request from "untrusted" VMs to a dnsVM that apply a small set of filtering rules. The problem is I don't know which configurations/files to change and how to make this configuration persist for a session or permanently, since I know ServiceVMs update dynamically the iptables rules, the nat table in particular, on interfaces UP and DOWN events. 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/a46dcc76-7df4-4b0a-9199-2db6475b89f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Can't login to VM after upgrade to fedora 26
I've upgraded a fedora-25 template in R4.0 rc1/current-testing to fedora-26 and now the VM stops at login(tty1). It doesn't let me login as 'user', but only as root and after few seconds being root, the VM shutdowns. Upgrade commands: `sudo dnf clean all` `sudo dnf --best --allowerasing --releasever=26 distro-sync` Is there any way to fix the Template? And what about the trimming, since `qvm-trim-template` is gone? -- 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/05fc01b7-1bed-46b8-bff6-a0f9ce73d1c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Install Whonix Templates in R4.0 rc1/2
Thanks for the answer. The release note specified at that time there was no Whonix template available for R4.0 rc1, but now they are available in the template-community repo and we are at rc2 (almost). -- 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/e82475a2-c46d-4945-940f-d5b0a9dbe212%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Impressions of the Purism Librem 15v3 for Qubes
Thanks for the details. Can you send a simple benchmark (`hdparm -t --direct`) of the default ssd pre-installed, if you didn't choose another drive? -- 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/7bab682f-c111-45a0-9a3a-58f6970bf69a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix
I don't know if dom0 actually warned you after having successfully removed the packages or it didn't let you do that because of the matter it warned you about. Anyway, I think the problem is you set up the dom0 updates to be done through Whonix, so you can try to change the UpdateVM field in the Qubes Global Settings (I can't recall now if R3.2 has the same name), choosing for example 'sys-firewall' and then remove the Whonix Templates. -- 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/bdc4c7e0-9a10-4370-a5ef-6b8d232b01f7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Managing Xen configs
Great, thank you so much. And if I wanted to manually change some libvirt configs and play with network interfaces? -- 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/2ad8e295-25ff-4f84-bf2d-54d3b6a97b21%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Managing Xen configs
Please, help me with this. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a4d11c03-cdbb-49b7-a599-93cc63461483%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Managing Xen configs
I'd like to know where the Xen configurations are stored and how to manipulate them, for example, to add net interfaces or exposing a console. -- 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/72b61c1f-51bf-4e10-8ad3-ace0152d386e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Managing Xen configs
Thanks for your answer. I wrote that I'm trying to connect TO a Template Emergency Dracut shell FROM Dom0, using 'xl console'. -- 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/fbd0ed21-a976-44f2-a6ae-61ba1a176996%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Managing Xen configs
Any help? -- 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/8ffc8844-bf43-48c5-819b-ef3409a6aa0f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qrexec to mimic ssh listen?
I think you can use a systemd socket associated with a `socat` service that connects the rpc stdin/stdout to a target VM listening port. You can mimic how the Templates updates packets are redirected to the port 8082 of sys-net using rpc in R4.0. Since you're using R3.2, if you can't figure out anything, I'll post here an example tomorrow. -- 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/5f7686a0-703c-4285-9b6f-b2e704f52bb9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qrexec to mimic ssh listen?
I think you can use a systemd socket associated with a `socat` service that connects the rpc stdin/stdout to a target VM listening port. You can see the basics in how the Templates updates packets are redirected to the port 8082 of sys-net using rpc. -- 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/122c2119-df76-40b2-a4d5-8009d63c3cb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HOW TO compile templates from sources
Thank you, you saved me. -- 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/971326ba-3d10-47f3-af5c-849fd66e672a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HOW TO compile templates from sources
What do you mean by 'pick'? This is the part I think it's not immediate. Do the scripts download automatically the chosen version or I have to get the sources? I've managed to find only the spec (config) files for Fedora and Debian for Qubes R3.1 and not for R3.2 or R4.0? Do you know where I can find at least the necessary files for R3.2? Can I start from the official rpms, make changes and then rebuild the packages? -- 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/2c0d00eb-4fe5-4a13-8c41-d59d2981fb7c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HOW TO compile templates from sources
I've tried to figure out something reading the docs, but it seems to me there are more infos about how to compile a template based on a new system rather than a Fedora or Debian one. I wanted to try with the minimal flavour of fedora 25 and Debian 9. Can someone guide me through the entire process and tell me if its possible to start from the official rpms too, to make some custom changes? Thanks guys. -- 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/679642c7-703a-47de-8907-6e5124f61abe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-block doesn't list/expose dom0 loop devices
Nobody has noticed this? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/46d54335-fe77-4766-9acb-57735e34a514%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-block doesn't list/expose dom0 loop devices
I'm using R4.0 rc1.
I wanted to install a Linux distro inside a disk image located in dom0 home,
using QEMU in an AppVM.
I've created a new disk image in dom0, set it up (dos partition label and a
primary ext4 partition) and attached it with `kpartx` to loopX, but `qvm-block`
doesn't list it in the exposed block devices.
So, in order to understand better how Qubes handles this, I've tried to do the
same in a VM and see if the dom0 would catch the event, but nothing.
Strangely, when I detached the disk image, both the 'AppVM:loopX - IMG_PATH is
available' and 'AppVM:loopX - IMG_PATH is removed' notifications appeared on
the screen.
I've read a lot about it, but I think what I found was all related to a < R4.0
version, so I don't know if this issue is related to a intended design or a bug.
Procedure:
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/table.raw bs=2048 count=1
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/root.raw bs=3GB count=1
[user@dom0 ~]$ mkfs.ext4 /home/user/root.raw
[user@dom0 ~]$ cat /home/user/{table,root}.raw > /home/user/root.img
[user@dom0 ~]$ rm /home/user/{table,root}.raw
[user@dom0 ~]$ truncate -s 3GB /home/user/root.img
[user@dom0 ~]$ fdisk /home/user/root.img
o new DOS partition table
n new partition
p primary
1 first
2048 first sector
\n to the end
[user@dom0 ~] fdisk -l /home/user/root.img
Disk /home/user/root.img: 2.8 GiB, 30 bytes, 5859375 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xda159b44
Device Boot Start End Sectors Size Id Type
root.img12048 5859374 5857327 2.8G 83 Linux
[user@dom0 ~] sudo kpartx -a /home/user/root.img
[user@dom0 ~] losetup -l
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
DIO
/dev/loop40 0 0 0 0 /home/user/root.img
0
[user@dom0 ~] ls /dev/mapper
control loop40p1 ...
--
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/35f29cb8-e8d6-4cba-8cc0-ea02517eee46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-block doesn't list dom0 loop devices
I'm using R4.0 rc1.
I wanted to install a Linux distro inside a disk image located in dom0 home,
using QEMU in an AppVM.
I've created a new disk image in dom0, set it up (dos partition label and a
primary ext4 partition) and attached with `kpartx` to loopX, but `qvm-block`
doesn't list in the exposed block devices.
So, in order to understand better how this thing is handled by Qubes, I've
tried to do the same in a VM and see if the dom0 would catch the event, but
nothing.
Strangely, when I detached the disk image, both the 'AppVM:loopX - IMG_PATH is
available' and 'AppVM:loopX - IMG_PATH is removed' notifications appeared on
the screen.
I've read a lot about it, but I think what I found was all related to a < R4.0
version, so I don't know if this issue is related to a intended design or a bug.
Procedure:
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/table.raw bs=2048 count=1
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/root.raw bs=3GB count=1
[user@dom0 ~]$ mkfs.ext4 /home/user/root.raw
[user@dom0 ~]$ cat /home/user/{table,root}.raw > /home/user/root.img
[user@dom0 ~]$ rm /home/user/{table,root}.raw
[user@dom0 ~]$ truncate -s 3GB /home/user/root.img
[user@dom0 ~]$ fdisk /home/user/root.img
o new DOS partition table
n new partition
p primary
1 first
2048 first sector
\n to the end
[user@dom0 ~] fdisk -l /home/user/root.img
Disk /home/user/root.img: 2.8 GiB, 30 bytes, 5859375 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xda159b44
Device Boot Start End Sectors Size Id Type
root.img12048 5859374 5857327 2.8G 83 Linux
[user@dom0 ~] sudo kpartx -a /home/user/root.img
[user@dom0 ~] losetup -l
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
DIO
/dev/loop40 0 0 0 0 /home/user/root.img
0
[user@dom0 ~] ls /dev/mapper
control loop40p1 ...
--
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/52961c52-1745-4799-8c29-592853d02953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Audio broken in R4.0 rc1 / qvm-run fails to start AppVM
I've checked the BIOS configs and VT-d is enabled. -- 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/538d3d0e-0cda-4259-bc7f-fbac12880401%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
Thanks for all the details. I've tested on the R4.0 rc1, so fc25, I'll try it soon on the R3.2 (fc23 and fc24), so we can crosscheck the script. I saw both dom0 and vm rpms are generated, but is it better to generate different rpms for them with config-host and config-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/9bbd1168-99c1-4d44-8733-4d0fff65f44d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
Thanks for all the details. I've tested on the R4.0 rc1, so fc25, I'll try it soon on the R3.2 (fc23 and fc24), so we can crosscheck the script. I saw both dom0 and vm rpmd are generated, but wouldn't be better to generate different rpms based on config-host and config-guest? -- 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/8082f643-5ac7-464c-861b-2e2030fbd5f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
I think Reg has done a great job and the porting its a must go path to force the developers to throw away all the differences that slow down or prevent the develop of a secure system. -- 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/5e907d70-409e-4afc-8134-ad1210c4821b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
Thanks for your answer! I had already noticed that, in fact I'm using the host version as .config, but an error occurs at the line specified above. With the trick of using the current configs and then override them with your file I've managed to build the rpms, but the sign fails (maybe it's the key related issue you commentes about in the spec file), so I wanted to ask you to check if it could be a problem with my system or packages. -- 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/802ab249-c249-4bd5-b29d-1c9570b9028d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Audio broken in R4.0 rc1 / qvm-run fails to start AppVM
I've used Qubes 3.2 and everythings there worked fine, but now I'm trying R4.0 rc1 and I can't figure out why the sound doesn't work. `qvm-pci` reports 2 Intel Audio Devices (00:03.0 and 00:1b.0), so I've tried to attach them to an base AppVm, such personal and start it with `qvm-run`, but it returns: "Start failed: internal error: libxenlight failed to create new domain 'personal'", while without those audio devices the VM starts without any problems. Related Bug Issue: https://github.com/QubesOS/qubes-issues/issues/3042 -- 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/e3b8a4cb-6221-4e9d-93f1-0b01bf86c307%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Audio broken in R4.0 rc1 / qvm-run fails
I've used Qubes 3.2 and everythings there worked fine, but now I'm trying R4.0 rc1 and I can't figure out why the sound doesn't work. `qvm-pci` reports 2 Intel Audio Devices (00:03.0 and 00:1b.0), so I've tried to attach them to an base AppVm, such personal and start it with `qvm-run`, but it returns: "Start failed: internal error: libxenlight failed to create new domain 'personal'", while without those audio devices the VM starts without any ptoblems. Related Bug Issue: https://github.com/QubesOS/qubes-issues/issues/3042 -- 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/a741e02a-04eb-4cc3-aad2-0f1c53ff0693%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
I'm trying to build your port, but I,ve actually had to to some changes to
`kernel.spec` because the script exits with an error at line 136:
`%_sourcedir/check-for-config-changes .config.orig .config`.
So, here are my changes.
Original:
117 if [ -f %_sourcedir/config-%{version} ]; then
118cp %_sourcedir/config-%{version} .config
119 else
120cp %_sourcedir/config .config
121 fi
...
130 MAKE_ARGS="$MAKE_ARGS -C %build_src_dir O=$PWD"
131 if test -e %_sourcedir/TOLERATE-UNKNOWN-NEW-CONFIG-OPTIONS; then
132yes '' | make oldconfig $MAKE_ARGS
133 else
134cp .config .config.orig
135make silentoldconfig $MAKE_ARGS < /dev/null
136%_sourcedir/check-for-config-changes .config.orig .config
137rm .config.orig
138 fi
My version:
117 if [ -f %_sourcedir/config-%{version} ]; then
118cp %_sourcedir/config-%{version} .config
119 else
120cp %_sourcedir/config .config
+++cat /proc/config.gz | unzip > .config.current
121 fi
...
130 MAKE_ARGS="$MAKE_ARGS -C %build_src_dir O=$PWD"
131 if test -e %_sourcedir/TOLERATE-UNKNOWN-NEW-CONFIG-OPTIONS; then
132yes '' | make oldconfig $MAKE_ARGS
133 else
134cp .config .config.orig
+++cp .config.current .config
135make silentoldconfig $MAKE_ARGS < /dev/null
---%_sourcedir/check-for-config-changes .config.orig .config
+++%build_src_dir/scripts/kconfig/merge_config.sh .config .config.orig
137rm .config.orig
138 fi
I don't know if this issue is related to my configuration or not, let me know.
--
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/43f8cc63-8b11-41a0-a9fc-a68fc13b4f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Audio broken in 4.0 rc1
I've used Qubes 3.2 and everythings there worked fine, but now I'm trying 4.0 rc1 and I can't figure out why the sound doesn't work. `qvm-pci` reports 2 Intel Audio Devices (00:03.0 and 00:1b.0), so I've tried to attach them to an base AppVm, such personal and start it with `qvm-run`, but it returns: "Start failed: internal error: libxenlight failed to create new domain 'personal'", while without those audio devices the VM starts without any ptoblems. Is there an issue with the rc1, since my hardware is not old and it worked fine with 3.2? -- 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/1e032119-1291-4b27-86e0-811949323358%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Unofficial forward-ported grsec 4.9 Qubes kernel branch
Why the repo can't be cloned without credentials? -- 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/3b475e97-de19-4819-90ad-138ab4ff74ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Kernel and Policies
In the past I've read in the docs about the way to isolate the root account in VMs using PolKit. I was wandering if there is a way to always prompt Dom0 for authorization for some specific operations inside VMs, like a syscall, using policies or better modifying the kernel. -- 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/835b852a-a99c-4510-9ea8-9976043444d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Admin privileges, new APIs and Firewall
With the new Admin APIs is there a way to set up a FirewallVM with an Application Firewall running inside that can pop up dialogs always on top to let the user decide where to accept or not a connection? Problems: 1) Unprivileged VM windows always on top 2) The Firewall VM need to know details about the app trying to connect The second one I think it can be solved by adding the infomations needed in the payload at the SourceVM and than let the FW remove them or by incapsulating the packets in an another IP layer. Do you have some 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/31f91cc8-15eb-4694-a08f-e5b423c8caeb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Nested virtualization
Yeah, currently I'm using LXC Containers inside AppVMs. What do you need exactly? -- 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/aa7a4a1c-0a99-4783-a94d-af04c645e698%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes doesn't support LXC unprivileged containers?
Why it's not possible to set 'kernel.unprivileged_userns_clone' (/proc/sys/kernel/unprivileged_userns_clone) to use LXC unprivileged containers? Qubes Kernel doesn't support it yet or is it possible to recompile the Kenel to add support to this? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/742e4676-77c6-4ee6-9b61-cb0783811569%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Update VM Kernel and Use VM Kernel
Il giorno mercoledì 8 febbraio 2017 00:33:04 UTC-5, nicholas roveda ha scritto: > 3) Compiling the kernel with default configs > > I ran 'make defconfig', then > I ran 'make' and it went all good, > but when I ran 'sudo make install' I encountered some errors, so I remembered > the Qubes Docs and I tried to use DKMS, so > I ran 'sudo dkms autoinstall -k -a amd64', but I didn't see any > output unlike the one showed by the Qubes Docs, so I stopped here. Actually now, when I run 'make install', it reports this: WARNING: missing /lib/modules/4.9.2 Ensure all necessary drivers are built into the linux image! depmod: ERROR: could not open directory /lib/modules/4.9.2: No such file or directory depmod: FATAL: could not search modules: No such file or directory When I run 'dkms autoinstall -k 4.9.2 -a amd64', it reports: Error! Your kernel headers for kernel 4.9.2 cannot be found. Please install the linux-headers-4.9.2 package, or use the --kernelsourcedir option to tell DKMS where it's located The only headers I found were linux-headers-4.9.0-1, so I managed to install the kernel after modify `u2mfn.c` and run which cointened some errors and ran 'sudo dkms autoinstall -k 4.9.0-1 -a amd64', but at boot it says it doesn't find any XEN notes and initramfs crashes at some point -- 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/0113d7ba-d29d-4136-a732-910c449dc600%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Update VM Kernel and Use VM Kernel
Il giorno mercoledì 8 febbraio 2017 00:33:04 UTC-5, nicholas roveda ha scritto: > 3) Compiling the kernel with default configs > > I ran 'make defconfig', then > I ran 'make' and it went all good, > but when I ran 'sudo make install' I encountered some errors, so I remembered > the Qubes Docs and I tried to use DKMS, so > I ran 'sudo dkms autoinstall -k -a amd64', but I didn't see any > output unlike the one showed by the Qubes Docs, so I stopped here. Actually now, when I run 'make install', it reports this: WARNING: missing /lib/modules/4.9.2 Ensure all necessary drivers are built into the linux image! depmod: ERROR: could not open directory /lib/modules/4.9.2: No such file or directory depmod: FATAL: could not search modules: No such file or directory When I run 'dkms autoinstall -k 4.9.2 -a amd64', it reports: Error! Your kernel headers for kernel 4.9.2 cannot be found. Please install the linux-headers-4.9.2 package, or use the --kernelsourcedir option to tell DKMS where it's located The only headers I found were linux-headers-4.9.0-1, so I managed to install the kernel after modify `u2mfn.c` which cointened some errors, but at boot it says it doesn't find any XEN notes and initramfs crashes at some point. -- 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/bb641226-737a-4028-8b5f-62abf5807e8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Update VM Kernel and Use VM Kernel
Il giorno mercoledì 8 febbraio 2017 00:33:04 UTC-5, nicholas roveda ha scritto: > 3) Compiling the kernel with default configs > > I ran 'make defconfig', then > I ran 'make' and it went all good, > but when I ran 'sudo make install' I encountered some errors, so I remembered > the Qubes Docs and I tried to use DKMS, so > I ran 'sudo dkms autoinstall -k -a amd64', but I didn't see any > output unlike the one showed by the Qubes Docs, so I stopped here. Actually now, when I run 'make install', it reports this: WARNING: missing /lib/modules/4.9.2 Ensure all necessary drivers are built into the linux image! depmod: ERROR: could not open directory /lib/modules/4.9.2: No such file or directory depmod: FATAL: could not search modules: No such file or directory When I run 'dkms autoinstall -k 4.9.2 -a amd64', it reports: Error! Your kernel headers for kernel 4.9.2 cannot be found. Please install the linux-headers-4.9.2 package, or use the --kernelsourcedir option to tell DKMS where it's located But linux-headers-4.9.2 is in /usr/src. -- 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/86a19981-bed6-4531-8a6e-3b8ecdb851c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Update VM Kernel and Use VM Kernel
Il giorno mercoledì 8 febbraio 2017 02:45:24 UTC-5, Foppe de Haan ha scritto: > I can't help you with the troubleshooting, but I can tell you that you can > get the 4.8.12 kernel from qubes-dom0-unstable. Yeah, thanks. I need to change the kernel configs, disable some drivers end remove some devices supports, so I need to compile the kernel manually or make a custom package. -- 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/a08309dc-2acf-483f-ad6b-5eb8860772ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
