[qubes-devel] What happened to the tagging of unsafe files?

[Elias Mårtenson]

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.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ee10af32-276c-4938-af00-20d183dc7a0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Template disappeared: qubes-template-fedora-29-minimial

[Elias Mårtenson]

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 perform the reinstall, I get an error message saying that the 
package does not exist. What could be the cause of this?

It does show up when searching for it:

$ sudo qubes-dom0-update --action=search qubes-template-fedora-29-minimal
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some 
time...
Last metadata expiration check: 0:10:33 ago on Fri Feb  1 13:59:39 2019.
Name Exactly Matched: qubes-template-fedora-29-minimal 
qubes-template-fedora-29-minimal.noarch : Qubes template for fedora-29-minimal
Qubes OS Repository for Dom0
  26 MB/s | 
 26 kB 00:00
===
N/S Matched: qubes-template-fedora-29-minimal 
===
qubes-template-fedora-29-minimal.noarch : Qubes template for fedora-29-minimal

$ sudo qubes-dom0-update qubes-template-fedora-29-minimal
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some 
time...
Last metadata expiration check: 0:11:19 ago on Fri Feb  1 13:59:39 2019.
No match for argument: qubes-template-fedora-29-minimal
Error: Unable to find a match

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/693aa570-de4b-4e21-9f4b-6114111cb37c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] HVM root image device type

[Elias Mårtenson]

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 systems.

Is it possible to change this so that they look like plain IDE (or similarly 
simple interface) from the point of view of the hosted operating system? I 
personally don't care about performance since I'm doing this purely to for 
experimentation purposes.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0d068e53-7325-466c-b093-470ba60c85d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] qubes-iptables not starting properly

[Elias Mårtenson]

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:

=
[user@sys-firewall ~]$ systemctl status qubes-iptables
● qubes-iptables.service - Qubes base firewall settings
   Loaded: loaded (/usr/lib/systemd/system/qubes-iptables.service; enabled; vend
   Active: failed (Result: exit-code) since Wed 2018-05-16 20:44:47 +08; 2min 42
  Process: 417 ExecStart=/usr/lib/qubes/init/qubes-iptables start (code=exited, 
 Main PID: 417 (code=exited, status=1/FAILURE)
=

The interesting thing is that I don't see anything in the log. When looking at 
the log, everything seems to have started correctly, and there is no further 
message suggesting it failed later:

=
May 16 20:47:38 sys-firewall audit[1023]: USER_START pid=1023 uid=0 auid=1000 
ses=1 msg='op=PAM:session_open 
grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix 
acct="root" exe="/usr/bin/
sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
May 16 20:47:38 sys-firewall systemd[1]: Starting Qubes base firewall 
settings...
May 16 20:47:38 sys-firewall audit: NETFILTER_CFG table=nat family=2 entries=5
May 16 20:47:38 sys-firewall audit: NETFILTER_CFG table=filter family=2 
entries=4
May 16 20:47:38 sys-firewall qubes-iptables[1026]: iptables: Applying firewall 
rules: OK
May 16 20:47:38 sys-firewall audit: NETFILTER_CFG table=filter family=10 
entries=0
May 16 20:47:38 sys-firewall audit: NETFILTER_CFG table=filter family=10 
entries=4
May 16 20:47:38 sys-firewall qubes-iptables[1026]: ip6tables: Applying firewall 
rules: OK
May 16 20:47:38 sys-firewall systemd[1]: Started Qubes base firewall settings.
=

If restart the service by calling “systemctl start qubes-iptables” everything 
works correctly.

Is this a known problem?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1fdc2b79-c0b2-4627-8f67-c65471fbcae4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Memory balancing issue resurfaced

[Elias Mårtenson]

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
> assigned + some details about state of qmemman.

I just had the problem again. Restarting qubes-qmemman fixed it, as expected. 
Before I restarted it, I had lots of messages like the following. Would you be 
able to draw any conclusions from it?



Apr 04 20:55:48 dom0 qmemman.daemon.algo[19150]: left_memory=79834729 
acceptors_count=5
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: dom 16 is below pref, allowing 
balance
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '0' act=7797228211 
pref=1940720102.4 last_target=7797228211
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '16' act=401645568 
pref=606883430.4 last_target=401604608
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '11' act=1594164013 
pref=385653964.8 last_target=1594164013
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '5' act=943718400 
pref=292608409.6 last_target=943718400
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '13' act=1529529771 
pref=369450598.4004 last_target=1529529771
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '7' act=2125299035 
pref=518805913.6 last_target=2125299035
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: xenfree=66575070 
memset_reqs=[('0', 6804649009), ('13', 1308300424), ('11', 1364980293), ('7', 
1830749866), ('5'
, 943718400), ('16', 2138847702)]
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 0 to 6804649009
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 13 to 1308300424
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 11 to 1364980293
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 7 to 1830749866
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 5 to 943718400
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: dom '11' still hold more 
memory than have assigned (1512398848 > 1364980293)
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 16 to 2021704585
Apr 04 20:55:48 dom0 qmemman.daemon.algo[19150]: 
balance_when_enough_memory(xen_free_memory=-2950780, 
total_mem_pref=4845036416.01, total_available_memory=99929653
59.98)
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: dom 18 is below pref, allowing 
balance
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '0' act=6804649009 
pref=1940720102.4 last_target=6804649009
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '18' act=419431424 
pref=730913996.801 last_target=419431424
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '16' act=2021704585 
pref=606883430.4 last_target=2021704585
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '11' act=1512398848 
pref=385653964.8 last_target=1364980293 slow_memset_react
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '5' act=943718400 
pref=292608409.6 last_target=943718400
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '13' act=1308300424 
pref=369450598.4004 last_target=1308300424
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: dom '7' act=1830749866 
pref=518805913.6 last_target=1830749866
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: stat: xenfree=49478020 
memset_reqs=[('13', 1130316938), ('0', 5937542971), ('5', 895221832), ('11', 
1179890384), ('7',
 1587262584), ('16', 1856731654), ('18', 2236197408)]
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 13 to 1130316938
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 0 to 5937542971
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 5 to 895221832
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 11 to 1179890384
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 7 to 1587262584
Apr 04 20:55:48 dom0 qmemman.systemstate[19150]: mem-set domain 16 to 1856731654
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: dom '11' didnt react to memory 
request (holds 1512398848, requested balloon down to 1179890384)
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: dom '7' still hold more memory 
than have assigned (1605578752 > 1587262584)
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: mem-set domain 18 to 1903107387
Apr 04 20:55:49 dom0 qmemman.daemon.algo[19150]: 
balance_when_enough_memory(xen_free_memory=805899, total_mem_pref=5152096332.8, 
total_available_memory=8588960524.1999
99)
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: dom 19 is below pref, allowing 
balance
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: stat: dom '0' act=5937542971 
pref=1940720102.4 last_target=5937542971
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: stat: dom '19' act=419431424 
pref=692713881.6 last_target=419431424
Apr 04 20:55:49 dom0 qmemman.systemstate[19150]: 

[qubes-devel] Suggestion: Sync local AppVM appmenus and not just the template

[Elias Mårtenson]

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), these will not be available when configuration 
the menu.

Would it be easy to change this so that all application are available? What 
needs to be done is to look at the AppVM itself and search for .desktop files 
in both /usr/share/applications as well as /usr/local/share/applications and 
$HOME/.local/applications.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9eb58444-f2df-4d4a-9354-bbf22c53700e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Intel Speedstep support?

[Elias Mårtenson]

(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.

Disabling Speedstep makes this problem go away. I'm guessing this is caused by 
the Speedstep drivers are not loaded in dom0, preventing the system from 
increasing the CPU speed (which is set to the slowest possible when booting on 
battery).

There doesn't seem to be any packages that contain the Speedstep drivers. Is 
there a way to get this to work?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/122235f8-493a-436b-b8c1-7fbac9cd5e4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Memory balancing issue resurfaced

[Elias Mårtenson]

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 enough, that seemed to have fixed the problem.

Clearly this issue is still around, but does anyone else see this?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/96058068-155c-4e36-959b-d7a952e29361%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Memory balancing issue resurfaced

[Elias Mårtenson]

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 just now when then issue happened again. I look at the “Q” menu, 
and every running VM had their memory allocation set to whatever was their 
minimum allowed.

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?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a6c5b01e-a47b-4123-860b-442cbc0c60b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Panel widget indicating doesn't stop spinning

[Elias Mårtenson]

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 completely, but update the state when you
> close and open menu again.

I'm not sure this is the same issue. I just started a few VM's (4, to be 
exact), waited until the windows popped up for all of them, and three of them 
ended up spinning. Note that I did not click on the “Q” icon until all the 
windows had opened.

Could this be triggered by multiple VM's being started at the same time?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6ce25406-8e20-4853-b6c6-ac7382324496%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] USB devices disappearing after rebooting fedora-26

[Elias Mårtenson]

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 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. They are still visible from qvm-usb. In other 
> > words, 
> > they only disappear from the widget.
> 
> I am having the same issue, but it only happens to me when I shutdown the 
> Debian 9 TemplateVM.

Is debian-9 used as a template for your sys-usb vm?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/03094679-add4-4019-8039-ee3dc96da5ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] qvm-revert-template-changes in Qubes 4

[Elias Mårtenson]

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 be very helpful to have some commandline tools to help out with this.

Is this something that has been considered?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/10ed8be4-c44f-4bfa-a243-28a05cc42fec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] USB devices disappearing after rebooting fedora-26

[Elias Mårtenson]

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. They are still visible from qvm-usb. In other words, 
they only disappear from the widget.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9320b744-2827-40aa-a95d-26b35ede7847%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] USB devices disappearing after rebooting fedora-26

[Elias Mårtenson]

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 question. It definitely disappears from the widget, and they
can definitely be seen by lsusb in sys-usb.

I'll check the result of qvm-usb in the morning.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CADtN0WJE7G2MdybNEVPUVef8Q7vNJ85LFLUsuN%3DjCWEANC3WFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] USB devices disappearing after rebooting fedora-26

[Elias Mårtenson]

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.
> >
> > Note that the devices never actually disappear from sys-usb. Typing lsusb
> > in sys-usb constantly shows the correct output.
> 
> Are any PCI devices assigned directly to your fedora-26 template? Is
> sys-usb based on the fedora-26 template? Does the behaviour still occur if
> you switch sys-usb to the debian-9 template?

No devices are assigned to the template. In fact, other than enabling the
testing repositories and updating to the latest version (as well as adding
some packages) it's pretty pristine. I haven't done much in the way of
configuring this template, and I've had this behaviour since very shortly
after installing this machine (a few days after rc4 was released).

It seems to be something that is triggered explicitly when shutting down this 
particular VM.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6c1a9f19-2273-406d-a6bb-4ff7bf7bc7ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] USB devices disappearing after rebooting fedora-26

[Elias Mårtenson]

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 it down, the USB 
devices all disappear (I get regular disconnection messages). It only happens 
when shutting down fedora-26. Doing the same with the fedora-26-minimal or 
debian-9 templates, nor any regular VM's cause this behaviour.

If I plug a USB device into the computer, then all USB devices show up again.

Note that the devices never actually disappear from sys-usb. Typing lsusb in 
sys-usb constantly shows the correct output.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9a0ffa90-338b-49be-a0b0-04e1b239baba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working

[Elias Mårtenson]

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 
> its own? (At least that's the impression I got from reading those posts). Now 
> the same happened to me, it just went away on its own. Then the question is, 
> what is triggering this "delay"?
> 
> Could it be some system cache of sorts? also did you install current-testing? 
> That's the one I used today. I also sometimes have to do 'clean all' or 
> restart sys-net and sys-firewall, for the updater to work properly, which 
> either can't find the updates or return PGP check errors. Sometimes I need to 
> do both, but typically the VM restart is just needed when PGP errors come up 
> during downloads. if I don't do that once in a while, especially if the 
> system has been running for a while, then I've frequently run into these 
> issues the last 14 days or so. It may be a long shot, but you can try these 
> things out too. For example I use qubes-dom0-update --action='clean all' and 
> then clean all in the respective template too.

I figured it out.

The problem was indeed that the template had not been updated to testing. This 
was caused by the repositories file being reverted back to its original 
(non-testing) state. I believe this was caused by me executing the wrong Salt 
state when I was experimenting with that previously.

Thanks a lot for the help, both you and Marek.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3563448e-ad1b-4866-ad78-af983a22b8c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working

[Elias Mårtenson]

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 noticeable 
> difference is how fast VM's shutdown is 
> after use.
> 
> Can you reproduce this fix Elias?

I did try to update and reboot today, but
the problem remained.

I also noted that "open in dispvm" doesn't
work, but I presume that's a consequence
of qvm-copy not working. 

It is funny that qvm-copy-to-vm works. I 
wonder what the difference is between 
these. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9bfb7e1d-0f53-4c7d-b613-418997581b54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working

[Elias Mårtenson]

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 qvm-copy still gives me the permission 
error.

As the Nautilus integration uses qvm-copy (rather than qvm-copy-to-vm) it too 
fails, in the same way as before.

A colleague of mine who installed rc3 (and has updated everything from testing 
since) just did a full update and he's not seeing the same problem.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/68b18bf2-41cd-4624-95da-14c132f7804b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working

[Elias Mårtenson]

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, as I 
closed the window after that. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5df13ab4-d7cb-42a5-99e5-33e16127df1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Possible regression: vm-to-vm RPC calls stopped working

[Elias Mårtenson]

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, since it uses the qubes.Filecopy RPC 
call.

Is this a known problem?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9606becc-5c00-46c6-bb06-28ae90624a18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Massive improvement in performance and battery life since switching to pvh

[Elias Mårtenson]

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 it.

I noticed that the default mode for new VM's was changed from HVM to PVH 
between rc3 and rc4.

What is the general recommendation right now for the use of PVH vs. HVM?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8d4b4883-1d35-46be-936a-5b7153f23aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] clocksync service is not enabled on any vm's in rc4

[Elias Mårtenson]

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 get time synchronisation working?

Regards,
Elias 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d6be960c-4ae8-4589-af29-9617012f4915%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Split-git?

[Elias Mårtenson]

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 private repositories. It would be 
nice to be able to work with those repositories from a vm which does not have 
Keybase installed.

I can also envision other usecases for a split-git implementation.

I have started working on a proof-of-concept but I'm nowhere near anything that 
works yet. That's why I'm asking here if anyone else have worked on the same 
thing, before spending more time on it.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0cecd112-d067-4bba-b771-59052d6d1dab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Bug #3265 not fixed in 4.0rc4

[Elias Mårtenson]

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 me.

Sure, doing a qubes-dom0-update will fix this, but this bug makes it very hard 
to even begin to use the system and might reflect poorly on new users.

It would be nice if this fix was part of the final 4.0 release.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e44560b9-b560-4a30-abdd-84796dbb7b2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] What happened to last year's GSOC submissions?

[Elias Mårtenson]

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 projects were 
pretty much completed. When can we hope to see them in Qubes 4?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/4937d080-437b-4efe-83e1-cc1e3a1256d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?

[Elias Mårtenson]

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 this too. 
> Also it seems it's a common problem not to be internet in the restored Q3.2-
> Win7, perhaps the code is different in regards to how it ties networking with 
> Qubes 4? I have no idea about the rest of the mechanics from a users 
> perspective though, and most certainly not as a developer as I unfortunately 
> don't have such skills, I wish I could help more.

I have tried this, and in my case, the win7 VM crashed hard (with the VM 
immediately disappearing with not error message to be seen) after a few seconds 
of use.

While it was running, things worked fine (i.e. fast graphics updates etc) which 
leads me to believe that the graphics drivers are fine. It does seem to die as 
soon as I open the Explorer window, which somewhat narrows down the set of 
potential causes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/82a27836-11e1-4a37-98f5-8d77ba26bfe9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?

[Elias Mårtenson]

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 that person, and I did take an initial look. However, being an 
experienced Unix developer was not much help in figuring out the issues with 
the Windows tools.

Is there some source of information that helps explain what the problem could 
be, and where to start looking for it?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/982dc0b2-f912-40b0-ab6d-523b788069dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Qubes OS 4.0-rc3 has been released!

[Elias Mårtenson]

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 
--enablerepo=qubes-dom0-current-testing’ told me that there are no updates 
available.

Because of this, I have two questions:

  - Was rc3 based on the content of testing as of a couple of days ago?

  - Is there some place where I can see what are the most recent versions of
packages, and when those packages were updated?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9dca957e-b20b-4dd8-84eb-1aa7ac72fe2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 calling qubes-gpg-client to
> > attempt to sign some
> > data, and somehow manage to trick me into accepting the request.
> 
> I believe the threat Jean-Philippe is describing is something like:
>  * You use an untrusted VM to perform some GPG operation
>  * However it was infected and something was waiting for you to accept this
>  * This something can now perform any GPG operation they want during
> 300s using your secret keys

Yes. I don't think we're in disagreement about the thread model.
Even in the case you're describing I would still know that something
is singing things on my behalf as every signing operation will display
a notification.

That said, the 300s unlock time isn't particularly beneficial to me, and
I will probably set it to something significantly lower, like 1 second
or even 0.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/db84bdfd-48e8-44f9-9645-1bf0a8a5d761%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 the keyring for 300 seconds(?) after first use) 
>

Yes, 300 seconds is the default. And it's only authorised for a given VM. 
Trying to sign
from another VM will present the popup again.

As long as I don't accept the GPG warning popup unless I know it's OK, I 
don't see
this as an issue. Also, every signing request during these 300 seconds will 
display a
notification, which will quickly reveal if there are any strange things 
happening (and,
again, I'd need to manually authorise the first access anyway).
 

> Was there some documentation you got this from? If so, please do point 
> me to it so I can correct it ASAP. 
>

When I initially did this for 3.2, I followed the official documentation on 
this, which gave
me the configuration that is identical to what I managed to set up with 4.0 
now:
https://www.qubes-os.org/doc/split-gpg/

There are no mentions of limiting access to specific VM's, and the 
following statement
seems pretty reasonable to me:

*“With Qubes Split GPG this problem is drastically minimized, because 
each time the key*
*is to be used the user is asked for consent (with a definable time 
out, 5 minutes by default),*
*plus is always notified each time the key is used via a tray 
notification from the domain*
*where GPG backend is running. This way it would be easy to spot 
unexpected requests*
*to decrypt documents.”*

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 calling qubes-gpg-client to 
attempt to sign some
data, and somehow manage to trick me into accepting the request.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/da229360-96f6-44d1-9e3e-2e2fd9579c4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 split-gpg entirely depending on 
>> your threat model.
>
>
> I still get the notification asking me to allow the signing. With the line 
> added, the
> behaviour seems to be identical to what I had in 3.2.
>

I do agree with you in the general case, that locking things are better 
than not
locking them. In this particular case, however, I want almost all my VM's 
to be
able to sign at one point or the other. And this behaviour was deemed 
acceptable
in 3.2, so I don't really see how my solution can be seen as being overly 
bad?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/240c288e-17bd-4e1d-96fa-38c67c7b701f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 specific source vm in the first field, not $anyvm, otherwise you 
> may actually be better off without split-gpg entirely depending on 
> your threat model.


I still get the notification asking me to allow the signing. With the line 
added, the
behaviour seems to be identical to what I had in 3.2.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0655c425-c010-4eb3-9aa7-93e849c6b464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 file fixed the problem.

Regards,
Elias 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/7dd26f51-9947-4f7d-aa52-a18a748ae36b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

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 choose the GPG VM, even though the name of that VM is already 
specified
in the QUBES_GPG_DOMAIN environment variable.

Is this a bug?

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/11091248-cf43-465c-9e31-93030998d2cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Network VM's always autostart even when they are not supposed to

[Elias Mårtenson]

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 at boot. 
> > 
> > The only other thing that is special about these VM's is that my second 
> > netvm has the ethernet hardware attached to it. That said, even if that 
> was 
> > the cause it wouldn't explain why the firewall vm starts at boot too. 
>
> Is any other VM started there too? Maybe some other VM (using such 
> netvm) is configured with autostart=True. 
>

No. After boot, the only VM that is started except for the two sets of 
netvm/firewallvm
is sys-usb.

There are only three VM's that use the alternative netvm/firewallvm and 
none of them
are autostart.
 

> Another possibility is dom0 update check or dom0 clock sync. Those 
> actions require appropriate VM to be running (see global prefs - 
> updatevm, clockvm). I think they will be started for that. 
>

updatevm and clockvm are set to sys-firewall and sys-net respectively, so 
that can't
be the reason either.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/db66164a-a5ec-4a92-9474-68e99d319827%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Network VM's always autostart even when they are not supposed to

[Elias Mårtenson]

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: 
> > 
> > You havent said which version if Qubes you are running. 
> > in 3.2 the qubes-netvm service may be responsible. You could try 
> > changing the default netvm, or temporarily disabling the 
> > qubes-netvm.service and see if that changes behaviour. 
> > 
> > Oops. Sorry about that. It's 4.0rc2. 
>
> I was able to prevent sys-net and sys-firewall auto-start in rc2 by 
> simply disabling 'Start VM automatically at boot' in settings. The only 
> other difference is that my default netvm is set to 'VPN' but I wouldn't 
> expect that to matter.


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 at boot.

The only other thing that is special about these VM's is that my second
netvm has the ethernet hardware attached to it. That said, even if that was
the cause it wouldn't explain why the firewall vm starts at boot too.

-- 
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ee18d200-8f9a-4d1d-b0a2-3eb3a3895333%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Network VM's always autostart even when they are not supposed to

[Elias Mårtenson]

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 that I am observing is that foo-net and foo-firewall are 
automatically
started whenever I boot the machine, even though they have autostart = 
False.
Also, there are no VM's started that depend on these network VM's.

What could trigger the start of these VM's?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/30e0d2c4-2bc9-477d-9951-65d21481b869%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Is there a way to save dispvm snapshots for fast startup?

[Elias Mårtenson]

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 snapshot
after booting, but I could be wrong. I would very much like to know what it
did.

Whatever it did, it certainly made the experience of using DVM's much
nicer, and the question is if something similar is available in 4.0?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CADtN0WJzN6ywT9%3DnJQK8SC%2B4V5kB9rSE5HRHv1Jfk0GSRM4naw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Where does Qubes 4 store the VM images?

[Elias Mårtenson]

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 because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ca898f0b-3090-4242-b0e0-ffc9d01aaf12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Is there a way to save dispvm snapshots for fast startup?

[Elias Mårtenson]

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 to try again. 
Getting the snapshot behaviour from 3.2 would be very helpful.

Regards,
Elias

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/269a9d47-1184-417b-90d0-99f4420921c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Where can I find the clocksync script?

[Elias Mårtenson]

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 
> utc/localtime value and use it next time. You can check that by calling 
> qvm-sync-clock again and rebooting again.


Thank you. That seems to have done the trick. I'm not sure I would ever 
have been able to figure that one out myself.

Regards,
Elias 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/4a5b6e2d-da44-409e-bbce-8d9da4be044e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.