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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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 lon
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
>
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
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:
> > >
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)."
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
>
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 "Disp12
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
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
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:
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
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
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
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
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
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,
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
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
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
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 forceup
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
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
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
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
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
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
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
>
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
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
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
44 matches
Mail list logo
