[qubes-users] Re: Trying to download a large file (3 gigs) in a VM results in failure each time
On Monday, June 10, 2019 at 3:06:04 PM UTC-4, atrain...@gmail.com wrote: > So I'm trying to download my windows ISO through Qubes so I can add it to my > Qubes but half way through the download, it keeps failing, regardless if I > use my personal or disposable VM. What's going on? The initial default maximum storage size for AppVM's is only set at 2 gigabytes, I believe, so trying to download anything larger will cause an insufficient space failure. Change the storage size maximum value in the VM's settings, either from Qubes Manager or the cascading Q-menu for that AppVM. -- 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/c932ac3d-9426-4ebb-8bac-21d0ec20fefa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Full proper backup of Dom0 possible?
For both Template and AppVM's it's easy enough to backup and restore the entire thing as needed using the built-in tools from Qubes Manager, Qmenu or command line. Anything goes wrong, just restore a backup. But for dom0, all that seems to get backed up is the /home directory, meaning that any changes to other system areas such as /etc/qubes-rpc/policy/ for example would not get restored in the event of a reversion to a previously made backup after a fresh system install. Is there any way to make a full proper backup of Dom0 that would include absolutely everything outside of the other VM's on the system, obviously? So that after performing a fresh system install and then restoring all backups (dom0, templates, appvms) you would end up with a complete byte-for-byte replica of the previous system that existed? This could be done with external tools like DD of course, but that produces a gigantic image of the entire hard drive rather than just the needed parts, and also doesn't allow one to fully restore *just* dome0 while leaving the other templates/VMs alone, if desired. Does such a versatile option exist? -- 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/04ee93a2-125b-4a5b-a43a-acdfa4866b7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes: Unable to connect to VPN
On Friday, March 1, 2019 at 9:07:57 PM UTC-5, unman wrote: > Call it with --down to have a script run when the tunnel closes. > If you check the man page, there are a variety of different options for > running scripts/commands at different events, but I suspect that will > fit the bill. Thanks!! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/825c9f2c-afb1-4170-a289-7c48d24f3871%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes: Unable to connect to VPN
On Tuesday, February 19, 2019 at 2:53:22 PM UTC-5, Jon deps wrote: > https://www.qubes-os.org/doc/vpn/ > > I believe it would be helpful if you indicate which method you have > used to create the VPNper the URL there > > > perhaps it is more obvious to others Thanks for your reply - sorry I somehow missed seeing it earlier. I managed to sort of figure out what is going on and sort of fix it. I am using the super-simple method of just invoking "openvpn whatever.ovpn" from terminal within an AppVM itself, rather than creating a dedicated proxy or gateway as suggested in the docs. What is happening is the following.. Initially before connecting to the vpn, the file /etc/resolv.conf contains the default Qubes sys-net dns entries, namely: nameserver 10.139.1.1 nameserver 10.139.1.2 When the vpn connects, it uses update-resolv-conf to overwrite the contents of that file. It places some comment-text near the top and changes the nameserver entries to its own, which is good and wanted of course. No complaints. When terminating the vpn connection by any means available (I tried several different ones), openvpn again automatically updates that /etc/resolv.conf file, but *only* to remove the entries it placed there, nothing more. The comment-text is left intact and the nameserver entries are simply deleted, resulting in a more or less empty and useless file and no DNS resolution whatsoever. The script does not seem to store and remember the previous entries that were there before (sys-net defaults) and replace them when finished. It just erases everything and leaves it like that. Thus after disconnecting the vpn I have to go back into that file and manually re-add the sys-net entries to regain DNS resolution functionality. Ultimately I'm just going to write a short bash script that puts the needed entries back after disconnection, which I'll run at termination every time. I don't know enough about openvpn to instruct it to "always run this extra script upon disconnection", though I'm sure there must be a relatively easy way to do so. -- 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/2924a4fe-1416-43c6-b241-7b87c5b3476f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
Just reviving a thread of mine from a few months ago with a related follow-up question. When trying to connect to a VPN using openvpn from a Debian-9 AppVM within Qubes, I could connect but instantly lost DNS resolution which rendered the connection unusable. Installing he package 'resolvconf' and adding the following lines to the .ovpn script supplied by the VPN provider: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf ...solved the issue and I was able to achieve full connectivity through the VPN. Now, when trying to *disconnect* from that VPN using Ctrl-C from command line (or any other method) I am able to end the connection, but the DNS assignment does not appear to automatically reverse/undo and revert to the default DNS servers provided by sys-net within Qubes, namely 10.139.1.1/2. And as a result I once again cannot connect to any websites due to lack of functioning DNS lookup. Having done a bit of research I've tried using commands like: sudo ifconfig tun0 down sudo ip link delete tun0 ..but in both cases I get a response that 'tun0 does not exist' or something similar. Is there any extra step needed to completely drop the VPN connection and revert to using normal sys-net connectivity, without requiring a restart of the AppVM itself? If I manually examine /etc/resolv.conf within the AppVM it still shows the default sys-net DNS entries as expected, so there must be some additional command needed to fully end the connection and revert to normal. What am I missing? -- 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/19fac423-d6ef-4ae1-9ace-b8721552e44f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
On Tuesday, November 20, 2018 at 3:56:22 PM UTC-5, 22...@tutamail.com wrote: > Interesting Otto...can you elaborate on the files you changed? I had this > working at one time but then broke...I never managed to get it working. > > What files did you change? The config files? > > Any specifics for a newbie would be appreciated and likely appreciated by > others. > > Thanks, > 22Rip In my case I had to change the config file supplied by the VPN provider itself, which ends with the extension ".ovpn" In that file, just before the certificate info section which starts with: -BEGIN CERTIFICATE- ..I had to add the lines: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf That change, in combination with the package 'resolvconf' being installed in the template that the AppVM is based on (Debian 9, which did not have it installed by default), caused the VPN connection to work properly with functioning DNS lookup. -- 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/bdba428f-3533-4cee-8a3d-67f1f137c0f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
Further update: I decided to try a completely different VPN provider's config file, and to my surprise that one worked fine using the old simple method of calling openvpn from the AppVM. Examining both files and looking for the difference between the two, it appears the broken one did not ever invoke resolvconf include the following lines: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf Adding those lines to the non-functioning file and running it resulted in success. -- 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/930b5080-4ba8-428f-bcf6-0eeaa1411c4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
On Monday, November 19, 2018 at 3:55:19 PM UTC-5, Chris Laprise wrote: > Qubes 4 networking is re-written and functions somewhat differently than > Qubes 3.x. So it seems. After spending several days trying to get a VPN connection up and working via every possible method conceivable, I have been met with complete and utter failure and have finally given up. The results are always the same. Whether I connect manually with Openvpn, use qubes-vpn-support, qubes-tunnel, try from an AppVM, NetVM, ProxyVM, edit /etc/resolv.conf or any number of other files or scripts, it makes no difference. The VPN output reports successful connection (Initialization sequence completed) and I can ping any numerical IP address I specify without issue. But DNS resolution does not work, and nothing I try fixes it. Booting up Qubes 3.2, the same VPN connection works flawlessly and DNS is trouble-free. So I've decided to solve my problem in the simplest (and only) way available: by going back to Qubes 3.2. I appreciate all your attempts to help me with this. 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/81b7d62b-f4ca-45b1-9745-1030ebbd6530%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
On Monday, November 19, 2018 at 12:27:40 PM UTC-5, Chris Laprise wrote: > It could be as simple as editing your /etc/resolv.conf so it contains > your VPN provider's DNS server (or other DNS server that you prefer) > instead of the Qubes internal routing addresses. I'll give this a try, thanks. What mystifies me though is that I still have Qubes 3.2 installed on an older laptop and can confirm that on that version, none of these extra config steps are needed. I can activate and deactivate the VPN connection at will on the fly from an AppVM terminal, and it works flawlessly every time. Run openvpn and my IP address changes to the provider as expected. Hit ctrl-c to terminate the connection, and it goes back to my regular ISP-provided address as expected. Ideally I'd actually like to have this ability it switch it on and off as many times as desired during any given session, but maybe that's no longer possible in Qubes 4. Also, I tried the instructions here: https://github.com/tasket/Qubes-vpn-support/ ..and they did not work. Everything seems to go okay, but after copying/installing/linking everything as directed and then shutting down and restarting the ProxyVM, it pops up the message "Ready to start link", and then just repeatedly does that every 10 seconds or so. The link never actually goes up. Problem isn't with the provider's .ovpn config file, since it works fine on Qubes 3.2 as well as another mainstream Linux distro, with no issues at all. Not sure if it's significant, but the service "vpn-handler-openvpn" does not appear in the dropdown list of available services in the ProxyVM's settings screen, even though the template on which it is based (Debian 9) most definitely has Openvpn installed on it. I typed that service name in manually and it accepted it, but it also accepts any garbage text entered as well, so no idea whether it's actually functioning properly or not. I was also admittedly a bit confused about whether I needed to separately install the qubes-tunnel package first, but the instructions didn't seem to explicitly require it so I did not. Other than that, I followed them to the letter but cannot get the link up. -- 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/77f93612-be60-4dbb-b8f5-f78e7af34e59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes: Unable to connect to VPN
On Monday, November 19, 2018 at 1:09:33 AM UTC-5, Chris Laprise wrote: > The Qubes VPN doc has two methods for correct openvpn configuration: > > https://www.qubes-os.org/doc/vpn/ > > A better method is located here: > > https://github.com/tasket/Qubes-vpn-support/ > > The difference is more failsafe checks and much smoother setup & operation. Thanks for your reply. I'm entirely willing to consider using these better, more secure and effective methods in the long run. My first objective however is to determine why the simple method I used in Qubes 3.2 (running Openvpn from AppVM) does not successfully work the same way in Qubes 4.0. > I would also try pinging known IP addresses (after connecting) to see if > you can get a response. If you can, then the problem is likely with the > DNS routing and dnat in the firewall. I've just tested this. After connecting to the VPN from within the AppVM, I can successfully ping known IP addresses from the terminal. However attempts to connect to websites in the browser fail and time out. What is my next step? How do I check or fix DNS routing and dnat in the firewall? -- 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/c80be580-203d-4228-b18b-9a980113d8ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes: Unable to connect to VPN
I realize it's possible to create a dedicated ProxyVM and use NetworkConfig to route VPN traffic, but that's not what I'm asking about. In Qubes 3.2 from any standard Debian AppVM connected to Sys-Net I am able to simply do from terminal: sudo openvpn --config ..and it connects, and from then on all traffic from that AppVM is correctly routed through the VPN, as evidenced by testing IP address from web browser etc. In Qubes 4, this does not seem to work. The same command from AppVM terminal works fine and reports successful connection to the VPN, but from that point all attempts to connect to any website or other remote host fail completely and just time out. As soon as I terminate the VPN by pressing ctrl-c from terminal, net connectivity resumes as normal. What has changed in Qubes 4, and what do I need to do different to make it 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/6b4f93fe-f2b9-4f47-98a6-09674d593525%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
On Monday, November 12, 2018 at 11:44:08 PM UTC-5, Ivan Mitev wrote: > Oh, I see. I've updated the issue to add a mention about the gateway. > Actually the issue was originally meant to document the problems with > QWT on R4 but it slowly evolved into a step-by-step guide. > The ip output by `qvm-prefs vmname visible_gateway` ; if you don't have > a fancy vpn/firewall setup, it's likely 10.137.0.6. Thanks - I added the sys-firewall gateway value and that seemed to do the trick in restoring connectivity (which is of course, entirely obvious in hindsight). A couple of oddities I noticed though: With everything manually configured and working, I can successfully ping the VM's own ip address and the gateway from within the VM, however I can *NOT* ping the DNS servers at all. Attempting to ping 10.139.1.1 or 10.139.1.2 results in: Response from 10.128.100.62: Destination net unreachable I have no idea what that IP address above is. Obviously DNS resolution is working since I can lookup websites correctly as expected, but the ping attempt either fails with that reply or times out completely, every single time. Also, if I delete the DNS entries from adapter IPv4 config completely and then do "ipconfig /all" from command line, they seem to get magically filled in by themselves, with one slight change: 10.138.1.1 <-- (note the 138 instead of 139) 10.139.1.2 ..And everything continues to work fine in terms of connectivity. The Qubes Network Setup service is definitely disabled and stopped, so I am not quite sure how that auto-fill is occurring. I can also use other externally operated DNS like: 8.8.8.8 4.4.4.4 1.1.1.1 And it gets saved correctly in ipconfig and also produces full connectivity. I am going to try garbage values and see what happens, but it almost seems like the HVM is somehow routing its DNS queries automatically regardless of entered values, but maybe not. > I've also added a note about QWT 4 breaking *new* HVMs (I thought the > breakage was only when updating from QWT3 to QWT4). It seems it's a > hit-or-miss process, IIRC some users managed to have QWT4 running. Hit or miss, yes... possibly partially related to the state of updates in Windows 7 at the time QWT4 is installed. Those reporting success (in this thread and issue 3585) seem to have installed updates into Win7 first before installing the guest tools. In my case I tried installing QWT4 into a fresh Win7 SP1 with no updates applied yet, and it broke completely. So that might be the crux, though it's just a hypothesis. At some point if I have the 2-3 days needed to fully update Windows 7, I may try removing QWT3 and installing QWT4 to see what happens. Of course I will try this in a clone, since I have no idea how easy or difficult it actually is to uninstall QWT3223 cleanly, and it's far more likely I'll break something in the attempt. Is it just a question of selecting "Remove" from the internal Win7 "Add/Remove Programs", and then installing QWT4 anew? Or is there a more elaborate procedure required? -- 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/4d67dd7f-89fe-472d-9f3f-9735cf51fb20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
On Monday, November 12, 2018 at 1:52:44 PM UTC-5, Ivan Mitev wrote: > Hi, > Since you mention that the network is functional without QWT installed > there's probably an issue with your ip settings in the windows HVM. Make > sure that the IP you've manually configured in windows matches the one > assigned to the VM (in dom0, run `qvm-prefs vmname visible_ip`). > Also check that the ip/gateways/dns ips you've configured are properly > applied in the vm (`ipconfig /all` in a command prompt), it could be > that the "Qubes Network Setup" service is still active for some reason. > > Then, if everything looks OK, try to ping the VM's IP from the VM (this > should work), then the gateway, then the DNS IPs. I'll give this a try, thanks. So far in the Windows HVM I have not put any value under "gateway" because that is not mentioned in the instructions from Issue3585 above. Only IP address, Subnet mask, and DNS server fields are filled out. Default gateway is left empty. What value, if anything, should go under Gateway in the VM? The ip address shown by Qubes as belonging to the network-providing VM itself, ie Sys-Net or Sys-Firewall, namely 10.137.0.6 ? Or something else? Also, I am presuming the values listed for DNS servers are universal constants at the moment in Qubes 4, meaning 10.139.1.1 and 10.139.1.2 are absolute values for all installations and not dynamically dependent on specific configuration? -- 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/b43e8281-bad6-49a6-9007-2ed6a9c758e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
Here's what I've done so far:
Created a new Windows 7 SP1 HVM by using an .iso as I've done many times
successfully in the past on Qubes 3.2. Everything works fine, HVM is created
and runs correctly, internet connection is intact and functioning as expected.
Downloaded Qubes Windows Tools 4.0 and installed them into the HVM as per
documentation. Installation of QWT 4.0 completely *breaks* HVM and places it
into a totally irrecoverable state, as detailed here near the top:
https://github.com/QubesOS/qubes-issues/issues/3585
"at the following reboot, windows fails to boot and tries to repair files,
which as usual doesn't fix anything (the VM might boot at some point, without
the tools installed)"
Deleted the HVM, and started over from scratch by creating a new one. This
time, I installed Qubes Windows Tools version 3.2.2.3 instead of 4.0. That
worked perfectly fine, and the usual QWT-enhanced Windows HVM appeared with
full screen resolution, mouse pointer integration etc. Except, the internet
connection suddenly completely went offline and stopped functioning.
As per Issue 1 again from the same source, I tried the following instructions:
https://github.com/QubesOS/qubes-issues/issues/3585
Issue 1 - Networking isn't set up properly
The PV adapter's status is stuck at "Identifying"; pinging an ip works but
pinging a host fails, indicating a problem with DNS resolution. A tcpdump on
sys-firewall indeed shows that DNS requests are sent to the gateway's ip and
are rejected. The reason is that in R4 VMs are now using the exposed
"/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use
/qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).
Workaround: disable the "Qubes Network Setup" service (with gui/msconfig, or sc
config "QubesNetworkSetup" start= disabled in a command prompt) and configure
the network manually.
Settings:
DNS{1,2}: 10.139.1.1, 10.139.1.2
Subnet: 255.255.255.0
IP: in dom0, qvm-prefs vmname ip will output the VM's ip. Caveat: a
cloned/restored/... VM will likely have its IP changed so you'll have to
remember to update your network settings.
Implementing this attempted fix did *NOT* solve the problem, and the lack of
internet connectivity persists despite doing everything suggested. All other
VMs on the system have their internet connections working perfectly fine.
What are the next suggested steps to try? Should that fix have worked
regardless of using QWT 3.2.2.3 rather than 4.0, as long as the base system is
Qubes 4 instead of 3.2? If not, what options should I be using for my specific
situation? What do I do from here to get internet connectivity back?
--
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/a0504ed0-b571-40ce-ad9c-e4d8bd868c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
On Friday, November 9, 2018 at 3:42:40 PM UTC-5, alrojs wrote: > On Friday, October 5, 2018 at 11:48:01 AM UTC-7, Otto Kratik wrote: > > Qubes 3.2 > > > > Ever since a routine qubes-dom0-update was interrupted in the middle of the > > upgrade process, I can no longer run any updates on dom0. Instead I see the > > message: > > > > "Failed to synchronize cache for repo 'qubes-dom0-cached', disabling." > > > > ..in response to most commands that I attempt through > > yum/dnf/qubes-dom0-update to try fixing it. None of the usual approaches > > like --clean have been successful. > > > > What should I try from here to correct the issue? > > > > Thanks, > > Otto > > hello, > > I'm having the same issue. > > dom0 fails to synchronize cache for repo 'qubes-dom0-current' and > 'qubes-template-itl'. > > I've tried the steps recommended above and the proxy seems to be opperating > fine but whenever i try to update i am unable to. > > My main goal is the get qubes-u2f working which wont' because it fails to > synchronize. It's been a few weeks, but I believe the synchronize cache issue resolved itself the next time I forcibly installed something on dom0 using yum/dnf or qubes-dom0-update. I don't remember which package I installed or reinstalled, but forcing it to perform an install from a repo that *was* working seemed to refresh everything again. In my case the stuck pseudo-repo was the local qubes-dom0-cached one, so if qubes-dom-current isn't working I'm not sure the same procedure will be workable. I'd go back and check my command line history, but I ended up having to reinstall the entire OS shortly afterward since the glitch that caused the entire situation in the first place (interrupted kernel update) was irrecoverable. -- 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/13d9c2fa-3080-46f4-87e9-bd5ca833d986%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Unable to get any DVM app to ever launch
On Tuesday, November 6, 2018 at 10:29:49 AM UTC-5, unman wrote: > On Mon, Nov 05, 2018 at 01:56:00PM -0800, Otto Kratik wrote: > > > Thanks for the extensive troubleshooting. > > > > > > It looks as if there's a problem *either* with the service *or* with the > > > desktop files on fedoratest. > > > Can you check the contents of /etc/qubes/rpc/policy/qubes.StartApp to > > > make sure that you dont have a "deny" statement at the top of that file? > > > You could temporarily insert a line at the top: > > > dom0 $anyvm allow > > > $anyvm $anyvm allow > > > > > > Just concentrate on using: > > > qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+firefox (or > > > gedit) > > > Check the log file in /var/log/qubes : you should see a log created for > > > whatever dispVM is atrted and qubes.log updated. > > > > > > unman > > > > > > So during testing, even though I'd stopped all other VMs from running, I > > started noticing some odd slowdowns and other memory-related issues, > > wondered if RAM shortage was affecting my attempts, and decided to reboot > > and try again from scratch with no autostart VMs enabled. > > > > After that, I am now able to run pretty much any app in a Debian or Whonix > > based DispVM without issue. In Fedora based DVMs, some apps like Firefox, > > Filezilla, Calculator etc all run fine from the DVM menu, while other apps > > such as Gedit and Nautilus/Files simply don't seem to want to act as the > > "launch leaders" for DispvM's. > > > > Meaning, the DispVM gets launched, but those apps don't open, and then the > > DVM halts again a minute or so later, as previously described. If I launch > > Firefox instead first in a Fedora DVM, and then from the widget select "Run > > terminal" for that very same already-open DVM, I can then launch Gedit or > > Nautilus or any other app from the command line without any problem. But > > those apps won't open as the initial "launch-apps" for Fedora DVMs. > > > > By contrast, in Debian DVM's I can launch KWrite or Dolphin or whatever > > other equivalents easily, a well as Firefox or Tor Browser, and so far > > haven't found one that refuses to launch. > > > > Thus it seems like a bit of an interoperability quirk between Fedora26 and > > the DVM system, so far as I can tell. Results are the same whether trying > > from gui menu or dom0 command line, though admittedly with some apps like > > Gedit, I am unsure which of the following I should be typing: > > > > qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+gedit > > qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+org.gnome.gedit > > qvm-run -a --service --dispvm=fedoratest -- "qubes.StartApp+Text Editor" > > > > All of them fail in the same way, however.. so I'm not sure it makes much > > difference. > > > > Out of curiosity for comparison, are you able to launch Gedit or > > Nautilus/Files in a Fedora based DVM without issue, as the initial > > launch-app either from the menu or command line? > > > > I'm glad that some progress is being made. > I wonder if there's some issue with the desktop files in Fedora which > are preventing those applications from running? Those symptoms are > exactly those that fit with problems with the desktop files. > I dont have Fedora here to test, I'm afraid: Debian and BSD only. > > If you open a Fedora based qube, do the applications work if you try to > open files that would use them? I mean create text file, and then double > click on it in nautilus, etc etc > > unman If I run a fedora based qube normally, all of those applications open and run completely fine, whether I launch them on their own or open files that would naturally use them as their default handlers. Gedit and Nautilus etc are perfectly willing to act at launch-starters for a fedora based qube, as long as that qube is a regular AppVM and not a DVM-template. It is *only* when trying to open those apps as launch-starters from DVM templates (such as fedora-26-DVM) that they refuse to open. Other apps like Firefox/Calculator open fine as launch-starters for fedora DVM's, and once open, I can run-terminal from the widget for that Disp8375 or whatever, and from that terminal launch Gedit or Nautilus or whatever, no problem. Only trying to start a new fedora based DVM with some specific apps (gedit, nautilus) fails, with the Disp7473 halting a minute or so after it initially launches, without ever opening the requested app. Debian/Whonix DVM's seem
Re: [qubes-users] Cannot boot new HVM from cdrom. What is the new command?
Thanks, Unman and Ivan.. I ended up trying: qvm-start --cdrom=dom0:/dev/sr0 win7 ..and it worked, since that's where my CD drive was mounted as. I'll give the suggested syntax a try as well, and imagine it will succeed also. The transition from Qubes 3.2 to 4.0 has been full of hiccups both large and small due to various scattered system changes like this one, and I appreciate the assistance here. -- 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/e1904a55-e27d-4703-b79c-e890a72c59ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Unable to get any DVM app to ever launch
On Sunday, November 4, 2018 at 8:22:33 AM UTC-5, unman wrote: > On Sat, Nov 03, 2018 at 03:14:00PM -0700, Otto Kratik wrote: > > On Thursday, November 1, 2018 at 10:13:36 AM UTC-4, unman wrote: > > > On Wed, Oct 31, 2018 at 12:27:06PM -0700, Otto Kratik wrote: > > > > On Wednesday, October 31, 2018 at 7:49:43 AM UTC-4, awokd wrote: > > > > > Otto Kratik wrote on 10/31/18 2:28 AM: > > > > > > Qubes 4.0 > > > > > > > > > > > > > > > > > > Whenever attempting to launch an app in a DVM, the result is always > > > > > > the same. The popup message comes up saying "Disp1234 has started", > > > > > > and then nothing happens. Then about two minutes later, another > > > > > > popup says "Disp1234 has halted". No app ever launches. > > > > > > > > > > > > It doesn't matter what app I try.. xterm, konsole, firefox, > > > > > > dolphin, thunar, tor browser, gedit, kwrite etc. Always the same > > > > > > behavior. Also doesn't matter if I try from Q Menu shortcuts, > > > > > > command line in dom0, command line in another AppVM.. no > > > > > > difference. Just the same type of message in the terminal, says > > > > > > it's launching, then shuts down two minutes later with no output. > > > > > > > > > > > > Doesn't make a difference either if I try to open a file in a DVM > > > > > > or just straight launching an app. Nothing ever opens. Launching > > > > > > apps regularly from normal AppVM's works perfectly all the time, > > > > > > just not DVM's. > > > > > > > > > > > > Slight correction: About 1 in 10 times, launching Firefox from a > > > > > > Fedora-template-based DVM succeeds. The other 9 times it fails. All > > > > > > other apps fail 10 out of 10 times. And launching any app > > > > > > (including Firefox) from a Whonix-ws-14-template-based DVM also > > > > > > fails 100% of the time as described above. > > > > > > > > > > > > How is this issue best investigated and resolved? > > > > > > > > > > > > > > > > Have you upgraded to Whonix 14 or customized the DVM? Try removing it > > > > > completely (you might have to temporarily change DVM defaults to a > > > > > different template), then recreating it with `sudo qubesctl state.sls > > > > > qvm.whonix-ws-14-dvm`. If that doesn't work, see > > > > > https://www.whonix.org/wiki/Qubes/Uninstall and > > > > > https://www.whonix.org/wiki/Qubes/Install to completely uninstall and > > > > > reinstall the workstation template and DVM. You can skip the gateway > > > > > steps if you've already upgraded it to 14 since it sounds like that's > > > > > still working. > > > > > > > > It's a fresh install of Qubes 4 with freshly downloaded/installed > > > > Whonix 14/DVM templates using the salt/qubesctl command mentioned above > > > > and in the documentation. No customisations. So I doubt reinstalling > > > > would have any effect. > > > > > > > > Whonix-ws-14 template works perfectly fine for running apps the normal > > > > way, from AppVMs based upon it. No issue whatsoever. Only running them > > > > from whonix-ws-14-dvm causes trouble. > > > > > > > > However as I said, even trying to run apps from Fedora-26-dvm also > > > > fails the majority of the time, so I'm not even convinced it's a whonix > > > > specific issue. Rather a DVM one in general. > > > > > > > > Any other things to try? > > > > > > > > > > I would try this: > > > Install all updates in dom0 and qubes. > > > Create a new Fedora based qube. > > > Confirm you can run programs as expected. > > > Make it a template for dispvms, using qvm-prefs. > > > Close all unnecessary qubes. > > > Then , at command line, start to test running programs in dispvms based > > > on the qube. > > > > > > Generally , the command should be: > > > qvm-run --dispvm > > > > > > That's the most basic form. > > > Anything you can run using qvm-run should work in > > > disposableVM based on qube (except gnome-terminal) > > > > >
[qubes-users] Cannot boot new HVM from cdrom. What is the new command?
Previously when creating a new Windows HVM on Qubes 3.2, to boot from a physical CD in the physical CD drive I would do: qvm-start --cdrom=/dev/cdrom win7 When I try that in Qubes 4.0, I get an error that starts with "Traceback" and ends with "Not enough values to unpack (expected 2, got 1)." What am I doing wrong? What is the new command to make this work in Qubes 4? -- 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/f991bcb7-633d-4251-837c-bfd795dc4402%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Unable to get any DVM app to ever launch
On Thursday, November 1, 2018 at 10:13:36 AM UTC-4, unman wrote: > On Wed, Oct 31, 2018 at 12:27:06PM -0700, Otto Kratik wrote: > > On Wednesday, October 31, 2018 at 7:49:43 AM UTC-4, awokd wrote: > > > Otto Kratik wrote on 10/31/18 2:28 AM: > > > > Qubes 4.0 > > > > > > > > > > > > Whenever attempting to launch an app in a DVM, the result is always the > > > > same. The popup message comes up saying "Disp1234 has started", and > > > > then nothing happens. Then about two minutes later, another popup says > > > > "Disp1234 has halted". No app ever launches. > > > > > > > > It doesn't matter what app I try.. xterm, konsole, firefox, dolphin, > > > > thunar, tor browser, gedit, kwrite etc. Always the same behavior. Also > > > > doesn't matter if I try from Q Menu shortcuts, command line in dom0, > > > > command line in another AppVM.. no difference. Just the same type of > > > > message in the terminal, says it's launching, then shuts down two > > > > minutes later with no output. > > > > > > > > Doesn't make a difference either if I try to open a file in a DVM or > > > > just straight launching an app. Nothing ever opens. Launching apps > > > > regularly from normal AppVM's works perfectly all the time, just not > > > > DVM's. > > > > > > > > Slight correction: About 1 in 10 times, launching Firefox from a > > > > Fedora-template-based DVM succeeds. The other 9 times it fails. All > > > > other apps fail 10 out of 10 times. And launching any app (including > > > > Firefox) from a Whonix-ws-14-template-based DVM also fails 100% of the > > > > time as described above. > > > > > > > > How is this issue best investigated and resolved? > > > > > > > > > > Have you upgraded to Whonix 14 or customized the DVM? Try removing it > > > completely (you might have to temporarily change DVM defaults to a > > > different template), then recreating it with `sudo qubesctl state.sls > > > qvm.whonix-ws-14-dvm`. If that doesn't work, see > > > https://www.whonix.org/wiki/Qubes/Uninstall and > > > https://www.whonix.org/wiki/Qubes/Install to completely uninstall and > > > reinstall the workstation template and DVM. You can skip the gateway > > > steps if you've already upgraded it to 14 since it sounds like that's > > > still working. > > > > It's a fresh install of Qubes 4 with freshly downloaded/installed Whonix > > 14/DVM templates using the salt/qubesctl command mentioned above and in the > > documentation. No customisations. So I doubt reinstalling would have any > > effect. > > > > Whonix-ws-14 template works perfectly fine for running apps the normal way, > > from AppVMs based upon it. No issue whatsoever. Only running them from > > whonix-ws-14-dvm causes trouble. > > > > However as I said, even trying to run apps from Fedora-26-dvm also fails > > the majority of the time, so I'm not even convinced it's a whonix specific > > issue. Rather a DVM one in general. > > > > Any other things to try? > > > > I would try this: > Install all updates in dom0 and qubes. > Create a new Fedora based qube. > Confirm you can run programs as expected. > Make it a template for dispvms, using qvm-prefs. > Close all unnecessary qubes. > Then , at command line, start to test running programs in dispvms based > on the qube. > > Generally , the command should be: > qvm-run --dispvm > > That's the most basic form. > Anything you can run using qvm-run should work in > disposableVM based on qube (except gnome-terminal) > > That will test the basic infrastructure. > > If all is good, start testing a more complex form: > qvm-run -a --service --dispvm= --qubes.StartApp+ > > here should have an associated desktop file. > Again, anything you can run using qvm-run --service should > work in > disposableVM based on the qube (except gnome-terminal) > > That will test the more complex infrastructure. > > If all's good, you can start testing different template based qubes, > including Whonix. If it's not good there's something fundamentally > broken. > > qvm-run *does* have -v option, but it doesn't generate verbose output. > > Check back when you have some results from testing. > > unman Hi, thanks for your detailed reply and suggestions. Here is what I have found: I created a new qube/AppVM based on the fedora26
Re: [qubes-users] Qubes 4: Unable to get any DVM app to ever launch
On Wednesday, October 31, 2018 at 7:49:43 AM UTC-4, awokd wrote: > Otto Kratik wrote on 10/31/18 2:28 AM: > > Qubes 4.0 > > > > > > Whenever attempting to launch an app in a DVM, the result is always the > > same. The popup message comes up saying "Disp1234 has started", and then > > nothing happens. Then about two minutes later, another popup says "Disp1234 > > has halted". No app ever launches. > > > > It doesn't matter what app I try.. xterm, konsole, firefox, dolphin, > > thunar, tor browser, gedit, kwrite etc. Always the same behavior. Also > > doesn't matter if I try from Q Menu shortcuts, command line in dom0, > > command line in another AppVM.. no difference. Just the same type of > > message in the terminal, says it's launching, then shuts down two minutes > > later with no output. > > > > Doesn't make a difference either if I try to open a file in a DVM or just > > straight launching an app. Nothing ever opens. Launching apps regularly > > from normal AppVM's works perfectly all the time, just not DVM's. > > > > Slight correction: About 1 in 10 times, launching Firefox from a > > Fedora-template-based DVM succeeds. The other 9 times it fails. All other > > apps fail 10 out of 10 times. And launching any app (including Firefox) > > from a Whonix-ws-14-template-based DVM also fails 100% of the time as > > described above. > > > > How is this issue best investigated and resolved? > > > > Have you upgraded to Whonix 14 or customized the DVM? Try removing it > completely (you might have to temporarily change DVM defaults to a > different template), then recreating it with `sudo qubesctl state.sls > qvm.whonix-ws-14-dvm`. If that doesn't work, see > https://www.whonix.org/wiki/Qubes/Uninstall and > https://www.whonix.org/wiki/Qubes/Install to completely uninstall and > reinstall the workstation template and DVM. You can skip the gateway > steps if you've already upgraded it to 14 since it sounds like that's > still working. It's a fresh install of Qubes 4 with freshly downloaded/installed Whonix 14/DVM templates using the salt/qubesctl command mentioned above and in the documentation. No customisations. So I doubt reinstalling would have any effect. Whonix-ws-14 template works perfectly fine for running apps the normal way, from AppVMs based upon it. No issue whatsoever. Only running them from whonix-ws-14-dvm causes trouble. However as I said, even trying to run apps from Fedora-26-dvm also fails the majority of the time, so I'm not even convinced it's a whonix specific issue. Rather a DVM one in general. Any other things to try? -- 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/4f599446-e980-4fd9-b457-9be0ef95d467%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4: Unable to get any DVM app to ever launch
Qubes 4.0 Whenever attempting to launch an app in a DVM, the result is always the same. The popup message comes up saying "Disp1234 has started", and then nothing happens. Then about two minutes later, another popup says "Disp1234 has halted". No app ever launches. It doesn't matter what app I try.. xterm, konsole, firefox, dolphin, thunar, tor browser, gedit, kwrite etc. Always the same behavior. Also doesn't matter if I try from Q Menu shortcuts, command line in dom0, command line in another AppVM.. no difference. Just the same type of message in the terminal, says it's launching, then shuts down two minutes later with no output. Doesn't make a difference either if I try to open a file in a DVM or just straight launching an app. Nothing ever opens. Launching apps regularly from normal AppVM's works perfectly all the time, just not DVM's. Slight correction: About 1 in 10 times, launching Firefox from a Fedora-template-based DVM succeeds. The other 9 times it fails. All other apps fail 10 out of 10 times. And launching any app (including Firefox) from a Whonix-ws-14-template-based DVM also fails 100% of the time as described above. How is this issue best investigated and resolved? -- 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/c5005b71-ad67-4d4c-9378-3ab0fc085895%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Syntax Error in qubes.GetAppmenus during every package install
On Saturday, October 27, 2018 at 10:43:15 PM UTC-4, unman wrote:
> On Sat, Oct 27, 2018 at 07:39:10PM -0700, Otto Kratik wrote:
> > Qubes 4.0
> >
> > Any time I use apt-get to install software into a debian-type TemplateVM
> > (Debian-9, Whonix GW or WS), I always get the following error during the
> > installation phase:
> >
> > Processing triggers for qubes-core-agent (4.0.37-1+deb9u1) ...
> >
> > /etc/qubes-rpc/qubes.GetAppmenus: 20: /etc/qubes-rpc/qubes.GetAppmenus:
> > Syntax error: "(" unexpected
> >
> >
> > As a result, the software is installed correctly but the App menu shortcuts
> > are not sent to the dom0 menus or Applications List of the relevant
> > Template or related AppVMs, and I have to do qvm-sync-appmenus manually
> > from the dom0 terminal every time. That command works fine with no errors,
> > and the new shortcut entries appear as expected.
> >
> > Installing new software packages in Fedora templates work fine and do not
> > cause any issues, it is only Debian type templates that are affected.
> >
> > What is causing this issue and how is it corrected?
> >
>
> It's a known issue, (#4417) and the fix is already in the pipeline.
> You can work around by calling qvm-sync-appmenus from the
> command line.
>
> unman
Thanks, I'm glad at least to hear that it's universal and not a specific fault
related to my particular installation. I will just wait for the fix and use the
workaround in the meantime.
Appreciate the quick and helpful reply.
--
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/b05a6c0f-3ede-4b91-a34c-c25b9939a818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4: Syntax Error in qubes.GetAppmenus during every package install
Qubes 4.0
Any time I use apt-get to install software into a debian-type TemplateVM
(Debian-9, Whonix GW or WS), I always get the following error during the
installation phase:
Processing triggers for qubes-core-agent (4.0.37-1+deb9u1) ...
/etc/qubes-rpc/qubes.GetAppmenus: 20: /etc/qubes-rpc/qubes.GetAppmenus: Syntax
error: "(" unexpected
As a result, the software is installed correctly but the App menu shortcuts are
not sent to the dom0 menus or Applications List of the relevant Template or
related AppVMs, and I have to do qvm-sync-appmenus manually from the dom0
terminal every time. That command works fine with no errors, and the new
shortcut entries appear as expected.
Installing new software packages in Fedora templates work fine and do not cause
any issues, it is only Debian type templates that are affected.
What is causing this issue and how is it corrected?
--
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/ac43deca-a3fd-4beb-8c3c-f915867464f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
On Friday, October 5, 2018 at 3:26:51 PM UTC-4, Ivan Mitev wrote: > Every time I had a "failed to synchronize..." erorr it was because there > was a problem with the proxy in sys-net. Restarting it usually did the > trick, eg: > > sudo systemctl restart qubes-updates-proxy.service > > (run the command sys-net ; the syntax is for R4.0, I don't have R3.2 to > test but it shouldn't be too different). > > Check the proxy's status with > > sudo systemctl status qubes-updates-proxy.service Thanks for your help and suggestion. I just tried both of those commands and sys-net reports the update proxy is working perfectly, however there is no change in the result from dom0 and I get the same error message as before. The original interruption glitch happened after dom0 had already successfully downloaded all updates, but during the upgrade/install of those new packages. Ever since then, this issue has occurred. So I am thinking something local has gotten messed up rather than a connection issue. Any other ideas I should try in order to fix this? Thanks... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ce59a818-cea9-4f59-a782-9557d8b48273%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
Qubes 3.2 Ever since a routine qubes-dom0-update was interrupted in the middle of the upgrade process, I can no longer run any updates on dom0. Instead I see the message: "Failed to synchronize cache for repo 'qubes-dom0-cached', disabling." ..in response to most commands that I attempt through yum/dnf/qubes-dom0-update to try fixing it. None of the usual approaches like --clean have been successful. What should I try from here to correct the issue? Thanks, Otto -- 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/7f9c6682-13b8-41fc-9338-8df3e6aff04e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Help: Qubes dom0 update interrupted, kernel panic resulted
Just to clarify, the original abort/glitch happened after all updates were successfully *downloaded*, but during the upgrade/install process itself. At present when I try to do: sudo dnf check-update I get: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling. I have already tried doing: qubes-dom0-update --clean and it has no effect on the issue. I believe some packages are still "stuck" in the local qubes-dom0-cached repo, but I have no idea how go about fixing this issue and getting back on track. Could someone please advise next steps to get this resolved? Thanks.. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1b952462-7461-4559-82a1-8be13e2792e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Help: Qubes dom0 update interrupted, kernel panic resulted
Qubes 3.2 Last night I was updating dom0, but in the middle of the update I accidentally hit some keys on the keyboard, which I now in hindsight realize must have included Ctrl-Z. At that point the update just stopped and froze at item 13/42 which just so happened to be qubes kernel 4.14.67-1. I tried to exit the console but was told there were stopped jobs (update was backgrounded no doubt). Not knowing any better in the moment, I force restarted my computer and retried the dom0 update. It did successfully re-download and install the new kernel, but also said that was the only new thing to be installed, and did not make any attempt to pick up where it left off and download the other remaining items, 14-through-42 of 42. I did qubes-dom0-update a few more times with the same result - it says there's nothing new available. The system seemed to think and act as though the other packages had all already been updated/installed, even though they hadn't. The next time I tried a reboot, the boot-up failed with a kernel panic and went into a boot loop. Choosing advanced options and using the older kernel 4.14.57-1 allowed me to boot up, and here I am. So what should I do from here? Is there any way to force the dom0 update to refresh or redo or reset, so that it gets everything it needs to function correctly with the newer kernel? I'm not sure what command to use or what file(s) to edit in order to forcibly instruct it to re-download and install all possible missing packages, when the normal qubes-dom0-update insists there's no update available. Right now I have a half-broken system and am not sure how to proceed. Any help would be very greatly appreciated.. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0d3a9655-c941-47f4-82ad-6c987e37d8d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Migrating TemplateVMs and AppVMs from Qubes 3.2 to 4.0
Generally speaking, once the full release version of Qubes R4.0 is published, and due to the completely re-worked infrastructure underlying how VMs function in the newer edition versus the old, will it still be at all possible to backup-and-restore either Templates or AppVM's from 3.2 over to 4.0, or is that a completely hopeless cause and everything will have to be created again from scratch? What about specifically a Whonix-Workstation where I have tons of software installed and customized, and don't want to redo from start. Can it be migrated through backup-and-restore, or has all compatibility between versions 3.2 and 4.0 been lost already? -- 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/534128e2-dd53-4cde-aed7-cb54808dc027%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?
A while back I used an extremely simple fix for a similar issue, which may or may not work in this specific situation described. In my case I had assigned a network card/controller to the Sys-Net VM, which Qubes hated so much compatibility-wise that it subsequently refused to boot altogether, simply because attempt to initialize that net card caused such catastrophic failure on startup that the entire OS became non-startable. However, since devices assigned to VM's have specific serial identifiers that Qubes is looking for on bootup to assign to chosen VM, and since Qubes was in this case itself installed on a flash drive, it stood to reason that by simply booting it on a completely different laptop which did not have that relevant network card and serial number present, Qubes would simply ignore the requested assignment and boot normally, with no network card (not even the one in the second laptop) assigned to Sys-net upon boot completion. And this is exactly what happened. >From there, with system successfully booted on second laptop without problem >card, it is/was still necessary to use Qubes Manager to graphically edit >settings for that Sys-net VM, and look in its list of assigned devices, which >*appears* empty but is not really (because a non-present device is still >assigned to it "invisibly"). Because of this, it was needed to click the >"unassign all" button (two arrows pointing left: << ) and then save settings, >so that even non-visible/present devices (the problem card) became unassigned >to that Sys-Net VM. After that, I shut down and placed Qubes flash drive back in original laptop, booted, and everything worked fine. Problem network card was back to Dom0 and not assigned to Sys-Net, and all worked fine (with no networking, obviously, but still usable system). This approach may or may not work for de-assigning USB controller from USB-VM, since when booted on a different laptop, that specific USB controller won't be found, and the assign request will be ignored, and you can unassign-all-devices from USB-VM on that second laptop, before shutting down and then booting again on original machine. Like I said, possibly this tactic won't work for some unpredictable reason, but it worked in my case when network card was the "accidentally" assigned device causing non-startable system. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9e824b5b-bae7-4e15-b49a-d5191adfb453%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Removing unwanted menu items under xfce?
I recently did a fresh install of Qubes R3.2, and then proceeded to restore several VM's from my previous installation, among them a Windows 7 HVM. I also installed qubes-windows-tools, which I also previously had installed. As a result of that restore/install, xfce has placed about 50 win7-related app shortcuts in both the win7 sub-menu of the start menu (expected and desired) and also simultaneously into the "System Tools" sub-menu of the start menu (not wanted), intermingled among the normal items one usually expects to find there (terminal, file manager etc). KDE is not affected, and logging into that environment shows the proper expected behavior: win7 shortcuts in the win7 sub-menu only, and system tools shortcuts where they belong. What is the easiest way to edit the entries appearing under the System Tools sub-menu of xfce, so as to remove the approximately 50 win7-related shortcuts that I don't want appearing there? Thanks.. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/45621212-9323-4ec7-b168-248a88c0e2eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Dom0 (System tools) shortcuts suddenly disappeared
On Friday, January 6, 2017 at 5:05:38 AM UTC-5, Ángel wrote: > > Do you still have those files listing the .desktop entries that should > be shown in the menu? Seeing no other recourse, I opted to re-install my entire operating system in order to correct the menu issue, prior to having a chance to check this specific item. Thank you for the suggestion though, nonetheless. -- 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/9804cb5d-4eb5-4402-bc97-d20f70e7f41f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
On Wednesday, January 4, 2017 at 1:01:49 PM UTC-5, Unman wrote: > I'd expect to see the .desktop files. > Here's a sample - save it as xfce4-terminal.desktop: Thanks for your efforts to assist with this. I copied the text you posted and saved it as a .desktop text file as you suggested, and then moved it into the /usr/share/applications folder of dom0, and then rebooted. It doesn't seem to have had any effect, though it's hard to tell since the xfce "start menu" doesn't appear to even have a "system tools" menu entry to begin with, unlike the kde plasma one. There is a "System" menu at the very top, but that contains a whole gigantic mess of shortcuts from every VM I have, all jumbled together in one big chaotic list. However, clumped together midway through that menu are the few dom0 shortcuts I still have (apper, DispVM Browser etc) and there doesn't seem to be any new item referencing the xfce4 terminal. Is there anything else I can try at this point? I've noticed that I keep getting notified that Qubes Dom0 updates are available, but whenever I run sudo qubes-dom0-update it reports no packages to download, nothing to update. Any other ideas or suggestions would be more than welcome. Thanks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0aa64fbc-ea7b-458d-8b32-1de0147f1475%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
On Tuesday, January 3, 2017 at 8:55:58 PM UTC-5, Unman wrote: > On Tue, Jan 03, 2017 at 04:12:28PM -0800, Otto Kratik wrote: > > On Tuesday, January 3, 2017 at 6:02:09 PM UTC-5, Marek Marczykowski-Górecki > > > > > > > > Try running `xdg-desktop-menu forceupdate`. > > > > Ran it as su from dom0 terminal. Command was accepted, but no noticeable > > effect or change, or output. > > > > Have you checked the menu files? > > For xfce, in /etc/xdg/menus/xfce-applications.menu you should have a > section with System that references > qubes-System-Tools.directory > There should be an section containing > and Excludes for X-Qubes_VM and X-Xfce-Toplevel > > The actual desktop files should be in /usr/share/applications: check > that they are there. > Confirm the Categories of a sample desktop file. > > I can't imagine that these have been deleted - if they have then you don't > need to reinstall, just replace the missing files. > > let us know what you find (or not, as the case may be). Here are the contents of the xfce-applications.menu file: ** http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd;> Xfce X-Xfce-Toplevel exo-file-manager.desktop exo-mail-reader.desktop exo-web-browser.desktop /usr/local/share/applications xfce4-run.desktop exo-terminal-emulator.desktop System xfce4-about.desktop xfce4-session-logout.desktop System qubes-System-Tools.directory X-Xfce-Toplevel X-Qubes-VM xfce-settings-manager.desktop *** In /usr/share/applications I see: kde (folfer) kde4 (folder) screensavers (folder) gnome-mimeapps.list kde-mimeapps.list mimeapps.list mineinfo.cache xfce-mimeapps.list Does that reveal anything? What should I be looking for within this location further? Thanks... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4caa2ffd-447d-491d-afe6-f20adf77114e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
On Tuesday, January 3, 2017 at 6:02:09 PM UTC-5, Marek Marczykowski-Górecki > > Try running `xdg-desktop-menu forceupdate`. Ran it as su from dom0 terminal. Command was accepted, but no noticeable effect or change, or output. -- 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/d9ecc53c-b93d-4dfb-ba42-b5146d6ef987%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
On Tuesday, January 3, 2017 at 4:32:11 PM UTC-5, Andrew David Wong wrote: > I'm afraid I don't have any special insight into this problem. (I > vaguely recall that it happened to me once on 3.1, then I think I > ignored the problem and it eventually reverted itself somehow.) > > However, it occurs to me that what you're asking about is primarily a > KDE issue, and the information you seek should, in principle, be > available from a KDE source (docs, devs) or even Fedora or another > distro that uses KDE. To clarify: The *cause* may be Qubes-related (I > have no idea), but the default file/list for KDE System Tools should > probably be the same as in non-Qubes KDE installations. At least, it's > worth checking. The file may possibly be in the same place, but of course in the case of Qubes it is a customized one containing entries like "Qubes VM Manager" etc, so I would need that specific one. I don't know the default location. Also as noted however, it makes no difference whether I use Xfce or KDE. In either case I have no menu item available anywhere for "Qubes VM Manager" which I normally would, so it is a pan-desktop-environment issue, likely related to Qubes itself rather than one of the DE's. So far I have not found any solution to this, and am looking at a complete system re-install in order to fix one single interface issue. -- 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/c49af7bb-2d47-4783-85c5-a9d1b72205ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Dom0 (System tools) shortcuts suddenly disappeared
As one approach, is there any command that will force a re-download and re-install of ALL dom0 packages and components, despite cache showing them as already up to date? If one or more elements are broken or corrupted, a refresh update might do the trick. Similar to if I'd made a dom0 backup and wanted to restore it completely. But since I don't have such a backup, can dom0 be effectively restored with a terminal command that will force-refresh everything from the repository? -- 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/8ada30a0-635b-4f0d-a0b6-1efea184a708%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
On Tuesday, January 3, 2017 at 6:54:24 AM UTC-5, Fred wrote: > I can't help but I had this happen once using Xfce as the desktop. All > my 'start menu' disappeared bar a few. It happened to me at least once before under R3.1 as well, also randomly with no obvious or apparent cause. The System Tools menu items stayed gone for several weeks, then one day after new Dom0 updates they magically re-appeared again, with no explanation. I can also confirm that at the login screen if I choose xfce as the desktop environment, the missing shortcut issue still persists, so it isn't an intrinsic KDE thing indeed, as surmised. On a related note, I'm not even sure whether entries like "DispVM: Web Browser" are meant to appear under System Tools in R3.2, or if that is a menu glitch as well. Previously DispVM had its own top-level menu entry like any other AppVM, under which different app shortcuts appeared, so I don't know if something else has gone wrong. Is there a text file somewhere in Dom0, from which the System Tools menu obtains its default list of items? And if so, is it possible for someone with a functioning menu to "dump" the contents of that file here in this thread, so that I can copy and paste them into my presumably broken source file here, if such a thing is even possible? > I re-installed. Possibly a bug then in this case? I would really, really, really like to avoid having to re-install my entire operating system just to fix some missing menu entries, especially since it could presumably happen again at any given time thereafter. No other template or app vm's are affected, only Dom0. Surely there must be some alternative way to fix this issue, without resorting to ssuch drastic measures. Anyone? -- 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/4224ce3a-0cf9-4b11-abd9-824ee30f88b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Dom0 (System tools) shortcuts suddenly disappeared
Is there any way to easily refresh/restore the System Tools shortcuts, without having to add each one back manually in some obscure way? I don't even remember what all the normal items under that menu are, but they suddenly just vanished without warning or explanation, and I have no idea whatsoever how to get them back. Can anyone please help? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f2090ac-fd63-4cd6-89e5-2946e862d58e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Dom0 (System tools) shortcuts suddenly disappeared
I am using Qubes R3.2. Suddenly almost all of the KDE shortcuts usually found under applications-> system tools have completely vanished. I have no konsole, file manager, system settings etc. Only four remain: DispVM: Terminal DispVM: Web Browser Screen Capture Program Software Management Everything else is gone. They were there one minute, and then gone the next. I have performed Dom0 updates and rebooted afterward to see if it fixed the issue, without success. What is the recommended course of action? -- 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/d2bf0987-dc29-429b-ad85-0ea589f196c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fullscreen mode and/or single mouse pointer with Linux HVM?
On Wednesday, September 21, 2016 at 9:03:30 PM UTC-4, Andrew David Wong wrote: > Since your question is about the functional or behavior differences > between TemplateVMs and HVMs, I take it that what you're really > interested in is the practical difference between using TemplateVMs and > StandaloneVMs as VMs which do not depend on any other VM for their root > filesystems. > > The only significant difference I'm aware of is that using a TemplateVM > allows you to retain the option of creating TemplateBasedVMs based on > this TemplateVM in the future, whereas a StandaloneVM does not. If you > one day decide that you'd like to have a TemplateBasedVMs based on your > StandaloneVM, you'll have to re-create it as a TemplateVM. There's no > (easy) way to turn a StandaloneVM into a TemplateVM. Your interpretation is correct, I am mainly interested in the practical differences between running either a TemplateVM or a StandaloneHVM as a self-contained VM that doesn't depend on another VM's root filesystem. As in my example, if I want a self-contained, non-dependent Debian VM it's far easier to just clone a Debian TemplateVM and use it independently as such, and thus get the single mouse-pointer desired, as opposed to creating an HVM and installing Debian there, and getting dual mouse pointers instead. If the two solutions are functionally the same, the first is more optimal. However one reason I ask is that I seem to have in fact noticed some behavioral differences I wouldn't have expected, based on the descriptions above. The example case is unfortunately too unique to be likely duplicable by others for testing, but here it is nonetheless. I purchased a Linux game that needs no installation, you just download it from the vendor website, unpack the tar.gz archive and run it from shell. At first run it asks you to input the license code received at the time of purchase, which is easy to do. After that, all future launches don't ask you to input the code again, as it's already saved and stored by the game. On normal standalone Linux systems (whether an HVM within Qubes or a truly separate bare-metal installation on another computer/drive) this works as expected. Enter the code once, game works smoothly forevermore. But on a TemplateVM, the code works for that session, but doesn't seem to "stick" or get saved next time around, and it has to be entered again each time the game is launched. While I'd understand and perhaps expect this if running from a TemplateBasedAppVM, since maybe the location where the game records the registration is on the rootFS and isn't remembered next time, I'm perplexed to see it occurring on a TemplateVM, which shouldn't have this issue saving data to rootFS if necessary - which isn't of course even the logical place for game data to be stored, as it should use a local directory like Home I would think. I've even made sure to run the game's launch command as sudo in case elevated permissions are needed to write the registration data permanently, but without any luck. As I said, this specific game issue is outside the scope of Qubes or its dev team to attempt to solve, but it does illustrate at least one behavioral difference between the two VM types. On a StandaloneHVM, the game registration is saved successfully as expected. On a TemplateVM, the registration is forgotten each time. To make things even more confusing, the registration is forgotten each and every time even within the *same session* of the TemplateVM being run. Shutdown and restart isn't necessary to trigger the problem. Launch game, enter code, proceed with game. Exit game, launch it again, and code is requested again, even though TemplateVM is still running continuously without interruption or restart. Thus, anything saved during session should still be preserved, and yet isn't. Again, not asking for a solution here, just describing the scenario that precipitated the issue. Could just be some odd quirk of the game itself. Who knows. -- 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/20acc1ae-ee6a-4cf1-9431-eb72e37dfe01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fullscreen mode and/or single mouse pointer with Linux HVM?
On Friday, September 16, 2016 at 4:44:10 PM UTC-4, Andrew David Wong wrote: > There's also a more general workaround for the screen resolution issue > https://www.qubes-os.org/doc/linux-hvm-tips/ Thanks Andrew. I was able to use the instructions on that linked page to fix the screen resolution as desired. Much appreciated. > (as well as a pointer regarding Qubes agents) I'm not currently familiar enough with the inner workings or code underlying Qubes Agents to take a casual shot at customising them, but it's good to know for future reference what would need to be tweaked in order to modify mouse pointer behavior. For now I'll just live with the dual pointers in standard Linux HVM's. > I think you (or someone else) would have to put in the coding work in > order to make this work in the desired way. However, a lot of work > has already been done on the Archlinux Template (which, I assume, > can be run as an HVM if desired, though I haven't tried it myself): > https://www.qubes-os.org/doc/templates/archlinux/ > Some work has also been done on an Ubuntu template: > https://www.qubes-os.org/doc/templates/ubuntu/ Generally speaking, is it the case that running apps directly from a TemplateVM (whether it's Debian, Fedora, Arch, Ubuntu) is functionally equivalent and identical to operating that template/distro as a self-contained standalone HVM? Meaning if I wanted a Debian HVM, it's just as easy to clone my Debian TemplateVM and treat it as an HVM, instead of creating an actual new HVM the classic way and then installing a Debian ISO? Is there any fundamental intrinsic difference between how a Template behaves if used in this fashion, and how a normal HVM would behave? -- 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/1d4e2a49-5856-4e1e-be7a-95b49df2825e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Fullscreen mode and/or single mouse pointer with Linux HVM?
With a Windows 7 HVM, initially upon creation it is a fixed small window size and shows two mouse pointers chasing each other within that HVM window. By installing Qubes Windows Tools, both of these limitations are removed. One single mouse pointer and full screen resolution are achieved - as well as seamless mode becoming available. My question is, can the same full window size and single mouse pointer objectives be achieved when using a Linux-based HVM, such as one in which Ubuntu for example is installed? As far as I know, there is no equivalent "Qubes Ubuntu Tools" which facilitates this. I know of course that regular Fedora/Debian/Whonix type PVM's based upon templates already do this perfectly, and I use them frequently for almost everything. I am asking specifically about an HVM for a special usage case. It doesn't have to be Ubuntu specifically, but it does have to be a Linux distro capable of running within an HVM under Qubes R3.1. Does any such option exist? -- 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/9555d756-45c6-4d07-8ea8-6d952e4a930b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes-OS 3.1 unusable on my HP 355 G2 Laptop
On Monday, May 23, 2016 at 4:08:42 PM UTC-4, Marek Marczykowski-Górecki wrote: > > Ah, sorry, wrong package name - for VM kernel it is > 'kernel-qubes-vm-3.18*' > Using this package name did indeed in fact allow me to install the older 3.18 kernel on my Qubes system, thank you. Interestingly it actually automatically changed/set the "default kernel" under VM Settings to this one upon completion of download and install, but it was easy enough to change this back centrally to 4.1.x and have all VM's acknowledge it again instantly upon startup. But I was surprised to see this auto-set behavior upon install. Unfortunately, the older kernel made no difference in the ability of Qubes 3.1 to work with my wifi card. In fact, no combination of various templates (fedora 21, 23 either R3.0 or R3.1 versions, Debian) or kernels allowed the wifi card to work properly under Qubes R3.1. And yet when I boot into my Qubes R3.0 installation (all my installations are on external flash media, not internal HD) on the very same laptop, the wifi card works flawlessly as always. Very strange that a forward upgrade to a newer version, would somehow completely break a previously existing functionality with a peripheral. If there are another suggestions that I'd be advised to try before giving up entirely, I'm all ears. I know that generally Qubes can be finicky about hardware environment, but this is a laptop/wireless-card that works perfectly under R3.0. Thanks again... -- 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/140c87e8-b002-444d-9aa2-c54dc1f501f7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
