I'm referring to the feature that was developed as part of GSOC about a year
and a half ago. It involved tagging some files as being unsafe, and would cause
them to be opened in a dispvm by default.
Was that work ever merged? I've been looking forward to this feature for the
last year or so.
I installed qubes-template-fedora-29-minimial by running the usual command:
$ sudo qubes-dom0-update qubes-template-fedora-29-minimial
This worked, but I messed up the template itself when doing some
experimentation. So, I removed said template and attempted to reinstall it.
When I try to
When installing an operating system in a HVM, sometimes the disk image will not
be recognised (some specific exampled include Hurd and Haiku, and I believe the
same is true for ReactOS).
It seems as though Xen exposes the disk image using a mechanism that is not
recognised by these operating
After my most recently upgrade of dom0 and all templates on my Qubes 4
installation (two days ago), I started facing the following problem:
After booting the system, all networking is down. I traced the problem to
sys-firewall failing to start qubes-iptables:
=
On Saturday, 24 March 2018 21:14:10 UTC+8, Marek Marczykowski-Górecki wrote:
> I haven't seen this for a while (since closing that issue). Check
> `journalctl` for qmemman related entries when it happens. Especially
> there are reports about each VM needs and how much memory was really
>
Currently appmenus are only synchronised from the template. In other words,
applications that are installed in the template is available for selection when
choosing which applications to show in the menu.
If you have locally installed applications (installed in
/usr/local/share/applications),
(tested on a Dell Latitude E7470)
If I enable Intel Speedstep in the BIOS settings and boot the machine without
power plugged in, the CPU is incredibly slow (as in: It takes minutes to start
a VM). If I boot the computer with power plugged in, the machine is as fast as
I expect it to be.
On Tuesday, 20 March 2018 11:41:54 UTC+8, Elias Mårtenson wrote:
> If this happens again, are there any logs or anything like that that I can
> collect in order to make it easier to debug this issue?
I just had the bug again, and this time I decided to restart qubes.qmemman and
sure
I'm on Qubes 4, latest updated from testing as of today.
This is about this bug: https://github.com/QubesOS/qubes-issues/issues/3265
The issue is that memory balancing randomly stops working, and I haven't seen
this issue for a long time (months?) and I though it had been fixed.
That was until
On Saturday, 17 March 2018 23:40:11 UTC+8, Marek Marczykowski-Górecki wrote:
> This should be at least partially fixed by
> https://github.com/QubesOS/qubes-desktop-linux-manager/pull/18.
> The issue happens when VM change state while widget's menu is visible.
> The above does not fix that
On Monday, 12 March 2018 05:25:51 UTC+8, Travis Dean wrote:
> On Tuesday, March 6, 2018 at 9:56:05 PM UTC-5, Elias Mårtenson wrote:
> > On Tuesday, 6 March 2018 23:44:15 UTC+8, Marek Marczykowski-Górecki wrote:
> >
> > > > It seems to be something that is trigger
As far as I understand, qvm-revert-template-changes has been removed in Qubes 4
(at least I can't find it), and the alternative solution is to manually create
an LVM clone that you can revert to later if needed.
I have to admit that I'm not sure of the syntax to actually do this, so it
would
On Tuesday, 6 March 2018 23:44:15 UTC+8, Marek Marczykowski-Górecki wrote:
> > It seems to be something that is triggered explicitly when shutting down
> > this
> > particular VM.
>
> Do the disappear from both qvm-usb tool and devices widget, or only the
> widget?
I have now tested this.
On 6 Mar 2018 11:44 pm, "Marek Marczykowski-Górecki" <
marma...@invisiblethingslab.com> wrote:
> It seems to be something that is triggered explicitly when shutting down
this
> particular VM.
Do the disappear from both qvm-usb tool and devices widget, or only the
widget?
That's a good
On Tuesday, 6 March 2018 15:30:33 UTC+8, awokd wrote:
>
> You meant other templates besides fedora-26 will NOT cause the behaviour,
> right?
That is correct. This only happens with the fedora-26 template.
> > If I plug a USB device into the computer, then all USB devices show up
> > again.
> >
Running Qubes4 with the latest testing updates on dom0 and the templates.
After booting my laptop (Dell Latitude E7470) my sys-usb has two USB devices
registered: The integrated webcam, and an 8087:0a2b (the USB root hub, I
believe).
If I then boot the fedora-26 template and subsequently shut
On Thursday, 22 February 2018 00:52:03 UTC+8, Yuraeitha wrote:
> This is really weird indeed... there somehow seems to be a time or random
> factor involved? I believe there were a few before us too, who also had
> problems for a while even after a restart, but it was resolved eventually on
>
On Wednesday, 21 February 2018 23:42:18 UTC+8, Yuraeitha wrote:
> On another bright side or bonus, Qubes
> even seem more smooth now. It's like old
> creeky wheels has gotten some oil and
> it's running more smooth. It can
> definitely be felt, at least on my
> system. For example one
On Wednesday, 21 February 2018 02:26:16 UTC+8, Marek Marczykowski-Górecki
wrote:
> qvm-copy command takes only filename, the VM name you give in qrexec
> confirmation prompt.
After doing a full reboot of the system, and making sure that everything is
updated, qvm-copy-to-vm now works, but
I'm away from my computer at the moment so I can't try to reproduce all your
tests, but I did try to use copy-to-vm from Nautilus on a fedora-26
template-based vm and it didn't seem to do anything. The menu just closed.
I can't say if anything else in the Nautilus instance worked after that,
After doing the most recent qubes-dom0-update from the testing repository, all
RPC calls from one VM to another stopped working. Calls from dom0 still works
fine.
By "not working" I mean that the call to qrexec-client-vm gives me a "Request
refused".
This includes calls to qvm-copy as well,
On Wednesday, 14 February 2018 07:14:15 UTC+8, Jean-Philippe Ouellet wrote:
> Thanks :)
>
> The ~10% cpu overhead for each linux-stubdom should still probably be
> fixed for those who need HVMs (and for sys-{net,usb}), but still...
>
> My previously constantly-spinning laptop fans appreciate
After installing rc4, I noticed that sys-net did not have the clocksync service
enabled. In fact, clocksync was not enabled on any of the vm's.
I noticed this after my computer's clock was off by one minute.
Other than enabling this service on sys-net, is there anything else I need to
do to
Has anyone considered implementing split-git? The idea being that you'd have a
custom git protocol that forwards requests over qrexec to a git repository on a
different vm.
The reading I started thinking about it is that I have a vm for Keybase, and
I'm using the keybase git provider for some
This morning I saw an update for bug #3265
(https://github.com/QubesOS/qubes-issues/issues/3265) that it had been finally
merged into mainline.
That suggests that it was not part of rc4. I just installed a fresh rc4 and
sure enough, whilte doing initial configuration of the system that bug hit
Last year, there was a lot of activity surrounding two really interesting
projects: One about improving the AEM feature, and another which was about
being able to mark downloaded files as insecure so that they can be opened in a
DVM.
When reading the posts about it, it seemed to me that these
On Sunday, 4 February 2018 03:09:41 UTC+8, Yuraeitha wrote:
> Also it seems like some functions "might (maybe)" work as intended, for
> example
> I can copy files between VM's and Win7, on a Win7 that was installed on Qubes
> 3.2., but backup restored on Qubes 4. Others seem like they can do
On Saturday, 3 February 2018 12:06:20 UTC+8, Andrew David Wong wrote:
> As far as I know, Qubes Windows Tools continues to remain on
> indefinite hold. We welcome anyone from the community with the
> requisite skills to take over development (or just pitch in here and
> there).
I wanted to be
Thank you for this update.
I have been running RC2 since it came out, and continuously been updating from
testing. My Qubes laptop had been off for two days and as soon as I saw this
announcement I booted it up and updated.
When I did the update, ‘qubes-dom0-update
On Saturday, 25 November 2017 09:03:42 UTC+8, Leo Gaspard wrote:
> On 11/24/2017 08:27 AM, Elias Mårtenson wrote:
> > The attack scenario you describe just doesn't seem as serious to me as
> > it does to you. This
> > scenario would involve a rogue application cal
On Friday, 24 November 2017 15:05:27 UTC+8, Jean-Philippe Ouellet wrote:
> ...but surely not *all* of them able to do perform any operation they
> want on any data they want using any key they want as soon as you
> authorize it once for any VM! (by default the agent authorizes any use
> of
On Friday, 24 November 2017 14:46:47 UTC+8, Elias Mårtenson wrote:
>
> On Friday, 24 November 2017 14:39:26 UTC+8, Jean-Philippe Ouellet wrote:
>
>
>> Use a specific source vm in the first field, not $anyvm, otherwise you
>> may actually be better off without spli
On Friday, 24 November 2017 14:39:26 UTC+8, Jean-Philippe Ouellet wrote:
> No! I would very strongly recommend against that!
>
> That allows any VM (including entirely untrusted ones, like sys-net,
> DispVMs with who knows what, etc.) to sign & decrypt stuff with your
> keys!
>
> Use a
On Friday, 24 November 2017 12:10:06 UTC+8, Jean-Philippe Ouellet wrote:
> Explicitly allowing it in policy e.g.
> some-vmsome-vm-keysallow
> in /etc/qubes-rpc/policy/qubes.Gpg will stop asking for confirmation each
> time.
Thank you.
Adding “$anyvm private-gpg allow” to the
I'm using split-gpg, and I end up using it a lot since I sign my git
commits using it.
Since upgrading to 4.0rc2, I have noticed that every time a VM wants to
call out to the GPG VM,
a dialog box is shown asking me for the target VM. At this point I need to
click on the menu
and manually
On Monday, 20 November 2017 19:32:50 UTC+8, Marek Marczykowski-Górecki
wrote:
> I've confirmed that both the net- and firewall VM's are configured to not
> > start
> > at boot (as far as I understand, this option simply controls the
> ‘autostart’
> > prefs option), yet the VM's still start
On Saturday, 18 November 2017 20:55:09 UTC+8, Chris Laprise wrote:
>
> On 11/17/2017 06:12 AM, Elias Mårtenson wrote:
> > On 17 November 2017 at 19:08, Unman <un...@thirdeyesecurity.org
>
> > <mailto:un...@thirdeyesecurity.org >> wrote:
> >
> >
I have configured sys-net and sys-firewall to only manage the WLAN
connection. I have
then set up two separate VM's, foo-net and foo-firewall that manages the
ethernet
interface on my computer. The latter is connected a separate network, and
have
dedicated VM's connected to them.
The behaviour
On 9 Nov 2017 9:33 pm, "blacklight" wrote:
qubes never had these snapshots you mentionded, but were you refering to
the dvm images?
Perhaps. It certainly did something that made DVM's start really quickly.
Definitely faster thaw a normal VM. I always assumed it took a
On Wednesday, 8 November 2017 21:11:39 UTC+8, Marek Marczykowski-Górecki
wrote:
> sudo lvs qubes_dom0/pool00
Thank you very much. It makes much more sense now. I can see how the new
system is much more powerful than the old behaviour.
Regards,
Elias
--
You received this message
Qubes 3.2 supported snapshots that made starting up a dispvm very fast.
This functionality seems to have disappeared in 4.0. Is there a way to do
something similar now?
If I'm lucky, a dispvm starts in about 30 seconds. If I'm unlucky it
doesn't start at all (rexec timeout, I think) and I have
On Monday, 30 October 2017 15:27:28 UTC+8, Marek Marczykowski-Górecki wrote:
qvm-sync-clock in dom0 do update hardware clock. But maybe with wrong
> localtime/UTC value? Try calling `sudo hwclock --systohc --utc`
> manually and see if that helps. Theoretically hwclock should record
>
42 matches
Mail list logo