Re: [qubes-users] Looking to change value of dom0_mem=max, tried finding xen-cmdline but no luck
@awokd: What on earth, so I was almost there already I was looking around grub and grub2 folders in hopes of finding some sort of startup script related to it. Now I feel so dumb hahahahahaha Many Thanks! @Claudia: Thanks for the heads' up. I have set the max memory through xen.cfg for my situation. To be honest, I couldn't comprehend completely the memory allocation in Xen/Qubes article but if I understand it right, what it heavily implies is that dom0 dynamically allocates memory from itself to AppVMs when it sees that there is a need for it. I did observe this behavior to some extent but unfortunately, it doesn't seem to react when an AppVM is in a very near-frozen state due to lack of RAM to use. I have observed this for almost over 5 times already and it sucked. Also, I could observe some minor lag hiccups whenever the browser is starting to completely exhaust the ram available to the AppVM, and that is something I would like to try to avoid. On Friday, November 22, 2019 at 3:27:07 AM UTC+8, awokd wrote: > > Sphere: > > > However, a ram stick just died on me this week and I badly need all the > RAM > > that I could get. Even right now, my dom0 is actively using just about > 940 > > MB worth of RAM... which is why I think it would be best if I could > > permanently allocate 2048M to dom0 instead of 4096M for my case. > > /boot/efi/EFI/qubes/xen.cfg > > -- > - don't top post > Mailing list etiquette: > - trim quoted reply to only relevant portions > - when possible, copy and paste text instead of screenshots > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f91ddd88-e8cf-425a-aa45-90b43e75f738%40googlegroups.com.
Re: [qubes-users] Looking to change value of dom0_mem=max, tried finding xen-cmdline but no luck
Well, I do have a problem with AppVMs completely hanging out on me on situations where firefox demands a large amount of ram and these are such cases: 1. Running a resource-intensive web application i.e. node.js web editors like Wix and Weebly 2. Downloading large files from mega.nz (I think the magic here involves loading the file into the RAM after it has been completely downloaded by the browser which is why when the browser prompts saving the file, the process is almost instantaneous... unless you don't have enough RAM to accommodate the demand. 3. Plenty of media-playing tabs open in Firefox or Chrome There may be other cases that I have forgotten but on all cases where an AppVM froze on me, the total RAM eaten by dom0 hardly ever shrunk for it to be allocated to the AppVM, which should be expected given the existence of https://www.qubes-os.org/doc/qmemman/ I was able to get myself a workaround for the problem before, and that is making more swap, ideally within the 8GB-10GB range. However, a ram stick just died on me this week and I badly need all the RAM that I could get. Even right now, my dom0 is actively using just about 940 MB worth of RAM... which is why I think it would be best if I could permanently allocate 2048M to dom0 instead of 4096M for my case. ...Not unless there are big security-related reasons as to why 4096M has been the default on dom0. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e2856dbf-120b-4044-b3bd-59a7857477dd%40googlegroups.com.
[qubes-users] Re: Running minikube
Minikube is related to kubernetes, which isn't exactly virtualization but rather, containerization. Those two things are different. And you *don't* do VM in a VM, only very special circumstances allow for such a thing Qubes isn't exactly the best option for what you're looking for. If you're looking for an ideal OS for minikube then go for Alpine Linux and as for miniocp, maybe go Proxmox VE or VMWare ESXi? On Thursday, November 14, 2019 at 10:05:01 AM UTC+8, shawn wilson wrote: > > What's the best/documented/misc ideas way to run things like minikube or > miniocp? Just a VM in a VM (they use libvirt to control a VM) or is there a > less clunky mechanism? > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d587bfec-9cf5-4817-9d92-ae0e166b067c%40googlegroups.com.
[qubes-users] Looking to change value of dom0_mem=max, tried finding xen-cmdline but no luck
https://discussions.citrix.com/topic/354913-error-increasing-dom0-memory-in-61/ So I am looking to reduce the max set on dom0_mem because a considerable amount of ram is being wasted (roughly 1500 MB) and I want to use it on my RAM heavy appvms instead I've been searching all over the place for xen configuration stuff but I haven't gotten much luck finding anything that has the parameters that define the values in "xen_commandline" that is shown whenever one types xl info I've tried doing things like "xl mem-set Domain-0 2048M" but it reverts back as soon as I start a new app vm... Anybody know the proper way to do 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7e48ee61-af07-4cf9-94ee-4d889499ac3c%40googlegroups.com.
Re: [qubes-users] TemplateVM updates almost instantly fail when target is VPN qube but dom0 updates run just fine
I see, I hope that really solves your problem cause so far on my side I was able to try a separate qube for updating Templates and dom0 So far so good there were no problems given the fact that I ensured that the qube responsible for being updates proxy to the Templates were resolving DNS queries just fine and updates proxy service actively running properly in that qube. If you still got the problem after switching to debian-10 maybe do some network diagnosis in your update vm? I can lend a helping hand with that if you need it -- 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/ed09218f-0794-4dc0-a28d-6907854de4b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Quick question please, need help!
I'm not particularly knowledgeable about the verification process being done by dnf on the signature of packages so the question still lies on me: Is downloading packages from plaintext http susceptible to MITM? Even if that is not the case, I believe we can't be for sure that there's no exploitable vulnerability on dnf involving packages poisoned either from the source itself or in transit through plaintext http. -- 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/689626e9-dad6-4efa-a615-57add8280147%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0.1 Installation To Emergency
I suggest giving Rufus a shot as well instead of Etcher. Also, you may want to try running Linux mint, openSUSE, or Nitrux OS first to see how tame your system is for Linux. "Gaming" hardware are quite notorious for almost always having trouble running Linux Lastly, I highly suggest for you to update the BIOS firmware of your Razer Blade GTX to the latest version for better chances of Linux compatibility. -- 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/91912cf5-a5c9-4d13-9419-70955fdf43ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: sys-net does not start applications
If it doesn't start any applications try to change the template of sys-net Alternatively, you can try to add more memory/ram using sys-net preferences and see 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/9077d957-cd9b-47b5-96ca-8847a86e9a94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?
You're welcome and good luck! In any case, I was reminded that any sort of communication between non-interconnected qubes are not allowed. So even if both of your AppVM qubes and sys-dns qube are connected to sys-firewall then they won't be able to communicate with each other by default. Additional iptables rules must be added to allow it according to what's written here: https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-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/8795f202-8452-493d-810d-bbaa973282ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Quick question please, need help!
@Jon deps: Proper hardening involves: 1. Proper use of firewall rules using qvm-firewall 2. Reducing the attack surface by only installing what is needed. Refer to usage of debian-minimal and fedora-minimal template in Qubes documentation. 3. Drop INPUT and OUTPUT in sys-net(only do this if you have proper DNS resolving mechanisms in place that are not reliant on sys-net, Qubes is reliant on sys-net for proper DNS resolutions by default. If you're interested then you can start by knowing how to use DNSCrypt proxy made by jedisct1 or using Stubby to make a sys-dns qube to do DNS over TLS resolutions. 4. Implementing the use of a VPN in qubes or highly relying on sys-whonix to torify your connections. 5. Picking only update sources that you could trust. IDK about debian but in fedora, by default, all updates are grabbed from mirrors and alot of those only support http which is bloody insecure thanks to being just plaintext and susceptible to MITM attacks. This can be changed by modifying /etc/yum.repos.d/fedora.repo and fedora-updates.repo If you're interested in doing this then you can search up a thread I made about this here in qubes-users. Just put "Sphere" in search and you will definitely find it among the threads I have made. 6. Frequently updating your qubes after making sure you picked a source of updates that you can really trust. "Since the majority of networks assign the actual IP address to you, you likely won't have much control over that address, and logically the IP address belongs to the network, not you. Chances are that with a different MAC address you will not likely be getting the same IP address each time either, depending of course on how they actually allocate their addresses. " @steve.coleman: I would like to add that IP address allocation from the ISP to you entirely depends on whether they provisioned you a Modem or a Modem + Router combo. For the case of a Modem, you will be allocated a random IP address from a pool of IP addresses the ISP provides on the subnet that you, as a client, was allocated to. Some ISPs do not provide it by random and in the case of statically assigning you an IP address, they use your modem's MAC address and bind it to a specific IP address which effectively becomes your public IP address. This is exactly why VPN is very essential for privacy because any internet activity that does not go through a VPN could effectively be traced back to you by your ISP. Do note that there has been wide confusion that's still happening about Modems and Routers thanks to some devices actually being labelled Modems but in reality they are Modem + Router combos that has a DHCP server which provides you your private IP addresses (Private IP addresses are IP addresses you use to access devices within your local network). -- 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/65c5caa6-2482-48e8-b3a8-362b6864293d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: No vpn-handler-openvpn in service tab
On Tuesday, July 2, 2019 at 5:37:58 AM UTC, Philip Pians wrote: > On Tuesday, July 2, 2019 at 4:36:22 AM UTC, Chris Laprise wrote: > > On 7/1/19 11:18 PM, Philip Pians wrote: > > > On Tuesday, July 2, 2019 at 3:13:56 AM UTC, Philip Pians wrote: > > >> Using instructions to create VPN appvm (with provides network), no > > >> service called vpn-handler-openvpn, or any other with VPN in name under > > >> service tab, nor do any of the other VMs. Tried adding “network > > >> connections” from applications tab, and can select to import a VPN > > >> configuration then can’t proceed to do anything once file is selected > > >> because everything is greyed out. > > >> I’ve looked and looked for help setting up VPN but info seems to be > > >> identical and not address this problem. Please help, if I can’t get past > > >> first step... > > > > > > Edit: Here is instructions I followed: > > > https://github.com/tasket/Qubes-vpn-support > > > https://www.qubes-os.org/doc/vpn/ > > > > You should only follow one of these, not both. I assume you meant the > > first one... > > > > The way to add a new service here is to just type it on the line and > > click the plus sign. > > > > -- > > > > Chris Laprise > > https://github.com/tasket > > https://twitter.com/ttaskett > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > Yes, quite a few threads link to the first one and seems more useful than the > out of date second one. I’m a little embarrassed, thought I need to select > from the drop-down menu… > Now at second step, there’s no such file or directory called vpn in > /rw/config… can I just make this directory? Or is it supposed to exist with > files in it? Usually for those cases you can just make a directory there and the service will start running Note that you have to make this directory in the template VM that your VPN qube is using so that you won't have to do this every single time you start your VPN qube. -- 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/fae0df5f-2c3c-43ee-8cbe-bc7bb096ba9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?
With my experience of using DNSCrypt I actually think that Qubes' has some unique way of handling DNS queries given how the nameservers automatically put into /etc/resolv.conf are on a different subnet. I actually think there must be some sort of bind or unbound being ran in there that resolves all the DNS queries for you by using sys-net or your netvm as a proxy. In order to make a sys-dns qube or to turn any other qube into a sys-dns qube you must ensure that it is listening on port 53 UDP for any DNS queries. This command alone given by Chris should be enough. iptables -I INPUT -p udp --dport 53 -j ACCEPT Afterwards you should change your /etc/resolv.conf to the IP address of your sys-dns qube. The IP address can be found out using Qubes Manager and try to ping that ip address first to verify if it is reachable by your AppVM in the first place. If your sys-dns qube is not your sys-net or netvm then you should ensure that TCP port 853 outbound is allowed through if your firewall rules do not explicitly allow all outbound (all outbound is allowed by default for each qube) (In dom0 terminal) qvm-firewall [sys-firewall or/and sys-dns] add action=accept proto=tcp dstports=853 --before 0 If this doesn't solve it then it may be best to provide us with some logs of your stubby -- 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/24d42a1d-b5cc-4d92-9aed-a5f209b1195a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes - Critique (long)
About corruption and reliability of data being stored, regardless of whether or not it is sensitive data or day to day files, is not entirely the responsibility of the Qubes OS itself. There are many factors to consider, the software being used, the filesystem being used, the components of the distro being used, and etc. This is based on my personal experience on using qubes on a daily basis for almost over a year already. So far I've only encountered corruption of data through the use of qvm-copy/qvm-move commands to move stuff from vm to vm and this is a rare case too since it probably only happens once or twice over a hundred times. With this in mind, the LVM thin fs of Qubes I believe, is extremely reliable. So with that I believe the problem most likely leans more towards the software that you are using, with respect to the distro that you are using as well. I haven't had much trouble using any software so far in my experience of using qubes provided they have the right dependencies installed, with respect to my usage of fedora minimal template. Despite that however, I agree with your sentiment about USB devices and the detaching notification though I am not entirely dependent on it since I can go ahead and confirm myself whether or not the usb device was detached by running "sudo lsblk" on the qube where the USB was attached and on the sys-usb qube itself. Convenience-wise, it is bad yes and there is definitely room for improvement. Also mind you that flash is a HUGE BLOB of SECURITY RISK. If you're using qubes for security reasons then using flash is really counterproductive against it not unless you really know what you're doing. -- 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/94143ecf-7500-41e0-8d9b-ab6f154dad02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] TemplateVM updates almost instantly fail when target is VPN qube but dom0 updates run just fine
On Thursday, June 27, 2019 at 11:44:51 AM UTC, unman wrote: > On Wed, Jun 26, 2019 at 10:12:40PM -0700, Sphere wrote: > > @unman: thanks for that > > I also noticed that qubes-updates-proxy.service fails by default on startup > > and I'm unsure if that is a minimal template-only problem but I was able to > > fix it thanks to it indicating that the problem is a missing folder: > > /var/run/qubes-service/qubes-updates-proxy > > > > Pretty much the same problem that I get with clocksync service thankfully > > so I was able to confirm that this service was running as intended > > > > systemctl status qubes-updates-proxy: > > qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) > >Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; > > enabled; > > vendor preset: enabled) > >Active: active (running) since Thu 2019-06-27 12:06:14 +08; 2s ago > > Process: 1603 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start > > (code=e > > xited, status=0/SUCCESS) > > Main PID: 1608 (tinyproxy) > > Tasks: 3 (limit: 414) > >Memory: 4.1M > >CGroup: /system.slice/qubes-updates-proxy.service > >??1608 /usr/bin/tinyproxy -d -c > > /etc/tinyproxy/tinyproxy-updates.conf > >??1609 /usr/bin/tinyproxy -d -c > > /etc/tinyproxy/tinyproxy-updates.conf > >??1610 /usr/bin/tinyproxy -d -c > > /etc/tinyproxy/tinyproxy-updates.conf > > > > Jun 27 12:06:14 redacted systemd[1]: Starting Qubes updates proxy > > (tinyproxy)... > > Jun 27 12:06:14 redacted systemd[1]: Started Qubes updates proxy > > (tinyproxy). > > Jun 27 12:06:14 redacted tinyproxy-wrapper[1608]: Found tinyproxy at > > /usr/bin/tinyproxy > > > > Despite this however, the problem still persists and still behaves the same > > even after trying dnf update for 5 times > > > > I think is right about the fact that there is a bug about this > > > > @Chris I think you may be right about the fact that this is a bug and I > > guess it's time to escalate it into an issue in github. I'm willing to lend > > a helping hand in making the issue as needed. > > > > My setup is all fully dependent on variations of fedora-30-minimal template > > that I have tailored depending on use-case of the AppVM that would be using > > it. > > > > Like Chris, I use a separate qube for updates. > Unlike you and Chris I don't see the behaviour you report. > > Let's try to dig in before raising a bug report. > > I've tested this with 30-minimal template 201905071541 and 201906241949, > from stable and testing. > I've tested against dom0 stable and dom0 testing: both fully updated. > Test boxes are an old x230 and a custom rig with X-series CPU and 32G RAM. > > In all cases, the proxy is started as appropriate, and the update > process (from fedora 29 and 30-minimal) waits until proxy is up and then > proceeds. > > What hardware are you, Sphere and Chris, running? > > Sphere - if you create a dedicated update qube using the 30-minimal with > qubes-core-agent-networking installed, > enable the qubes-updates-proxy service, route it through > sys-firewall, and edit the policy file appropriately, do you see the > same behaviour? (Almost instant fail) > What if you start the new update proxy before attempting a 'dnf update'? > > unman Big update: I was able to solve the problem What I essentially did: 1. Ensure to run the Update Qube first 2. Confirm and ensure that the qubes-updates-proxy is already running after the qube is started. qubes-updates-proxy was listed and set as checked in the services tab of Qubes Settings GUI before starting the update qube. checking was done through the `systemctl status qubes-updates-proxy` command. 3. Ensure that qubes.UpdatesProxy policy file is configured correctly before starting the templateVM 4. Ensure that DNS queries are resolving in the update qube 5. Start the templateVM and try to do a dnf update One big thing to note here is that I encountered the problem after step 4 and was able to solve it by ensuring that my update qube is able to properly resolve DNS queries but I have to say that what's unique in my situation is that I use DNSCrypt for resolving DNS queries. So basically, the problem was solved after I ran DNSCrypt on the update qube. Admittedly that was kinda dumb on my part to not realize that the f30 template definitely needs to have DNS resolutions to do updating along with that fact that I have already blocked all plaintext DNS from going out. However, I can't quite remember whether or not I had DNSCrypt running on the update qube last time I teste
[qubes-users] Re: Quick question please, need help!
The general idea is correct If dom0 gets pwned then everything else can be pwned and stolen, including your data pwning dom0 properly and successfully however, is not trivial because dom0 has no direct access to network hardware to communicate in the first place and malicious actors would need malware to communicate directly to the C2 server for commands. What's great about qubes is the fact that with proper hardening, it becomes very resilient thanks to the fact that it follows a 0-trust model. -- 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/9ce9472f-8c36-44c8-b513-424c591f2b63%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: no DNS resolving being passed to sys-firewall or other appVMs after updates?
On Wednesday, June 26, 2019 at 4:34:11 PM UTC, cubit wrote: > I am not sure if this is related to recent updates but after updating today > and doing a reboot, my sys-firewall and other appVMs are not getting DNS > resolving working. > > > > - sys-net (fedora30) starts up with out an issue, can resolve and connect to > the internet > > - sys-firewall starts up and gets an IP address, it can ping sys-net and > hosts on the internet by IP but can not by name. > > - appVMs are the same as sys-firewall > > > > on sys-firewall and appVMs I have two entries in /etc/resolv.conf 10.139.1.1 > and .2 I am not sure what these IPs are as they do not show up in qubes > manager and I can not ping them. > > > > IPs all start at 10.139.0.5 which is sys-net > > > > The only way I can get to the internet is to use Tor or VPN which don't rely > on the system DNS. > > > > Is anyone else experiencing this, does anyone know what 1.1 and 1.2 hosts > are or how I can get DNS up and running again? > > > > cubit Well I don't have much of a solution to solving your DNS problem other than checking if your DNS queries are resolving in your sys-net vm through the use of nslookup command. An alternative would be using DNSCrypt https://github.com/jedisct1/dnscrypt-proxy/releases Using this properly needs to have you change the contents of your /etc/resolv.conf to the following: nameserver 127.0.0.1 options edns0 single-request-reopen -- 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/dda05552-344a-4baa-a2f0-8da76693f6bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] TemplateVM updates almost instantly fail when target is VPN qube but dom0 updates run just fine
@unman: thanks for that I also noticed that qubes-updates-proxy.service fails by default on startup and I'm unsure if that is a minimal template-only problem but I was able to fix it thanks to it indicating that the problem is a missing folder: /var/run/qubes-service/qubes-updates-proxy Pretty much the same problem that I get with clocksync service thankfully so I was able to confirm that this service was running as intended systemctl status qubes-updates-proxy: qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-06-27 12:06:14 +08; 2s ago Process: 1603 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=e xited, status=0/SUCCESS) Main PID: 1608 (tinyproxy) Tasks: 3 (limit: 414) Memory: 4.1M CGroup: /system.slice/qubes-updates-proxy.service ├─1608 /usr/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf ├─1609 /usr/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf └─1610 /usr/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf Jun 27 12:06:14 redacted systemd[1]: Starting Qubes updates proxy (tinyproxy)... Jun 27 12:06:14 redacted systemd[1]: Started Qubes updates proxy (tinyproxy). Jun 27 12:06:14 redacted tinyproxy-wrapper[1608]: Found tinyproxy at /usr/bin/tinyproxy Despite this however, the problem still persists and still behaves the same even after trying dnf update for 5 times I think is right about the fact that there is a bug about this @Chris I think you may be right about the fact that this is a bug and I guess it's time to escalate it into an issue in github. I'm willing to lend a helping hand in making the issue as needed. My setup is all fully dependent on variations of fedora-30-minimal template that I have tailored depending on use-case of the AppVM that would be using it. -- 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/56db9edd-8442-4a7c-a46b-30b9ca97c1cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes: Encrypted LVM
By all means hold your horses on asking if Qubes is vulnerable to every single one of those lol I used to be paranoid about Computer Security but if you ain't even gonna bother to delve deep down from how computers work up to the way computer applications/programs work then you should just focus on what you can actually do as a user to strengthen your privacy. If your biggest concern is trusting your hardware then the best thing you can do is to buy Hardware that respects your privacy and install hardened linux/bsd into it and never use Windows 10 ever again. https://www.bleepingcomputer.com/news/hardware/there-are-only-25-devices-that-respect-your-privacy/ Or if you want an easy life just do away with this: https://puri.sm/products/librem-15/ Only thing left to do with that is to harden it and install your privacy goodies -- 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/e80c2e06-1904-483b-8247-b74c3df40413%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] TemplateVM updates almost instantly fail when target is VPN qube but dom0 updates run just fine
@unman The dom0 updates setting is set correctly and working as intended through the VPN qube, I haven't tried browsing from the VPN qube itself but I can definitely browse from an AppVM connected to it and I can confirm that all the browsing being done there is tunneled through the VPN. I'm using a fedora minimal and I don't see any sort of package requirement for a qube to install to provide TemplateVM updates as I read through the Fedora Minimal documentation. Only thing that has a requirement from the looks of it is a qube for dom0 updates. Thanks for the suggestion about updateProxy service. I suppose I should set it to provide qubes-yum-proxy, is that right? @Chris Thank you for telling me that as I too am using fedora-30, specifically fedora-30-minimal Templates I am trying to do a setup where a qube is dedicated for the purpose of updating, something similar to yours I believe. I'll try to work on this tomorrow and report results back to this topic. -- 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/7623ccd5-9a7d-4bed-b331-b54a6008aa5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] TemplateVM updates almost instantly fail when target is VPN qube but dom0 updates run just fine
/etc/qubes-rpc/policy/qubes-UpdatesProxy $type:TemplateVM $default allow,target=VPN As soon as I execute a sudo dnf update to my template VM, it takes a little less than a second for it to go "Failed to synchronize cache for repo 'updates'" "Error: Failed to synchronize cache for repo 'updates'" dom0 updates isn't suffering from this which is why I don't really get what the problem is. At first I thought it's the custom resolv.conf being used for dnscrypt-proxy but that doesn't seem to be the case after trying to use the dns server of the vpn itself Web browsing and everything else is working as intended through the VPN qube and only TemplatVM updates are failing. I don't think there is a problem with what I set on /etc/qubes-rpc/policy/qubes-UpdatesProxy But I don't really face this problem when the target is set to the net VM. That however is no good since I'm looking to utilize the VPN for Template updating. Is TemplateVM updating dependent on whether or not net VM is capable of connecting to the internet and domain name resolutions? -- 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/919df0ac-c1a5-4da7-912b-fcd55249873f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Looking to explicitly not use mirrors to download fedora updates
Welp I guess it really won't work since there's really nothing but README.md left within the folders for deprecated Fedora release versions. Thanks for your reply 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/f45209e4-b4b1-49ad-a03f-9c55dd5f1cbc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking to explicitly not use mirrors to download fedora updates
I apologize for not clearing that out. Uhh, it's that just my machine in particular or maybe at least on the internet that my machine is using, it prefers to use the ftp.riken.jp mirror and it doesn't seem to dynamically change. So far so good, everything has been working nicely on my cloned templates but for some reason it doesn't work on dom0 updates and it ends up with "Failed to synchronize cache for repo 'fedora', 'updates' Here is what's in my repo file: [fedora] name=Fedora 25 - x86_64 failovermethod=priority baseurl=https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/25/Everything/x86_64/os/ enabled=1 enablegroups=0 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary [updates] entry is almost exactly the same just minorly different string on baseurl but still on the same domain of download-ib01.fedoraproject.org Does sudo qubes-dom0-update do something special in particular? I really have no idea why it fails as Qubes repo synchronizes just 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/1b0e6466-44b2-4ac0-bf13-6bdcbeaf8c6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Looking to explicitly not use mirrors to download fedora updates
Tried things on an AppVM turned fedora.repo and fedora-updates.repo on /etc/yum.repos.d/ into just the following content: [fedora] name=Fedora baseurl=https://download-ib01.fedoraproject.org/pub/fedora-secondary It did execute update well somehow just that IDK why it's still probing Fedora Modular when there's only just that on both fedora.repo and fedora-updates.repo Is there another directory/file that I'm missing here? Looking to do this for dom0 too hopefully to get updates directly from Red Hat officially hosted infrastructure -- 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/0a214128-c292-4f2d-9b3d-e8a48159b004%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Looking to explicitly not use mirrors to download fedora updates
Hi, I checked DNS queries being made as I was updating templateVMs today and I noticed that there is an extreme bias preference of using ftp.riken.jp which didn't sit well with me since that would mean that it was downloading updates in plaintext and thus, unprotected against MITM attacks. While I know that dnf has a verification system in place, I do not want to completely depend on it. With that, I've done some research about it which led me to this: https://askbot.fedoraproject.org/en/question/7960/how-to-choose-a-specific-mirror-source/ I noticed that on both fedora.repo and fedora-updates.repo, the baseurl is commented out and metalink is definitely the one being used. So I'm thinking that maybe it's enough to just comment out metalink and settle with the baseurl. Would this be enough for what I need to get done or am I missing something? Also, if you guys have suggestions for a mirror to trust then I would be willing to take you up on those -- 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/44d7f216-638d-4a64-9ecd-e44823ce9d77%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Outline - your own OpenVPN server without logs
Well for starters, Outline doesn't really use VPN but is just using proxy technology, specifically Shadowsocks. So using it with Qubes VPN is kinda well, just partial security? It only affects TCP connections but not everything else so it's not really a "VPN". -- 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/1b13a6ca-13cc-4591-88d4-db2ced3e5a83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNF will only download packages for the transaction
My bad for not indicating that. The problem is that it only downloads it and stops exactly after that and doesn't even start installing the updates. -- 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/11c6b637-95e0-454f-8a6b-bf687c9cc601%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] DNF will only download packages for the transaction
This has annoyed me for the second time and IDK what to do about it anymore. Got a workaround for this before with sudo dnf reinstall suggested by someone on a thread I created back then but yeah it's back after I just did a sudo qubes-dom0-update --clean Seems the workaround doesn't work for kernel-qubes-vm and I haven't tried for kernel but I assume it may be the same case. Could anyone 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/330a5f1a-4e0a-4b94-96fa-0c1d780d4438%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Error: Unable to find a match for fedora-30/fedora-30-minimal (yet again for new templates)
I'll mark this as complete later in hopes of maybe getting a solution to the "DNF will only download packages for the transaction". -- 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/58e7a70d-4595-42a1-b0ca-06d51f71338b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Error: Unable to find a match for fedora-30/fedora-30-minimal (yet again for new templates)
Interesting, this is the first time I am told about that It downloaded newly released versions of kernel-qubes-vm and kernel but sadly it's yet another annoying "DNF will only download packages for the transaction." I got this problem too before and was worked-around with a sudo dnf reinstall [package] but unfortunately it doesn't seem to work for kernel and kernel-qubes-vm Thankfully that solved the problem of not being able to find a match for fedora-30. Cheers! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d0460964-ea92-450b-8dcb-a343002e1e7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4 system requirements; AMD compatibility?
I haven't personally tried this but I am highly confident that Qubes will definitely work on an ASRock X370 Taichi https://www.asrock.com/mb/AMD/X370%20Taichi/ It's the motherboard out there that has aced being able to do GPU Passthrough on a Windows Guest VM on a Linux Host so all in all it's very reliable for Qubes' many VM requirements and has done very well to reliably run various linux distros just by me reading through alot of pages/articles about doing GPU passthrough in linux All in all, it's really worth the try and even if it doesn't work on qubes then maybe it will work on considerable alternatives like Subgraph OS. https://subgraph.com/ There's X470 and X570 out already but I'm not sure how it fares with Qubes OS given that there's alot of new stuff going on in there right now that may not be compatible or working well with Linux. -- 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/5a4c9c93-d801-4bde-aac6-25fc3cb2aad0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: New advanced linux trojan/rootkit just discovered, servers still active
This one shouldn't be a problem so long as dom0 is not compromised. Also nice that we can just block 103.206.123[.]13 and 103.206.122[.]245 Also, this thing doesn't even survive a reformat so yeah nothing much to worry about (not unless they also aim to persist in your routers and other network devices). -- 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/de0cda3a-3316-4f44-80a0-6c9931ae02b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Bootloop
That's not a bootloop, it's simply that you are stuck at the phase where you have to unlock the drive's encryption If you can't get past that then maybe there's a problem with your keyboard? Reinstall qubes and put an easy/short encryption pass first then maybe the problem resides with your keyboard. I've never encountered this problem before the feedback I can give is pretty limited but I stick with the usual default keyboard layout. -- 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/07787a84-eebe-4920-87de-98e9f71c18bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Openbsd as a netvm
On Tuesday, June 4, 2019 at 12:44:46 AM UTC+8, ronpunz wrote: > On 6/3/19 12:10 PM, unman wrote: > > On Mon, Jun 03, 2019 at 09:28:01AM +, ronpunz wrote: > >> On 6/3/19 12:54 AM, unman wrote: > >>> On Sun, Jun 02, 2019 at 06:24:33PM +, ronpunz wrote: > On 6/2/19 3:11 PM, unman wrote: > > On Sun, Jun 02, 2019 at 02:04:57PM +, ronpunz wrote: > >> On 6/2/19 1:46 PM, unman wrote: > >>> On Sun, Jun 02, 2019 at 01:41:48PM +, ronpunz wrote: > On 6/2/19 1:06 AM, unman wrote: > >> Not sure which direction to go next and to be honest, feel a bit > >> out of my > >> depth. When I started this task I thought there was a simple > >> correlation > >> between openFW to sys-net and fw to sys-firewall. In reality it > >> seems a > >> fair bit more complicated than that. For example, fw seems to have > >> a dual > >> firewall and network interface role? > >> > > I dont understand what this means. > > There is simple correlation as you describe, it's just that fw > > needs to > > do a little more work to provide the internal interface to the HVM. > > > > What error do you get when you bring up em0? > > What's the output from ifconfig? > > > I note the ifconfig screen shots were missed off my reply. > > They should be here > > >>> I'm sorry - can you cut and paste the contents rather than imaging? > >> Copy/paste as requested > >> > > ?? > > I cant see the images - paste the contents in the mail. > > > Sorry. I'm a bit confused. I pasted them in the mail and they're > viewable on > the qubes user forum at > https://groups.google.com/forum/#!topic/qubes-users/MpXLhz5COvM > > Please let me know if there's more i can do > > >>> I cant view them. > >>> Please post the contents, not pictures. > >>> > >> Gotcha. However, that's easier said than done. After trying and failed > >> using > >> various OCR software. To cut a long story short, I've ended up typing the > >> whole thing out as follows: > >> > >> joo# ifconfig > >> lo0: flags=8049 mtu 32768 > >> index 5 priortity 0 llprio 3 > >> groups: lo > >> ininet6 :: 1 prefixlen 128 > >> inet6 fe80 ::1%lo0 prefixlen 64 scopeid 0x5 > >> inet 127.0.0.1 netmask 0xff00 > >> xnf0: flags=8843 mtu 1500 > >> lladdr 00:16:3e:5e:6c:00 > >> index 1 priortity 0 llprio 3 > >> media: ethernet manual > >> status: active > >> inet: 10.137.0.10 netmask 0xff00 broadcast 10.255.255.255 > >> re0: flags =8802 mtu 1500 > >> lladdr 1c:1b:0d:a4:1e:e4 > >> index 2 priortity 0 llprio 3 > >> media: ethernet autoselect (none) > >> status: no carrier > >> em0: flags=8843 mtu 1500 > >> lladr 68:05:ca:55:75:6f > >> index 3 priortity 0 llprio 3 > >> groups: egress > >> media: ethernet autoselect 1000baseT > >> (full-duplex,master.rxpause,txpause) > >> status: active > >> enc0: flags=0<> > >> index 4 priortity 0 llprio 3 > >> groups: enc > >> status: active > >> pflog0: flags=141 mtu 33136 > >> index 6 priortity 0 llprio 3 > >> groups: pflog > >> > >> I'm now able to successfully ping 8.8.8.8 but not google.com. Indicating a > >> dns issue? > >> > >> The dns setting in pf is iptables -t nat -I PR-QBS -p udp --dport 53 -j > >> DNAT > >> --to 9.9.9.9 > > I'm sorry for the pain in doing this - you could always have booted the > > openBSD qube with a USB attached, and transferred the files that way. > > Like a sneakernet but smaller scale - a fingernet? > > > > You dont say *from where* you are able to ping. Yes, this looks like a > > DNS issue. > > > > If you want to get this working from the BSD qube, then check > > /etc/resolv.conf > > This isn't necessary - in fact you may prefer NOT to allow outgoing > > traffic originating from the openBSD firewall. > > > > You say that rule you have is "in pf" - do you mean "in fw"?? It's just > > not a pf thing. > > So if it *is* in fw, and you are able to ping from fw, then this is looking > > good. > > Simplest way to proceed is to set /etc/resolv.conf in fw to use 9.9.9.9 > > > > Give just a little more detail on what's working and from where. > > > Update > > I've noticed that the contents of fwVM's /etc/resolv.conf does not > survive a reboot. The file contents revert to default values: > "nameserver 10.137.0.1 nameserver 10.137.3.254" > > I hope this helps debuging That's normal, apparently that happens every single time an AppVM starts up even if you personally changed the value in the TemplateVM itself. Trust me, that's part of my frustrations back then lol. Could you try having another AppVM running and connected to your Openbsd netvm and see if you can
[qubes-users] Error: Unable to find a match for fedora-30/fedora-30-minimal (yet again for new templates)
Hi, I have no idea why I'm experiencing the same old problem with the new fedora-30 templates. I was able to successfully install fedora-29-minimal when I had the first instance of this problem so I thought that the problem may be residing on the repositories but with this happening then maybe there's more to it than just that. I've already tried doing sudo dnf clean all to no avail but sadly it doesn't solve the problem. -- 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/96c5d9e8-426a-4fbc-b872-b93f808e9bd9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Announcement: Fedora 30 TemplateVM available
Thank you very much for the timely wonderful update qubes team! -- 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/3c5366a3-26f7-4595-a284-714ef672ec5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Openbsd as a netvm
I think what unman means is for you to provide the logs in text and not just provide images to help diagnose this problem -- 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/51f90c16-e24f-4154-a9c7-11a7e4820e28%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Fixing support for H.264/MSE & H.264 playback on firefox in Fedora-29
On Monday, May 6, 2019 at 11:38:19 PM UTC+8, Sergio Matta wrote: > > Does anyone know which specific packages need to be installed > > Try this info: > > https://forums.fedoraforum.org/showthread.php?317721-fedora-28-and-firefox-video(h264-youtube-gstreamer1) Thank you very much for that reference! Thankfully I have tested all steps that I've done before on an AppVM so the unneeded stuff that I downloaded didn't remain. The latter replies on the thread has the solid solution of doing sudo dnf install compat-ffmpeg28 Which amazingly completed playback support on youtube Also appreciate the fact that the thread mentioned dependencies needed to play twitter videos. Cheers! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e2d4c7a9-1a20-446f-a828-ed90e76906fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Fixing support for H.264/MSE & H.264 playback on firefox in Fedora-29
On Monday, May 6, 2019 at 12:24:12 PM UTC+8, Sphere wrote: > I've been trying to figure this out for days but to no avail, I couldn't > really make it work. I do my checking by visiting https://youtube.com/html5 > > Did all sorts of searching and stuff. Some suggested installing vlc but > apparently it doesn't seem to exist on the repositories of qubes fedora > > The seemingly best possible solution I found was from > https://rpmfusion.org/Configuration > > Where I did a > sudo dnf groupupdate multimedia > > Much to my dismay, it still didn't solve this problem. D: > > So I'm here in hopes that someone out there may have been able to make this > work on an appVM based on fedora-29 qubes template. Sincerely hoping there is > someone OTL > > You could probably say that the easiest way to solve my problems would be to > install/use google-chrome or any chromium-based web browsers instead but that > doesn't sit well with me because I don't really like the idea of going with > the flow and becoming entirely dependent on google/google-chrome/chromium. > > Which is why I'm dead set on finding a solution to this. Oh silly me, I did not even do research on Qubes documentation nor even a search on this place. Found some hope at https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-11 And performed the following commands: sudo dnf config-manager --set-enabled rpmfusion-free rpmfusion-nonfree sudo dnf upgrade --refresh However, I still can't figure out the exact codec/s dependency to completely support it. I did tried installing the following little-by-little but in the end, my firefox still can't play H.264 stuff gstreamer1 gstreamer1-plugins-good gstreamer1-plugins-ugly gstreamer1-plugins-ugly-free gstreamer1-plugins-bad-nonfree gstreamer1-plugins-bad-free As a last resort, I resulted to installing vlc and my firefox can now magically play it. Bad thing is that installing vlc installs a HUGE bunch of stuffs and I don't even use vlc for playing media. Does anyone know which specific packages need to be installed? -- 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/50f8b9a2-e55c-4dc7-a0dc-7b4d37255eeb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Fixing support for H.264/MSE & H.264 playback on firefox in Fedora-29
I've been trying to figure this out for days but to no avail, I couldn't really make it work. I do my checking by visiting https://youtube.com/html5 Did all sorts of searching and stuff. Some suggested installing vlc but apparently it doesn't seem to exist on the repositories of qubes fedora The seemingly best possible solution I found was from https://rpmfusion.org/Configuration Where I did a sudo dnf groupupdate multimedia Much to my dismay, it still didn't solve this problem. D: So I'm here in hopes that someone out there may have been able to make this work on an appVM based on fedora-29 qubes template. Sincerely hoping there is someone OTL You could probably say that the easiest way to solve my problems would be to install/use google-chrome or any chromium-based web browsers instead but that doesn't sit well with me because I don't really like the idea of going with the flow and becoming entirely dependent on google/google-chrome/chromium. Which is why I'm dead set on finding a solution 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/5e91db2d-a44a-4f7d-b45b-bcefc81369ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Looking to edit rules.ml of my mirage-firewall VM but since I cannot run shell, IDK what to do
On Thursday, April 11, 2019 at 8:02:33 PM UTC+8, Thomas Leonard wrote:
> On Thursday, April 11, 2019 at 4:16:17 AM UTC+1, Sphere wrote:
> > @unman Thanks for the clarification. I suppose I misunderstood it wrong
> > since I thought you have to set it directly using some sort of text editor
> > and be done with it. So I'll have to recompile it I see, welp guess I have
> > no choice but go through with that haha
> >
> > On Thursday, April 11, 2019 at 3:16:32 AM UTC+8, 799 wrote:
> > > Hello,
> > >
> > >
> > >
> > > Thomas Leonard schrieb am Mi., 10. Apr. 2019, 20:42:
> > > (...)
> > >
> > > To change the rules, you edit rules.ml, rebuild and redeploy (this should
> > > only take a couple of seconds after the first build).
> > >
> > >
> > > (...)
> > >
> > >
> > >
> > > Can you or someone from the mirage fw for Qubes team give some examples
> > > how to write rules for mirage?
> > >
> > >
> > > Examples:
> > >
> > >
> > > 1) can access via ssh
> > > 2) can reach using via TCP
> > > 3) Block access from to
> > >
> > > I think some example rules will make it easier to understand how to write
> > > rules.
>
> I've added some examples at
> https://github.com/mirage/qubes-mirage-firewall/pull/54 (see the changes to
> rules.ml).
>
> Actually, matching on individual machines was a bit ugly, so I also made some
> changes to let you name all the machines you want to refer at the start of
> the rules file. You'll need those changes too for the new examples to work.
>
> > > Regarding rebuilding and redployment:
> > > Maybe we can write a small script that will do the following:
> > >
> > >
> > > - launch mirage build VM
> > > - apply changes to rules.ml
> > > - rebuild
> > > - copy new kernel files back to dom0
> > > - shutdown mirage build VM
> > > - restart mirage firewall proxyVM
>
> See:
> https://github.com/mirage/qubes-mirage-firewall/#easy-deployment-for-developers
>
> e.g. I build and deploy the firewall from my dev VM with:
>
> [dev]$ make && test-mirage qubes_firewall.xen mirage-firewall
>
> It does what you describe, and also tails the log file so you can see it from
> the build VM. The process is triggered from the build VM rather than from
> dom0 because working in dom0 is risky. There is a policy so that only the
> builder VM can push the kernel, and only the mirage-firewall kernel can be
> updated.
>
> Note that the instructions for test-mirage show how to set up a "mirage-test"
> unikernel. You'll need to use "mirage-firewall" as the name instead.
>
> > I second this idea. I'm having a hard time myself trying to absorb the very
> > raw instructions of making rules in the rules.ml
> >
> > While the added convenience expands the surface of attack by a bit, I think
> > this can be very useful in environments where you have to frequently
> > interact with firewall rules.
> >
> > Also got questions about makings rules in rules.ml
> >
> > let from_client = function
> > | { dst = (`External _ | `NetVM) } -> `NAT
> > | { dst = `Client_gateway; proto = `UDP { dport = 53 } } -> `NAT_to
> > (`NetVM, 53)
> > | { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet
> > addressed to firewall itself"
> > | { dst = `Client _ } -> `Drop "prevent communication between client VMs"
> >
> > Does `NAT_to (`NetVM, 53) mean that NAT will be applied to the outgoing
> > packet then NetVM itself will process the DNS Query within its own VM
> > context? If this is right, then configuring a wrong DNS server within NetVM
> > would essentially mean DNS resolutions will fail right?
>
> Yes. Client AppVMs are by default configured to use the firewall as their DNS
> (check your /etc/resolv.conf). The firewall then just forwards these requests
> to sys-net.
>
> > Or is this because the rule { dst = `Client_gateway; proto = `UDP { dport =
> > 53 } } -> `NAT_to (`NetVM, 53) is intended for internal DNS resolutions?
> > (From my own understanding, that seems to be the case but I'd like to be
> > corrected if this rule really is for internet DNS resolutions)
> >
> > Moving forward, if I have no lapses in understanding the guidelines in
> > making rules, then this must be the ruleset for allowing only outgoing
> > traffic towards port 25, 110,
Re: [qubes-users] qubes-mirage-firewall 0.5
I have been briefly reminded that technology is not some magic bullet where you just fire and forget. Thank you for 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/977cc4bb-868b-43ff-b044-fe8ffb3a7238%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Looking to edit rules.ml of my mirage-firewall VM but since I cannot run shell, IDK what to do
@unman Thanks for the clarification. I suppose I misunderstood it wrong since I
thought you have to set it directly using some sort of text editor and be done
with it. So I'll have to recompile it I see, welp guess I have no choice but go
through with that haha
On Thursday, April 11, 2019 at 3:16:32 AM UTC+8, 799 wrote:
> Hello,
>
>
>
> Thomas Leonard schrieb am Mi., 10. Apr. 2019, 20:42:
> (...)
>
> To change the rules, you edit rules.ml, rebuild and redeploy (this should
> only take a couple of seconds after the first build).
>
>
> (...)
>
>
>
> Can you or someone from the mirage fw for Qubes team give some examples how
> to write rules for mirage?
>
>
> Examples:
>
>
> 1) can access via ssh
> 2) can reach using via TCP
> 3) Block access from to
>
>
> I think some example rules will make it easier to understand how to write
> rules.
>
>
> Regarding rebuilding and redployment:
> Maybe we can write a small script that will do the following:
>
>
> - launch mirage build VM
> - apply changes to rules.ml
> - rebuild
> - copy new kernel files back to dom0
> - shutdown mirage build VM
> - restart mirage firewall proxyVM
>
>
> The easiest procedure would be to keep the rules.ml in dom0, edit it there
> and then qvm-copy or qvm-run --pass-io cat ... it to the mirage build VM.
>
>
> -O/799
I second this idea. I'm having a hard time myself trying to absorb the very raw
instructions of making rules in the rules.ml
While the added convenience expands the surface of attack by a bit, I think
this can be very useful in environments where you have to frequently interact
with firewall rules.
Also got questions about makings rules in rules.ml
let from_client = function
| { dst = (`External _ | `NetVM) } -> `NAT
| { dst = `Client_gateway; proto = `UDP { dport = 53 } } -> `NAT_to (`NetVM,
53)
| { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet addressed
to firewall itself"
| { dst = `Client _ } -> `Drop "prevent communication between client VMs"
Does `NAT_to (`NetVM, 53) mean that NAT will be applied to the outgoing packet
then NetVM itself will process the DNS Query within its own VM context? If this
is right, then configuring a wrong DNS server within NetVM would essentially
mean DNS resolutions will fail right?
Or is this because the rule { dst = `Client_gateway; proto = `UDP { dport = 53
} } -> `NAT_to (`NetVM, 53) is intended for internal DNS resolutions? (From my
own understanding, that seems to be the case but I'd like to be corrected if
this rule really is for internet DNS resolutions)
Moving forward, if I have no lapses in understanding the guidelines in making
rules, then this must be the ruleset for allowing only outgoing traffic towards
port 25, 110, and 143:
let from_client = function
| { dst = (`External _ | `NetVM); proto = `TCP { dport = 25, 110, 143 } } ->
`NAT
| { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet addressed
to firewall itself"
| { dst = `Client _ } -> `Drop "prevent communication between client VMs"
I also want to know why there is an underscore in front of `External and `Client
--
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/8a16ee49-6cd8-4506-864b-4c6e9683e152%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Looking to edit rules.ml of my mirage-firewall VM but since I cannot run shell, IDK what to do
So I have now also boarded the mirage-firewall VM hype to replace sys-firewall in order to take advantage of the very nice small memory consumption of just 32 MB After searching around I literally failed to find anything that could help me know how I'm gonna edit rules.ml in the mirage-firewall VM The VM as it is right now is running on fedora-29 and trying to launch gnome-terminal/xterm in the VM using qvm-run returns with the error code that I usually get when it doesn't recognize the command/command does not exist in the VM at all May I ask for any leads in getting through 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/cdb1fe4b-33a4-48ef-8900-1940a41fe5af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it just my machine or sys-net vm by default, has an INPUT accept iptables rule for port 8082?
So I tried removing the rule today and attempted to do a templateVM Update Oddly enough it updates just fine and my setting on qubes-rpc for TemplateVM updates is set as my sys-net vm Not unless this is because I have already done an update without removing the iptables rule first which caused a complete sync of repository metadata Thus, when I removed the rule and did an update again, there were no problems because metadata has already been sync'd. Or do you think this hypothesis is wrong? On Monday, April 8, 2019 at 8:16:21 PM UTC+8, unman wrote: > On Mon, Apr 08, 2019 at 01:35:45PM +1000, haaber wrote: > > > So I was doing some security checks on a whim in my Qubes machine until I > > > stumbled upon discovery that my the INPUT chain of iptables in my net VM > > > has a rule of accepting all tcp connections to port 8082 coming from > > > anywhere > > > > I checked and confirm the same line in my sys-net: > > > > -A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT > > > > I cannot offer insightful help at the moment. To permanently change the > > iptables, you might find clues in the qubes-firewall documentation. > > Otherwise, searching a bit I got here > > https://github.com/QubesOS/qubes-issues/issues/3201 the impression that > > this port is used for non-torified Qubes updates proxy. Do update > > mechanisms still work (the torified && non-torified one) if you remove > > the line manually? > > It is indeed part of updates-proxy, which I assume you have enabled in > sys-net. > Sphere reports the rule allowing "coming from anywhere" - if this is o > then they must override the default - as haaber reports the default rule > allows traffic originating from the vif+ interfaces. > I guess this is a hangover from 3.2, as templates now use qubes-rpc, > but it does allow you to use proxy settings in your qubes and perform > package updates/installs. About that, sorry I forgot to specify which interface it was. By "anywhere" I had intended to mean any source ip address would be permitted to connect to port 8082 but as for the interface, it's definitely vif+ Welp, I suppose I'll do more testing in the following days before concluding that it's safe to just permanently remove it from the iptables rules since it doesn't break my updating of TemplateVMs I'll just leave this iptables command here for reference: sudo iptables --insert INPUT 1 -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT -- 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/545aceee-38b9-48a8-b392-475fbcbe864d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.5
So I have briefly read README.md about this and does this thing really have to run as a PV VM and cannot be a PVH 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/4aad0c4d-0b60-47e6-b885-34c48d50af38%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it just my machine or sys-net vm by default, has an INPUT accept iptables rule for port 8082?
@haaber thank you for your response and information provided to my inquiry Unfortunately I have already performed a full update of VMs before I discovered this but I will check up on this through an update/install whenever I'm free from my work in order to provide an update about 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/0568d1cc-0cdf-4b1f-837d-f2eee371bf65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Is it just my machine or sys-net vm by default, has an INPUT accept iptables rule for port 8082?
So I was doing some security checks on a whim in my Qubes machine until I stumbled upon discovery that my the INPUT chain of iptables in my net VM has a rule of accepting all tcp connections to port 8082 coming from anywhere I checked my other VMs and discovered that they didn't have this rule and that despite deleting the rule, whenever I disconnect the laptop from the wifi and reconnecting it would make this rule get added back So I thought about doing something to make permanent/persistent changes to these iptables rules unless otherwise that there is good reason as to why port 8082 has to be open for the net VM I would also like to ask where should I do changes to make iptables rules persistent, in the net VM or the template 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/322a1f18-730e-45c2-92fb-5b044406cd85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"
@cooloutac: I'm using Qubes 4.0 right now @American Qubist 001: I'm sorry but I beg your pardon, could you please be more specific? An example at least of what you mean by using different syntax Could you also specify which repos you used? -- 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/39742c31-b185-49d0-9ec5-a6fa7295212d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QSB #048: Multiple Xen vulnerabilities
Thank you very much for this advisory and the hard work -- 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/2fb41c10-d296-4488-99b6-88976e015ff8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"
I also did what Chris suggested as well as the dnf clean all and the result is all the same. No problem with my dns for sure because I'm using dnscrypt on a pool of 19 dns servers and I've never had problems resolving everything so far -- 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/5595b0bc-6758-43da-93f0-97f1d24877de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"
Thanks for this unman I tried the commands you suggested and it still ended up with the very same "Error: Unable to find a match" I'll track that issue you raised to know when it gets fixed (Y) -- 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/2c5ae297-2706-41f1-8051-edd467d8847c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Could Qubes Installation Configuration Be More User Friendly?
Oh and I must say, Nvidia is a sucker for Open source Really a huge pain to have their GPU and want to use the KDE desktop RE -- 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/059e6650-4a7d-4e78-9203-708de6387dbc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Could Qubes Installation Configuration Be More User Friendly?
On Monday, March 4, 2019 at 10:14:18 AM UTC+8, Aaron wrote: > On Sun, Mar 3, 2019 at 3:41 PM Chris Laprise wrote: > > On 3/3/19 2:56 AM, Aaron wrote: > > > Unfortunately I don't have that option in BIOS. There is no way I can > > > disable Nvidia chip. > > > > > > An average user won't deal with that much complication during > > > installation and this is probably a huge barrier to convert many users > > > from other OS to Qubes. > > > > > > I hope to see Qubes finding an easy solution for this issue. > > > > - > > Please post replies to the bottom, not the top. > > - > > > > Unfortunately, if Nvidia is secretive and only cooperates fully with > > Microsoft, then there is no way to reliably make such complex hardware > > 'just work'... too much is unknown and left to guessing. > > > > https://en.wikipedia.org/wiki/Nvidia#Open-source_software_support > > > > Its situations like this where people discover that hardware is not some > > ideal blank slate, requiring programmers to only put in the right amount > > of effort to get satisfactory results. Detailed information about > > accessing hardware features is necessary. > > > > And if your laptop maker forces you to use Nvidia then your only option > > (for that machine) is to try to troubleshoot the specific compatibility > > issues you're experiencing. > > > > Consumers who value open source do have better GPU choices such as AMD > > and Intel. They might even contact Nvidia (who are very wealthy BTW) to > > ask them to support Linux instead of pretending the onus is on Linux or > > Qubes developers. > > > > OTOH, people who don't want to think much about their computers (and > > their role as a consumer) or who don't value open source and the goodies > > it offers (like Qubes security) can remain comfortable with Nvidia > > hardware ...if they go back to Windows. > > > > -- > > > > Chris Laprise, tas...@posteo.net > > https://github.com/tasket > > https://twitter.com/ttaskett > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > > > > I understand. It's definitely frustrating. > > > I'm definitely new to Qubes, but I'm just wondering... I'm able to install > Ubuntu on the > same machine. I had to install Nvidia driver after Ubuntu installation was > done and it > wasn't a big deal. It took a few mins to handle. At least, I was able to > switch to shell (with Ctrl-Alt-F2) > and install Nvidia drivers at the last stage of the installation, at user > login stage. > > > How does Ubuntu handle a similar issue, at least until hitting the login > stage, without any configuration? > > > Aaron I believe this is because of a vast difference of manpower and popularity between Ubuntu and Qubes. Also taking into consideration the use-case of Qubes when it comes to popularity. You see, Operating systems don't really work "magically" on hardware These operating systems need to have drivers designed and coded in order to establish stable communication between your Hardware and Operating system. Taking this in mind, yes, for the most part, the general approach is to have a driver for each and every popular hardware that are put into machines and are being utilized by users. There may be generic drivers but these drivers don't really work universally So in order to code these drivers, you need a vast amount of manpower Since Ubuntu is arguably the most popular linux distribution to the general populace and I believe popularity really has alot of influence to the amount of people contributing to the Ubuntu project - contributors who could definitely help in coding these drivers While I'm not exactly sure if there is a way to make installation seamlessly work on 'any' hardware and only have issues float by Login interface and have access to shell, I sincerely believe that the very reason why installation tends to fail alot is the lack of drivers. There are a bunch of things you can try to make installation happen like setting nomodeset, acpi=off, and etc. Alas, if your notebook has an intel CPU then I seriously believe it has Intel HD graphics not unless it's those old ones that don't really have it It would be great if you have Intel HD graphics cause you can definitely push through installation with nomodeset to avoid utilizing your nvidia GPU It's not ideal to use that GPU for Qubes anyway, specially when you're looking to make some gaming VM where you would passthrough your Nvidia GPU -- 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/369191f3-38ec-4a47-85cc-c9ae942eaacc%40googlegroups.com. For more options, visit
Re: [qubes-users] Could Qubes Installation Configuration Be More User Friendly?
I believe this is because of a vast difference of manpower and popularity between Ubuntu and Qubes. Also taking into consideration the use-case of Qubes when it comes to popularity. You see, Operating systems don't really work "magically" on hardware These operating systems need to have drivers designed and coded in order to establish stable communication between your Hardware and Operating system. Taking this in mind, yes, for the most part, the general approach is to have a driver for each and every popular hardware that are put into machines and are being utilized by users. There may be generic drivers but these drivers don't really work universally So in order to code these drivers, you need a vast amount of manpower Since Ubuntu is arguably the most popular linux distribution to the general populace and I believe popularity really has alot of influence to the amount of people contributing to the Ubuntu project - contributors who could definitely help in coding these drivers While I'm not exactly sure if there is a way to make installation seamlessly work on 'any' hardware and only have issues float by Login interface and have access to shell, I sincerely believe that the very reason why installation tends to fail alot is the lack of drivers. There are a bunch of things you can try to make installation happen like setting nomodeset, acpi=off, and etc. Alas, if your notebook has an intel CPU then I seriously believe it has Intel HD graphics not unless it's those old ones that don't really have it It would be great if you have Intel HD graphics cause you can definitely push through installation with nomodeset to avoid utilizing your nvidia GPU It's not ideal to use that GPU for Qubes anyway, specially when you're looking to make some gaming VM where you would passthrough your Nvidia GPU -- 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/fabb631a-af20-4f3a-9a34-c47d0770eee7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"
On Friday, March 1, 2019 at 8:38:07 PM UTC+8, unman wrote: > On Thu, Feb 28, 2019 at 10:09:38PM -0500, Chris Laprise wrote: > > On 2/28/19 8:30 PM, Sphere wrote: > > > I was sure I double checked the line of code I used in dom0 terminal to > > > get a new template which was > > > "sudo qubes-dom0-update qubes-template-debian-9" > > > > > > Not sure why running this returns with the "Error: Unable to find a > > > match" while just changing 9 to 8 actually works > > > > > > The same case happens when I try qubes-template-fedora-29, where my > > > fedora-29 template still exists > > > > > > If this is because of some sort of name conflict issue, how could I > > > download the template/s and have them be named something else? > > > > > > > The older release with the apt vulnerability may have been removed from the > > repository, and the patched version may still be in testing? > > > > Easiest way to resolve that is to add '--enablerepo=qubes*testing'. > > > > I dont believe this is so. > A fixed version (201901281256) is in qubes-templates-itl, and I > *believe* that I grabbed it from there before. > What you need to run is: > sudo qubes-dom0-update --enablerepo=qubes-templates-itl > qubes-template-debian-9 > > @Sphere - do you have a debian-8 installed? If so it may be that yum > remembers which repo it installed from, and so is able to grab the > update. If this isnt the case (and the repo wasnt updated during the > day) then I'm lost for an explanation. > > Generally, if you want to do this manually, you can always grab from > https://yum.qubes-os.org/r4.0/templates-itl/rpm. > Download the package. > Manully check the signature using "rpm -K" (You will need to get signing > key and Qubes master) > Transfer to dom0 > install using "rpm -i " > > Much better to use the native tools, but that option is always > available. > > unman @unman - Nope I don't have debian-8 installed and that I snagged a fresh copy of debian-9 last year. What's noteworthy is that I can definitely trigger installation of debian-8 and other templates that I have never installed. I can trigger qubes-dom0-update just fine tho and have the repositories update. I'll try snagging the templates from the itl repo and see if that still triggers the problem, many thanks for lending me a hand hope it solves this problem -- 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/91ba8f3c-d8f1-403f-abb0-041e4ac684a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"
I was sure I double checked the line of code I used in dom0 terminal to get a new template which was "sudo qubes-dom0-update qubes-template-debian-9" Not sure why running this returns with the "Error: Unable to find a match" while just changing 9 to 8 actually works The same case happens when I try qubes-template-fedora-29, where my fedora-29 template still exists If this is because of some sort of name conflict issue, how could I download the template/s and have them be named something else? -- 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/7a356102-8f22-4e0b-8688-88e396805418%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Weird dnf update command behavior on fedora-29 template
On Friday, March 1, 2019 at 3:54:12 AM UTC+8, awokd wrote: > Sphere: > > On Thursday, February 28, 2019 at 11:57:22 AM UTC+8, awokd wrote: > >> Sphere: > >> > >>> Making it seem like my sys-net has been set as the updateVM for my > >>> fedora-29 template > >>> > >>> I haven't tried updating my other templates yet but performing a > >>> "qubes-dom0-update" works properly as intended and is using updateVM > >>> properly > >>> > >> Double check targets in /etc/qubes-rpc/policy/qubes.UpdatesProxy. > > > > Thank you very much for that > > I checked the file and I found: > > > > # Default rule for all TemplateVMs - direct the connection to sys-net > > $type:TemplateVM $default allow, target=sys-net > > > > (facepalm) > > Does this mean that the updateVM that I assigned was meaningless after all > > this time? OTL > > > Not completely. The updateVM setting applies for dom0 updates but to > also have your templates update via your new template you want to also > change the target= line in there. Ah that's a relief to hear While I did understand what those pieces of code meant I at least wanted confirmation from someone else Guess I'll go try to redownload my templates just to be sure -- 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/696cb816-415f-42c9-bf71-625e25f27d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Weird dnf update command behavior on fedora-29 template
On Thursday, February 28, 2019 at 11:57:22 AM UTC+8, awokd wrote: > Sphere: > > > Making it seem like my sys-net has been set as the updateVM for my > > fedora-29 template > > > > I haven't tried updating my other templates yet but performing a > > "qubes-dom0-update" works properly as intended and is using updateVM > > properly > > > Double check targets in /etc/qubes-rpc/policy/qubes.UpdatesProxy. Thank you very much for that I checked the file and I found: # Default rule for all TemplateVMs - direct the connection to sys-net $type:TemplateVM $default allow, target=sys-net (facepalm) Does this mean that the updateVM that I assigned was meaningless after all this time? OTL -- 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/528d7e58-9612-4ca9-966e-c361f8717905%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Weird dnf update command behavior on fedora-29 template
On Wednesday, February 27, 2019 at 8:30:53 PM UTC+8, unman wrote: > On Tue, Feb 26, 2019 at 06:54:15PM -0800, Sphere wrote: > > It started happening just today > > Executing sudo dnf update command on my fedora-29 template forcefully makes > > my sys-net start > > > > But thing is, I'm no longer using sys-net template as my net vm and this > > caused me to triple check my settings and my update VM is showed correctly > > as I had intended = a VM designed to securely process DNS queries that is > > attached to sys-firewall > > > > Despite this, the behavior continues, even if I kill and/or halt my > > fedora-29 template and I have no clue as to why this happens it's like > > something is forcing it to use sys-net in an attempt to get through my > > secure processing of DNS queries > > > > I also double checked that the template has no assigned net vm as intended > > according to how Qubes was designed and it's also set properly to 'none' > > > > It's absolutely persistent to the point that I ended up deleting my sys-net > > template and now the sudo dnf update command abruptly ends with "Error: > > Failed to synchronize cache for repo 'fedora-modular'" > > > > Can anyone help me with the logs to check/commands to use in diagnosing > > this problem properly? > > > > This is expected. Not a problem. > When you run dnf update , Qubes will start the update VM that you have > set. > As with any qube, if that has a netvm then it will start *that*, etc etc, > right up to sys-net. > If it didn't start a network connection, then you would get an update > error (as indeed you have). Sorry if I wasn't clear in some way that may have caused this confusion. I should've kept it short and simple: "I'm no longer using sys-net template as my net vm" my update VM has internet connection in it, I even did a ping to google Structure is: update VM -> Firewall VM -> Net VM(not sys-net) Which means dnf update should work as expected But instead what happens is dnf update execution -> starting sys-net Making it seem like my sys-net has been set as the updateVM for my fedora-29 template I haven't tried updating my other templates yet but performing a "qubes-dom0-update" works properly as intended and is using updateVM properly -- 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/0630b69d-04ac-449d-b318-22517dc7edd2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Weird dnf update command behavior on fedora-29 template
It started happening just today Executing sudo dnf update command on my fedora-29 template forcefully makes my sys-net start But thing is, I'm no longer using sys-net template as my net vm and this caused me to triple check my settings and my update VM is showed correctly as I had intended = a VM designed to securely process DNS queries that is attached to sys-firewall Despite this, the behavior continues, even if I kill and/or halt my fedora-29 template and I have no clue as to why this happens it's like something is forcing it to use sys-net in an attempt to get through my secure processing of DNS queries I also double checked that the template has no assigned net vm as intended according to how Qubes was designed and it's also set properly to 'none' It's absolutely persistent to the point that I ended up deleting my sys-net template and now the sudo dnf update command abruptly ends with "Error: Failed to synchronize cache for repo 'fedora-modular'" Can anyone help me with the logs to check/commands to use in diagnosing this problem properly? -- 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/12e13d20-2841-4576-8ddb-a2db1a941008%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: sudo qubes-dom0-update downloads packages but abruptly ends with a "The downloaded packages were..."
On Monday, February 11, 2019 at 5:13:40 AM UTC+8, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Feb 10, 2019 at 07:33:21PM +0100, Dupéron Georges wrote: > > I have the same issue. I thought there weren't any new updates, but it's > > been like this for a while. > > > > There are two updates listed, but they never get installed. > > > > Note: I am not using the regular sys-net as my updatevm (I am using a plain > > fedora 29 VM, that is connected to sys-firewall, which is connected to the > > sys-ethernet VM to which the PCI device is attached). > > > > Log: > (...) > > Reinstalling: > > This looks like it tries to update to the same version it already have > installed. Looks to be this issue: > https://github.com/QubesOS/qubes-issues/issues/4792 > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxgk/0ACgkQ24/THMrX > 1yzHkQgAkeyp0rkaSYX+ysS2sdgKk/TTt8fTJohevDpdwpJIQZ1ibMXRr+J2DEWL > LuOi7JWFebK53xGD6eQvu8AaCuvSNpWWf9lrdm8taPi267t1Q03bO6tJyqfOzFcU > H8vMuC0rdq8JH97oCUxl5lhjDNaLX2JJmjIX43td33DANxtdgkwgVg+gPThvxWZl > 6CFNEtmH5rW+5n4ISyJZ9PC4k6zzjnmnyhaak4GLCeeJ5WYYU8E1xWD4JuB/ZKcT > mCH/JFgD5Bc5MS8xHYylAhBOF+gNJPOyVnb6qrxaRxmp284l1UjqtzFaiZGAeNd9 > 9uciJE80mKP8uh9nm8SRFtN6WfjBOQ== > =JLEm > -END PGP SIGNATURE- Thank you for this So it seems there's a bunch of people having this problem too and now it is marked as critical Oddly enough though it doesn't suffer from this problem when trying to install a new package. Tried installing Anti-evil maid and it gone through without problems on both Downloading and Installing -- 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/8ec28316-5d00-411b-968e-ee0adbab3775%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: sudo qubes-dom0-update downloads packages but abruptly ends with a "The downloaded packages were..."
It's like this but without the errors: https://pastebin.com/YVUFtid6 -- 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/d40be472-5b1c-40a8-a82a-4cf24382e86a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] sudo qubes-dom0-update downloads packages but abruptly ends with a "The downloaded packages were..."
I have no idea what's up with my dom0 It downloads the packages through sudo qubes-dom0-update but by Transaction Summary after showing Total Size and Installed Size it doesn't even ask me whether or not to continue the transaction but just says "DNF will only download packages for the transaction." Proceeds to download the packages then ends with a "Complete!" "The downloaded packages were saved in cache until the next successful transaction." Seems some setting about DNF got changed, how do I fix this? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/27341873-f8f4-49bb-9c15-5dd78fcbddef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to do the extra configuration needed on a new template
On Tuesday, February 5, 2019 at 8:35:28 AM UTC+8, unman wrote: > On Sun, Feb 03, 2019 at 10:16:55PM -0800, Sphere wrote: > > So I got a new Fedora-29 template but the problem is that after assigning > > it to sys-net/sys-firewall all it shows is something similar to what you > > when you start a generic PC after BIOS POST. > > > > All that's in this link: > > https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/ > > > > Is how to get the template but I don't think I found anywhere detailing > > what to do afterwards. > > > > I'm not clear what you mean by this: "what you when you start a generic > PC after BIOS POST". > > Once you have installed the template (with dnf or qubes-dom0-update), > then all you have to do is assign it to qubes as required. Those qubes > will then start using the assigned template. > You can confirm this by opening a terminal in sys-net and observing > contents of /etc/fedora-release My bad about that. I meant to say was "what you see when you start a generic PC after BIOS POST" Hmm I tried it again today by assigning it to a test vm and surprisingly it worked. Not sure if a reboot did it but I haven't really touched it since February 4. In any case thank you for that. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/09390c9c-e9a8-43bc-ac07-83890f15fbaf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes with newer hardware and error messages still safe enough?
> It is not an option - it can't be disabled! By Option I mean, an option whether or not to ride along with PSP despite the known horror it brings. If only I could establish my own CPU production company I would definitely support libre hardware/libreboot/coreboot and such but sadly we are in a world with high demands to processing and stuff and due to how there is hardly any support for libre hardware, the processing needs are hardly filled out and even more so with limited budget. I checked KGPE-D16 KCMA-D8 g505s coreboot and it seems good so long as you have enough budget. Say I would make a KVM server or ESXi server out of this for the purpose of gaming VMs running AAA games, which CPU and RAM models would you suggest? -- 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/e3150547-a9c8-4059-b29a-56e1b7fce537%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes with newer hardware and error messages still safe enough?
On Thursday, December 13, 2018 at 9:59:27 AM UTC+8, tai...@gmx.com wrote: > On 12/12/2018 03:56 PM wrote: > > New to Qubes with basic Linux knowledge i installed successfully a desktop > > system with follwing configuration: > > > > Qubes 4.0, CPU Ryzen 5 2400G, MB ASRock B450 Pro4, GPU Radeon R7 370, 32 GB > > RAM > > > > I can update templates and install appvms without issues. Everything works. > > > > My question is now: On Boot screen i get some error messages (see following > > screen). Possibly there is a lack of safety i can not estimate. Everything > > works but under the surface i did not know if it is as safe as it should > > be. Are there some basic tests which should be made? Or is it enough when > > the system works? > > > > Well you are stuck with a system that has a very obvious frontdoor > backdoor called AMD PSP platform "security" processor (as in security > from you) that prevents you from doing as you please with the system > firmware hence it is not really your computer. > > If you want one that is owner controlled and has free (as in freedom) > open source firmware I have written many walls of text on this subject > so just use a non-google search engine to find my previous posts. > > You also are using gmail which is really bad if you care about not being > put of of work or murdered by a robot - your emails and re-captcha > solves are fed in to a massive database that helps googles AI research > including killer robots like project maven and also of course sold to > advertisers and anyone else who can pay. > > I do not load images from random people if you want help you have to > send text only. How about give us keywords to help us search this and have it at the first search result? As for stefanne's inquiry, here are my thoughts: It's usually normal to see error messages on start of a linux system cause consumer motherboards production processes still have no proper arrangement to fully support Linux operating systems much to our dismay. To check the level of your safety, I recommend you produce one of these and see the results: https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports If it's a yes on HVM, IOMMU, and SLAT then that means your hardware works very well on Qubes. To further increase security, I recommend you to turn off SMT (Simultaneous Multi-threading) as recently there's been a high surge of vulnerabilities involving multi-threading/hyperthreading and will probably haunt us for years to come. Additionally, if you have an entry of IOMMU=no Go search around your BIOS setup for an option like AMD-Vi or IOMMU and set that to enabled. Product another report to check and see if the entry changes to IOMMU=yes IOMMU is essential because it protects you from alot of complex attacks like Direct Memory Access (DMA) attacks. Lastly, check for updates everyday and never neglect them for maximum security! After all this, you may want to configure a VPN. As for the Platform Security Processor, well it's an option for people whether or not they would go with it. -- 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/e6f243b3-d1db-4ed5-9e77-b8f7bf5ae37b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: About X.Org vulnerability and Qubes
I apologize for the late reply everyone. Thank you for your all your thoughts about this matter. I had read the responses days ago but I ended up forgetting to respond and marking this as complete. Your responses have added to my knowledge and ease with the Qubes OS. I am grateful for all 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/6120ac41-db62-4fb0-a61c-fb7145a35857%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Motherboard recommendations
Please refer to the Hardware Compatibility List if you're in no situation to go blind or full YOLO on some hardware. https://www.qubes-os.org/hcl/ Anything in the list that has all green(yes) on columns from HVM column to Kernel column should be good. Disregard "unknown" of TPM Column as it likely means the submitter of the HCL report file didn't bother checking the status of the TPM nor bothered configuring/trying to make it work. Note that the TPM only matters with high regard if you want to make Anti-evil maid work. For more information check: https://www.qubes-os.org/doc/anti-evil-maid/ Once you have picked a hardware candidate, be sure to thoroughly read the remarks as it is your key to getting things to work should some extra pre-configuration was needed for installation to finish properly. Mind you that on my first time of getting Qubes to work properly, I had to do tons of research and understanding to finally get it going nicely. If you're really determined for this then it's time to steel that determination some more and it also depends on your luck. -- 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/e3c5751e-7b04-4f50-ba03-5c12ba899594%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] About X.Org vulnerability and Qubes
https://threatpost.com/x-org-flaw-allows-privilege-escalation-in-linux-systems/138624/ It is said that leveraging the vulnerability is possible from a remote SSH session. Say an attacker was able to successfully gain a remote SSH session in an untrusted VM, do you think it would be possible to gain full control through qubes' implementation of X.org? I checked around and if I understand it right, qubes utilizes X.org in order to integrate the display of PVH VM applications to what the user can/must see. Because of this, what's in my mind right now is that it's possible to leverage this vulnerability to gain full control but since I don't have an idea of the codes or how exactly qubes' implementation of X.org works, I would like to kindly ask for your thoughts about this matter. Earlier I was about to remove setuid of Xorg but I thought it has a good chance of breaking my desktop environment altogether and that would be alot of trouble for 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/848dfc38-040c-422a-958a-c20b68db1b87%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: My farewell to Qubes OS!
I've only been a minor part of the Qubes community and I am truly grateful that this kind of Operating System became a reality and am proud to say that I am using it as my daily driver. Thank you for all your contributions to the Qubes OS and I hope you well on your new journey :) -- 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/14ecb571-9e13-4f1c-ac9f-44a8b2a008c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is Qubes vulnerable to CVE-2018-3620?
On Wednesday, August 15, 2018 at 8:50:28 PM UTC+8, Rusty Bird wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Sphere: > > https://www.bleepingcomputer.com/news/security/researchers-disclose-new-foreshadow-l1tf-vulnerabilities-affecting-intel-cpus/ > > > > There are other vulnerabilities disclosed along with this today and > > if possible, I would like to confirm that as well. > > > > On a side note, I have long disabled Hyperthreading on my machine. > > To me as a layman, it looks like Qubes is indeed vulnerable to the > XSA-273 data leak, and that fixing it involves > > 1. disabling hyperthreading (by adding smt=off to the Xen command line) > 2. AND upgrading Intel microcode to 20180807 > 3. AND upgrading Xen > > There's a pull request* for the new microcode package. As for Xen, the > XSA says they're "not supplying separate patches because the changes > have many complicated prerequisites", and their d95b5bb commit on the > staging-4.8 branch is 42 patches ahead of RELEASE-4.8.4... :\ > > Rusty > > > * https://github.com/QubesOS/qubes-intel-microcode/pull/2 > -BEGIN PGP SIGNATURE- > > iQJ8BAEBCgBmBQJbdB8sXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 > NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf+A4P/jJopc94LC67vWz+PmkLOmB5 > DaxS/VmFB70CNzfDmQMJ58YLOJ7z2wu9GEOOnHgP+KmAKsn9/xtp5nufrMfNoOd+ > a7dezBA0b2vHy7aVaAXG3qhRL9PhHqpFhcUrudShATrUWdY2aFnaeRGSZDbwoR40 > jGEgjxFFM2SGEtTHOEuKBBfLU/OJMw72ClmIAIdtvfEPABQ0WYw95OmcVTzi+tvZ > 2bEwXJz1cXUovGzDPInbBBZm43m3X/r9FAnsFdLQXyjgRNkFc2LuhVz5Tc12NGjH > 6Xb2qJlIhQVZjotRPqm506G6UrKrx5DB0lANY2/H8tl/tPACyoTY+EHrOJHIz/21 > XipPbVVLqQJtQJOgQXCkHEPz49X1Deni/TFedrQxzEuTiOH5R/KVjqEe17cwyaL4 > f6HHf94OiFHGKVmGtwySwMxxWiH9T0UOu3+Xzo3UNE9IPkLoakcXMTvaLFJS9Hfa > AFZil3+aKMogWWRS0mJJc0UX+m9jpPdwERdXAriqAY4mp59TJ3qt5OFEobSlG4kD > aRIfBiQbMRZagfwtsHLTxwEymwMyaovm/q7hv6cZvNYm2S7cztMdFXeUquYlZgJi > ZzCr+AirENSDSBq+hCosnGdvwAAemiUBpRh3kXHMuOTtR1Lu3ulnatN64SCznzPR > M8ZJnNdpOLX4RqU/yTr/ > =E4BM > -END PGP SIGNATURE- I have hyperthreading disabled on my BIOS, do I still have to add that option to Xen command line? By pull request you mean, it's still being grabbed for use and installation using qubes-dom0-update right? As for Xen updates, welp we have no choice but to wait for that I suppose. -- 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/5d320435-9846-4dc7-90b5-edb2740bb0de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] X470 and IOMMU Groups...
Surely you have checked that your boot sequence really starts at the HDD where you installed qubes right? I got a case where my bios completely could not recognize the drive where I installed my Qubes as bootable and had to do sum stuff in the Boot sector to make it work. The same may apply to you so yeah. -- 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/4e87ae91-5829-41c6-9a9e-22c8f2be5226%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Is Qubes vulnerable to CVE-2018-3620?
CVE-2018-3646 in particular is alarming: "The third flaw, CVE-2018-3646, has a CVSS Base Score of 7.1 and enables bad actors to attack virtual machines (VM), via virtualization software and Virtual Machine Monitors (VMMs) running on Intel processors. A malicious guest VM could infer the values of data in the VMM’s memory." Could potentially allow Untrusted VMs to attack safe VMs but I don't know for sure whether or not Qubes mitigates 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/b8c08313-4662-4c9e-a182-5dc83f48f4d5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Is Qubes vulnerable to CVE-2018-3620?
On Wednesday, August 15, 2018 at 10:33:09 AM UTC+8, Sphere wrote: > https://www.bleepingcomputer.com/news/security/researchers-disclose-new-foreshadow-l1tf-vulnerabilities-affecting-intel-cpus/ > > There are other vulnerabilities disclosed along with this today and if > possible, I would like to confirm that as well. > > On a side note, I have long disabled Hyperthreading on my machine. For reference to this vulnerability as well as 2 more: https://threatpost.com/intel-cpus-afflicted-with-fresh-speculative-execution-flaws/135096/ -- 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/4dcd121e-1b7e-48ff-bf4a-92888140afd7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Is Qubes vulnerable to CVE-2018-3620?
https://www.bleepingcomputer.com/news/security/researchers-disclose-new-foreshadow-l1tf-vulnerabilities-affecting-intel-cpus/ There are other vulnerabilities disclosed along with this today and if possible, I would like to confirm that as well. On a side note, I have long disabled Hyperthreading on my machine. -- 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/12d30846-c21f-4eac-9d79-38d90adaab0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android-x86 on Qubes 4
On Wednesday, August 8, 2018 at 9:37:53 PM UTC+8, rex mat wrote:
> After the manual install, I can boot, but ethernet can only be configured
> from the terminal. That is still work in progress.
> You need to have an android-x86 build and check out the 7.1.2 version to
> build a cd. I found the instruction on the web on the android-x86.org web
> page. I recommend using the ubuntu 16.4 version mentioned as the preferred
> build machine in a hope you avoid the pain I went through to do a build on
> qubes.
>
>
>
> I did the following 2 changes:
>
>
>
> 1. Changed 1 line in "init" inside initrd
> from:
>
> for device in ${ROOT:-/dev/[hmnsv][dmrv][0-9a-z]*}; do
> to:
>
> for device in ${ROOT:-/dev/[hmnsvx][dmrv][0-9a-z]*}; do
> That allows the XEN hard drive to be used at initialization
>
>
>
> 2. I configured the kernel
> Below is the config (I hope, as I played afterwards to get a proper mouse,
> with no avail). This config disabled a lot of things that need blobs and the
> like to get it built:
>
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.9.109 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="-android-x86_64"
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="android_x86_64"
> CONFIG_SWAP=y
> # CONFIG_SYSVIPC is not set
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> # CONFIG_FHANDLE is not set
> # CONFIG_USELIB is not set
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
>
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
>
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
>
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_SCHED_WALT is not set
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
>
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=17
>
[qubes-users] Re: X470 and IOMMU Groups...
On Thursday, August 9, 2018 at 1:30:49 AM UTC+8, 3mp...@gmail.com wrote: > Hi everyone, > > actually I'm a happy Qubes 3.2 user on Intel platform for more than a year > now ! > > I'm looking to upgrade my actual Skylake build with an AMD one with the new > Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same > occasion. The Asrock X470 Taichi seems a really nice motherboard for it. > > I've found the IOMMU Groups of this motherboard on reddit : > https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/ > > and it seems there's a big group 13 with LAN, USB and SATA controllers. I > wonder if the netVM and USB VM will actually be able to passthrough these > controllers if they are in the same IOMMU Group ? > > Any Ryzen / Qubes users can confirm this works OK or this is a no go ? > > Thanks for your help ! I've observed that Qubes installation rarely ever succeeds on X370 motherboards so I believe the same case applies to X470 motherboards with a higher chance of failure since it is newer. The reason for this I believe is because these high-end gaming motherboards have alot of functionalities/bugs that break/interfere with Qubes installation which is an awful letdown. So while that mobo having separate IOMMU groups being a plus, it doesn't matter much when you're still in the installation phase of Qubes (Which is the real hard phase to overcome when it comes to 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/9e610861-0b9c-4a49-a65e-25d1592a9388%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X470 and IOMMU Groups...
On Thursday, August 9, 2018 at 1:30:49 AM UTC+8, 3mp...@gmail.com wrote: > Hi everyone, > > actually I'm a happy Qubes 3.2 user on Intel platform for more than a year > now ! > > I'm looking to upgrade my actual Skylake build with an AMD one with the new > Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same > occasion. The Asrock X470 Taichi seems a really nice motherboard for it. > > I've found the IOMMU Groups of this motherboard on reddit : > https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/ > > and it seems there's a big group 13 with LAN, USB and SATA controllers. I > wonder if the netVM and USB VM will actually be able to passthrough these > controllers if they are in the same IOMMU Group ? > > Any Ryzen / Qubes users can confirm this works OK or this is a no go ? > > Thanks for your help ! On a side note, I wanna ask Do you play games/tried playing games on that Qubes 3.2 installation of yours by any chance? -- 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/23f00eb8-8f36-49c4-be7c-fa84c27677de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS dual boot question
On Tuesday, August 14, 2018 at 4:17:31 AM UTC+8, Patrick Bouldin wrote: > I have a goal to buy a new laptop, preconfigured with Windows, and then > within Windows I will reallocate disk space in order to install Qubes4.0. > > In the past with prior versions of Qubes that has sometimes been problematic, > is that fixed with 4.0 or still a problem? > > Any input on how to proceed? > > One data point, while I can recreate windows it's a pain in the butt to get > the licensing back on the machine. I can do it, but would like to avoid it. > > Thanks, > Patrick Question: What's your purpose for using Qubes? Usually the answer is to have very-high level of security. This purpose however, is ultimately defeated once you do OS dual boot as your Qubes installation could be easily infiltrated/modified in the context of the Windows OS that you have dual-booted. So I suggest having two HDDs or one HDD and one M.2/SATA PCI SSD in your laptop to effectively separate the Windows OS and Qubes OS(By setting a password on the HDD/SSD where Qubes is installed and not entering it when booting on the Windows OS (To effectively protect the UEFI boot partition and also a tag-team protection with LUKS encryption). If you really want to insist on dual boot however, sad to say but I can't help you with that. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/37b79503-dc99-40e1-ba10-178ce5f2f221%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Incredible HD thrashing on 4.0
On Saturday, August 11, 2018 at 3:02:31 AM UTC+8, Kelly Dean wrote: > Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not SSD? > Have you noticed the disk thrashing to be far worse under 4.0? I suspect it > might have something to do with the new use of LVM combining snapshots with > thin provisioning. > > The problem seems to be triggered by individual qubes doing ordinary bursts > of disk access, such as loading a program or accessing swap, which would > normally take just a few seconds on Qubes 3.2, but dom0 then massively > multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on for > minutes at a time, and in some cases, more than an hour. > > iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1], > reading the disk at rates ranging from 10 to 50 MBps (max throughput of the > disk is about 100). At this rate, for how prolonged the thrashing is, it > could have read and re-read the entire virtual disk multiple times over, so > there's something extremely inefficient going on. > > Is there any solution other than installing a SSD? I'd prefer not to have to > add hardware to solve a software performance regression. Same here for me, I hear lots of scratching sounds from the HDD whenever I do something in the laptop. Extremely worries me that the HDD might die soon because of it D: -- 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/182578a5-3cad-4dbe-9cdc-94a78cc58930%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: New CPU Bug Found
On Tuesday, August 14, 2018 at 7:44:18 AM UTC+8, jonbrown...@gmail.com wrote: > New CPU backdoor has been found with code available here: > https://github.com/xoreaxeaxeax/rosenbridge > > Anyone mind checking if Thinkpad 230 is affected? Wow... things sure are going rough in the firmware/hardware/low-level instruction side of things -- 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/4a3aa75a-7ce6-4075-a7e1-a96852c5c161%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Manually remove R4.0 template vms
On Tuesday, July 17, 2018 at 2:37:05 AM UTC+8, Will Dizon wrote: > qvm-prefs fedora-281 installed_by_rpm false > > This worked perfectly. Was even able to remove it from the existing qube > manager instance without reinstallation. Thanks so much! Thank you very much for 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/14243512-8e76-4fc8-a28e-0ef562adf686%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to change TemplateVM update method from Whonix to just another appvm?
On Wednesday, August 8, 2018 at 1:17:23 AM UTC+8, Patrick Schleizer wrote: > Sphere: > > So upon installation of Qubes I have set updating of TemplateVMs through > > Whonix but now I'm actually stuck with it and I want to change it to > > updating through just another AppVM. > > > > Could anyone guide me to what commands I need to use in order to fix this? > > (I actually wish this was an option in Qubes settings UI as well) > > > > Qubes R4? > > modify: > > /etc/qubes-rpc/policy/qubes.UpdatesProxy 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/67e35a4d-c072-4006-b70f-806dcdcd4800%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Can't find a guide to setup a new fedora-28 template
Sorry for the late reply I installed a fresh template and what happens when I assign it to Service VMs is that some terminal opens that's similar to what I see whenever I make a new Standalone VM that requires a CD-ROM/ISO to install an OS. I recently have done upgrading fedora-26 to 27 and it works like a charm. Just gonna upgrade it to 28 I suppose though I do still want to know a way to make the fedora-28 template I installed work as it's much faster to jump to 28 than having to go through 27 which takes almost a whole day. -- 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/b50b0c65-0980-423f-99e5-74573b68adb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Can't find a guide to setup a new fedora-28 template
So I just installed a new fedora-28 template in hopes of using it as the template for my sys-net and sys-firewall VMs but apparently seems there's still alot of manual configuration to do in the template before it becomes ready for that. Could anyone provide me with a guide to do this? Thanks in advance -- 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/be60f7f3-eb1a-42ab-9e3b-03f96556dceb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: NSA’s Encryption Algorithm in Linux Kernel is Creating Unease in the Community
On Saturday, August 4, 2018 at 3:01:09 PM UTC-4, John wrote: > Just reading this. It appears Speck is a module and can be excluded, so > hopefully nothing to worry about. > > https://itsfoss.com/nsas-encryption-algorithm-in-linux-kernel-is-creating-unease-in-the-community/ what a pain in the arse, trying to push as standard of IoT? These guys are really just plain mad. Defending the country - done the wrong way -- 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/7b7a3afe-f779-49fe-ae2b-de8400a98205%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to change TemplateVM update method from Whonix to just another appvm?
So upon installation of Qubes I have set updating of TemplateVMs through Whonix but now I'm actually stuck with it and I want to change it to updating through just another AppVM. Could anyone guide me to what commands I need to use in order to fix this? (I actually wish this was an option in Qubes settings UI as well) -- 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/312c04a9-7690-4fbe-a2ca-3364917e5db4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
