R3.1 few issues / bugs

[Shilu Pilu]

I did install a clean qubes 3.1 and I created all vms by myself. After a while I noticed some weird behavior with the autostart setting in qvm-prefs.

My sys-net and sys-firewall were auto starting even with autostart set to False, and so I though the system must have written somewhere to start these machines since the name I've choosen is the same the system usually name these machines.

Decided to change the names and even create new net and firewall vms to see if both network and firewall kept auto starting.
After a while I can't really say why they start or not. Definitely qvm-prefs autostart is not helping.
Right now I've to machines with name network and firewall which keep autostarting even with qvm-prefs autostart set to False.

Something else I found out is the state of the vms in qubes manager when vms are set to autostart. They do not fully start. They remain in that yellow state (starting). But only until you launch an application from the vm it won't fully start (with green state). For example, in network vm only until I launch a terminal It won't start and I won't get NetworkManager Applet.

Something weird that happened a few times is when launching an application, the vm "start" and the application launch but the qubes manager shows again a yellow state in that vm and next to it, a recycle symbol (green arrows) like when you update a template and a vm need to be restarted.

Another issue I've found is after setting the debian 8 template. I tried to create a vm but I was receiving the following error:

Dom0: Error Creating AppVm

Error: 'NoneType' object has no attribute 'qid'

Also, while trying to change the netvm of the Template was encountering few problems. Qubes manager showed a netvm but when tried to change it from qubes manager I could not, or changes were not applied or different error messages were showed. (the only thing I remember is mentioning qid in various of these errors.

Since I couldn't do much decided to continue setting fedora 23 template and after 1 or 2 reboots the debian8 template issues disappeared and I could create and start vms from debian.

Last thing I wanted to mention is my inability to use the "convert to trusted PDF". I did mention this in another post. The application starts, open a disposable VM and send to Untrusted PDFs the original one, but there is no secure PDF as a result.

  I know most of this bugs must be minor bugs between manager and vms but I do not know how to help it. I wish I could.

cheeers!

[Tim W]

On Monday, December 14, 2015 at 12:01:05 PM UTC-5, Shilu Pilu wrote:

I did install a clean qubes 3.1 and I created all vms by myself. After a while I noticed some weird behavior with the autostart setting in qvm-prefs.

My sys-net and sys-firewall were auto starting even with autostart set to False, and so I though the system must have written somewhere to start these machines since the name I've choosen is the same the system usually name these machines.

Decided to change the names and even create new net and firewall vms to see if both network and firewall kept auto starting.
After a while I can't really say why they start or not. Definitely qvm-prefs autostart is not helping.
Right now I've to machines with name network and firewall which keep autostarting even with qvm-prefs autostart set to False.

Something else I found out is the state of the vms in qubes manager when vms are set to autostart. They do not fully start. They remain in that yellow state (starting). But only until you launch an application from the vm it won't fully start (with green state). For example, in network vm only until I launch a terminal It won't start and I won't get NetworkManager Applet.

I have seen this same behavior in Qubes as far back as 2.0 IIRC.  I just took it as normal.  As it in no way delayed the network connection from a VM.
 

Something weird that happened a few times is when launching an application, the vm "start" and the application launch but the qubes manager shows again a yellow state in that vm and next to it, a recycle symbol (green arrows) like when you update a template and a vm need to be restarted.

I got The yellow ! next to one when I accidentally tried to start it twice and had a number of VMs all starting up at the same time.  It went away as soon as I restarted it.

Another issue I've found is after setting the debian 8 template. I tried to create a vm but I was receiving the following error:

Dom0: Error Creating AppVm

Error: 'NoneType' object has no attribute 'qid'

Also, while trying to change the netvm of the Template was encountering few problems. Qubes manager showed a netvm but when tried to change it from qubes manager I could not, or changes were not applied or different error messages were showed. (the only thing I remember is mentioning qid in various of these errors.

Since I couldn't do much decided to continue setting fedora 23 template and after 1 or 2 reboots the debian8 template issues disappeared and I could create and start vms from debian.

Last thing I wanted to mention is my inability to use the "convert to trusted PDF". I did mention this in another post. The application starts, open a disposable VM and send to Untrusted PDFs the original one, but there is no secure PDF as a result.

  I know most of this bugs must be minor bugs between manager and vms but I do not know how to help it. I wish I could.

cheeers!

On the other issues did you do a updates on all the templates first?   I noticed a couple weird things that went away after I did the initial updates and restarted everything.  Since then everything so far has been running fairly smoothly but I have yet to dig into everything.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Dec 14, 2015 at 06:16:44PM -0800, Tim W wrote:
>
>
> On Monday, December 14, 2015 at 12:01:05 PM UTC-5, Shilu Pilu wrote:
> >
> > I did install a clean qubes 3.1 and I created all vms by myself. After a
> > while I noticed some weird behavior with the autostart setting in qvm-prefs.
> >
> > My sys-net and sys-firewall were auto starting even with autostart set to
> > False, and so I though the system must have written somewhere to start
> > these machines since the name I've choosen is the same the system usually
> > name these machines.
> >
> > Decided to change the names and even create new net and firewall vms to
> > see if both network and firewall kept auto starting.
> > After a while I can't really say why they start or not. Definitely
> > qvm-prefs autostart is not helping.
> > Right now I've to machines with name network and firewall which keep
> > autostarting even with qvm-prefs autostart set to False.

This is because the VM set as "default netvm" is always started at system
boot, regardless of "autostart" setting. It would be started anyway when
you start the first networked VM, so it's speeding up that action.

If you really want to disable this, disable "qubes-netvm" service in
dom0 (sudo systemctl disable qubes-netvm).

> >
> > Something else I found out is the state of the vms in qubes manager when
> > vms are set to autostart. They do not fully start. They remain in that
> > yellow state (starting). But only until you launch an application from the
> > vm it won't fully start (with green state). For example, in network vm only
> > until I launch a terminal It won't start and I won't get NetworkManager
> > Applet.
> >
> >
>

> *I have seen this same behavior in Qubes as far back as 2.0 IIRC. I just

> took it as normal. As it in no way delayed the network connection from a

> VM.*

>
> > Something weird that happened a few times is when launching an
> > application, the vm "start" and the application launch but the qubes
> > manager shows again a yellow state in that vm and next to it, a recycle
> > symbol (green arrows) like when you update a template and a vm need to be
> > restarted.
> >
>

> *I got The yellow ! next to one when I accidentally tried to start it twice

> and had a number of VMs all starting up at the same time. It went away as

> soon as I restarted it.*

>
> >
> > Another issue I've found is after setting the debian 8 template. I tried
> > to create a vm but I was receiving the following error:
> >
> > Dom0: Error Creating AppVm
> >
> > Error: 'NoneType' object has no attribute 'qid'

Are you able to reproduce this problem? What exactly are the steps?

> > Also, while trying to change the netvm of the Template was encountering
> > few problems. Qubes manager showed a netvm but when tried to change it from
> > qubes manager I could not, or changes were not applied or different error
> > messages were showed. (the only thing I remember is mentioning qid in
> > various of these errors.

Was the template running at that time? If so, take a look here:
https://github.com/QubesOS/qubes-issues/issues/975

Looks familiar? Or something else?

> > Since I couldn't do much decided to continue setting fedora 23 template
> > and after 1 or 2 reboots the debian8 template issues disappeared and I
> > could create and start vms from debian.
> >
> > Last thing I wanted to mention is my inability to use the "convert to
> > trusted PDF". I did mention this in another post. The application starts,
> > open a disposable VM and send to Untrusted PDFs the original one, but there
> > is no secure PDF as a result.

Did you get any error? What templates are you using for source VM and
default DispVM?

> > I know most of this bugs must be minor bugs between manager and vms but
> > I do not know how to help it. I wish I could.
> >
> > cheeers!
>
> On the other issues did you do a updates on all the templates first? I
> noticed a couple weird things that went away after I did the initial
> updates and restarted everything. Since then everything so far has been
> running fairly smoothly but I have yet to dig into everything.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWb3psAAoJENuP0xzK19csBHAH/j1UqVJhI957OMO2yi7+zqSr
eDpSgCyzXx3aYGqJTJ/2iRF4/XdAR7zUR+oZE9amCdtMImyzuQhPZPhUJuM2+lQ2
JuEw6JWvn0ASPfFhIkfugrjg/6YexkOfrkzw3MvbYlH9xs9wYaxpZarutjhA0QFd
LkQVFxXlcr9xtPaYBRsba/U1Pp2zWLblXcedc5CZlG9JLdH5Uk9/E+wlGzlwEKxY
y4nNPMtZnKYkOW7eIjdR+HhwcD5ubLrgFf/MkxX7ioZR3Z3g6aPiXHFiPzuRB9qL
g8LccgcGSB2HHDdo7Ak1tgZw4ZuWyeYqME1a/huSl9EMSNOMuWi/BzJKSv2EP4Y=
=OONB
-----END PGP SIGNATURE-----

[Cube]

I'm consistently getting the same error and can't get around it, here's the error

-> Backing up files: 94%...Removing file dom0-home/User.004
-> Backing up files: 94%...Sending file dom0-home/User.004.hmac
-> Backing up files: 94%...Removing file dom0-home/User.004.hmac
-> Backing up files: 94%...tar: User/.local/share/systemd/user: File removed before we read it
-> Backing up files: 94%...Wait_backup_feedback returned: addproc
 ERROR: Failed to perform backup: error in addproc

Before you think the "File removed before we read it" is the issue, I've tried in multiple ways to delete that file and it still dies at the same point, so that doesn't seem to be the problem. Any ideas? Thanks much ...

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

But if you've tried to remove that file, why it is still there?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWcCFJAAoJENuP0xzK19cs2CIIAJqCTslWOkfVhnkL+/FKz2wK
ejejh6qXiciInz2kn+znlK28F6wbdW1nvvm4jROxQykguaK1DIW36k7A60NE5Db+
EXVkBYYCLb8Il5FXoUMw6jtkhSGAZSkq81vtzK8W4xhtqUMr3yUID/LMZI34N8vb
RysqoGTUcpObUw428ODukhCCr0sUyzI9iQlUpaXnK0vrH5/KgrZ9ODu76Jhdrtk+
+Z+J1gqaFbGQ6mrZlulqcEcQLbknI8Fgkv6rJq3dUG7H5WKaiIyQYeAwm5GC/UEp
xsvhnClTWFceTmIUSwDrHuzpYhi7M0zaCOsrwgiLMX+NTQAslWK6z53DwYBBwm0=
=J4Tt
-----END PGP SIGNATURE-----

[Cube]

On Tuesday, December 15, 2015 at 6:18:58 AM UTC-8, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Dec 15, 2015 at 06:15:15AM -0800, Cube wrote:
> I'm consistently getting the same error and can't get around it, here's the
> error
>
> -> Backing up files: 94%...Removing file dom0-home/User.004
> > -> Backing up files: 94%...Sending file dom0-home/User.004.hmac
> > -> Backing up files: 94%...Removing file dom0-home/User.004.hmac
> > -> Backing up files: 94%...tar: User/.local/share/systemd/user: File
> > removed before we read it
> > -> Backing up files: 94%...Wait_backup_feedback returned: addproc
> >  ERROR: Failed to perform backup: error in addproc
> >
>
> Before you think the "File removed before we read it" is the issue, I've
> tried in multiple ways to delete that file and it still dies at the same
> point, so that doesn't seem to be the problem. Any ideas? Thanks much ...

But if you've tried to remove that file, why it is still there?

Sorry, this is from the last iteration ... I removed the file, tried backing up again, got the same problem (without the complaint about the file), then rebooted and tried again (maybe it was some odd problem), this is the result of that so shows that error again.

 

[Cube]

Oh one thought - "why is it still there"? No idea, but seems to get recreated, at least on reboot.

The user name on this is "User" (User@dom0), and this file is named "user", perhaps some issue with using the name "User"? I remember you mentioning something about that.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Did you get any other error then?

> then rebooted and tried again (maybe it was some odd problem), this
> is the result of that so shows that error again.

I see that .local/share/systemd/user is indeed broken symlink. You can
try to create the directory pointed by it (.config/systemd/user). As the
symlink is apparently recreated after reboot...

Anyway a single broken symlink shouldn't break the whole backup:
https://github.com/QubesOS/qubes-issues/issues/1515

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWcCRRAAoJENuP0xzK19cs4kYIAJEcmQ7PMBH0m82iBrlVosO8
auRncjZYY5BJvw5r1G1s9hVOVp3jHFYzm/F87sE5lJEHqsfuOd6bgScexlogeBK/
SpqO6qSKdJ6TVYOsew1LXbI61bO9da0v6ooV3+yq59W2eRbfwJY1y3XTUJMMBMRk
IHcqFKwWbVIIGjU+FHmegsyRKfyyt3UbqvpfYvu+TXI+/n7VYXzK6MAdBECVPCTB
20E13N5TWJk/7sKsBYlh14L1v+CcUi769Y9D4I9lecQJesSZO3F+t/TL7FKAyCbr
1QG53nuVvGI7zMT5DdUFG4/9MXjANbAQkkcPD/5SqEiafjJkb7FQZJpKFfzZV1g=
=sr5i
-----END PGP SIGNATURE-----

[Cube]

On Tuesday, December 15, 2015 at 6:31:54 AM UTC-8, Marek Marczykowski-Górecki wrote:

Did you get any other error then?

Yeah that's what I didn't make clear. 1) Delete the bad symlink 2) re-run the backup 3) it fails at the same point, no error information
 

> then rebooted and tried again (maybe it was some odd problem), this
> is the result of that so shows that error again.

I see that .local/share/systemd/user is indeed broken symlink. You can
try to create the directory pointed by it (.config/systemd/user). As the
symlink is apparently recreated after reboot...

Anyway a single broken symlink shouldn't break the whole backup:
https://github.com/QubesOS/qubes-issues/issues/1515

Yeah, I think that's a red herring, deleting it makes no difference. 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Dec 15, 2015 at 06:39:50AM -0800, Cube wrote:
>
>
> On Tuesday, December 15, 2015 at 6:31:54 AM UTC-8, Marek
> Marczykowski-Górecki wrote:
>
> >
> > Did you get any other error then?
> >
> >
> Yeah that's what I didn't make clear. 1) Delete the bad symlink 2) re-run
> the backup 3) it fails at the same point, no error information

And the final error is still about "addproc"? If there is no other
message, I think it's time to go for --debug option. Be prepared to
receive A LOT of output.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWcCeaAAoJENuP0xzK19csrlgH/2YWTs7ZlkL/N1ZP1MSbEt/l
rMvgNzOufGGHYX5ZWHn5hcBmNYPtQhDO0ju+1sd8lRxUYgFDbFqY4FbnjzpdDDDw
T02x0AozhIjvh1O/VwykyPmNjtpYDmmGcncPxE51CbCJZBGQVfmVLQoDR7iCSp0U
4RXcPwlk6Le0ohPU3Cg0yJl/D3tOQ4nKT/pXQWAVZscmfejibTqd/mRK7RcVc6/w
rmf5cw5hwrr4LIyN5ji11kx8HqmPOXXuikuN460sf9icO8U1jA0SySzPag77lIZ6
Hxus2l5w3d36hGzumvwkWfpVdo9MQiXbK9sBFUDcVryM4B9WYEp5+bywrWXdegQ=
=aR95
-----END PGP SIGNATURE-----

[Cube]

And the final error is still about "addproc"? If there is no other
message, I think it's time to go for --debug option. Be prepared to
receive A LOT of output.

Yes, this IS the result of --debug :)

Anything else I can try?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Dec 15, 2015 at 04:18:55PM -0800, Cube wrote:
>
>
> > And the final error is still about "addproc"? If there is no other
> > message, I think it's time to go for --debug option. Be prepared to
> > receive A LOT of output.
> >
> >
> Yes, this IS the result of --debug :)

Ah, indeed...

> Anything else I can try?

Is that still error in "addproc"? If so, there is some error message there,
maybe much earlier...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWcLE8AAoJENuP0xzK19csZ64H/0THvu3qvZvlOJ1sDkLeA+YX
EczU56xHNgRYzGvRBIZoGbLe925jRVikehBqBjyurcZ596nd1+eqz5TDSU1YErqV
uCizMSJlOZKYTTJLSzMXfh5+MyZJuOj69TohhEOVall9PvvYmWAliJ8VOy0v2oHi
lcfALYikKN8e6n1k2H4fYFV/lxe6PlyrSXfIxb/iQY+tkU9xkHIvAXy+lB959l+W
hJBs0gMKAMao/oWlIufiPNtfBsz0258dMUDUg2Q0YoEuGPM3QTqvrp7mxyjDWWnn
hFIU1hWeLBLE+Kwu5BmVIQ+fqmxKR6HqB94f6aBBC4quppp8C3m8IiU2EDVFMI0=
=doXC
-----END PGP SIGNATURE-----

[Tim W]

On Tuesday, December 15, 2015 at 9:27:26 AM UTC-5, Cube wrote:

Oh one thought - "why is it still there"? No idea, but seems to get recreated, at least on reboot.

The user name on this is "User" (User@dom0), and this file is named "user", perhaps some issue with using the name "User"? I remember you mentioning something about that.

There is the issue with any user name other than 'user' all lower case letters.  'User' would create the config fail error during install at least.

[Shilu Pilu]

Well I realized the vms with this yellow stat are really up and running.

> >
> > Something else I found out is the state of the vms in qubes manager when
> > vms are set to autostart. They do not fully start. They remain in that
> > yellow state (starting). But only until you launch an application from the
> > vm it won't fully start (with green state). For example, in network vm only
> > until I launch a terminal It won't start and I won't get NetworkManager
> > Applet.
> >
> >
>

> *I have seen this same behavior in Qubes as far back as 2.0 IIRC.  I just

> took it as normal.  As it in no way delayed the network connection from a

> VM.* 

But if you want to select a different network I have to launch an application from the net vm or I won't get NetworkManager Applet in dom0 and that does delay.
Also when whonix-gateway which also autoruns does not notice to dom0 with "connected to tor", but it is.
I'm trying to say, when the vms autorun they remain in this yellow state and they won't "talk" to dom0, or dom0 won't notify about the vms (sry I don't have skills to explain any better).

>
> > Something weird that happened a few times is when launching an
> > application, the vm "start" and the application launch but the qubes
> > manager shows again a yellow state in that vm and next to it, a recycle
> > symbol (green arrows) like when you update a template and a vm need to be
> > restarted.
> >
>

> *I got The yellow ! next to one when I accidentally tried to start it twice

> and had a number of VMs all starting up at the same time.  It went away as

> soon as I restarted it.*

That's true too.

>
> >
> > Another issue I've found is after setting the debian 8 template. I tried
> > to create a vm but I was receiving the following error:
> >
> > Dom0: Error Creating AppVm
> >
> > Error: 'NoneType' object has no attribute 'qid'

Are you able to reproduce this problem? What exactly are the steps?

No, I tried to change the firewall vm name and then play a bit with it but couldn't, I don't really remember what my steps were.

> > Also, while trying to change the netvm of the Template was encountering
> > few problems. Qubes manager showed a netvm but when tried to change it from
> > qubes manager I could not, or changes were not applied or different error
> > messages were showed. (the only thing I remember is mentioning qid in
> > various of these errors.

Was the template running at that time? If so, take a look here:
https://github.com/QubesOS/qubes-issues/issues/975

Looks familiar? Or something else?

I remember a dom0 message about a mac but I don't remember exactly, I will be more carefully if it does happen again.

> > Since I couldn't do much decided to continue setting fedora 23 template
> > and after 1 or 2 reboots the debian8 template issues disappeared and I
> > could create and start vms from debian.
> >
> > Last thing I wanted to mention is my inability to use the "convert to
> > trusted PDF". I did mention this in another post. The application starts,
> > open a disposable VM and send to Untrusted PDFs the original one, but there
> > is no secure PDF as a result.

Did you get any error? What templates are you using for source VM and
default DispVM?

No errors at all (can I search deeper on this? how? ).
I'm using fedora-23 template for both.

> >   I know most of this bugs must be minor bugs between manager and vms but
> > I do not know how to help it. I wish I could.
> >
> > cheeers!
>

> On the other issues did you do a updates on all the templates first?   I
> noticed a couple weird things that went away after I did the initial
> updates and restarted everything.  Since then everything so far has been
> running fairly smoothly but I have yet to dig into everything.

Everything up to date.

[Tim W]

"Also when whonix-gateway which also autoruns does not notice to dom0 with "connected to tor", but it is."

Now tht you mention it I notice this too. I k ow I get the message when I start the ws.client vm. I do recall reading something in whonix sites docs that the newest version is now using silent mode for the connection and bootstrapping of the gw. Not sure if that has anything to do with it. I can not recall what was needed to change it back to.the gui verbose pop up window for it. Maybe see if you can find it on their site if you think it might be the reason for this.

Another thing I noticed was a difference in some of the config of vms created by the command line versus the vmm gui. I can't recall off the top of my head what they were. I k ow it was enough for me to delete them and ceate them instead via the vmm. I will look at this when I get home

[Shilu Pilu]

Hello again.

I've discovered why autostarted VMs remain in "yellow" state in Qubes VM Manager after system boots.
The whole thing happens when you get into dom0 really quick.
I explain, qubes 3.1 has improved a lot loading times from 3.0 to 3.1. I believe this is because previously (3.0 and older) VMs started loading before logging screen (or at least that was for me). Now in 3.1 VMs start loading when you reach login screen. If you enter your pass really quick VMs doesn't have time to reach the "green" state. Because of this, Qubes VM Manager will show "yellow" state and the notifications from VMs (such as network manager applet from sys-net or "connected to tor" message from sys-whonix" will not get to dom0.
However if you wait 1min or so before entering your pass, VM manager will show "green" and the messages will get to dom0.

No idea on how to proceed further but I figured out how to reproduce it.

Regarding PDF conversion I have yet no idea. Still waiting for some help.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 17, 2015 at 03:37:24PM -0800, Shilu Pilu wrote:
> Hello again.
>
> I've discovered why autostarted VMs remain in "yellow" state in Qubes VM
> Manager after system boots.
> The whole thing happens when you get into dom0 really quick.
> I explain, qubes 3.1 has improved a lot loading times from 3.0 to 3.1. I
> believe this is because previously (3.0 and older) VMs started loading
> before logging screen (or at least that was for me). Now in 3.1 VMs start
> loading when you reach login screen. If you enter your pass really quick
> VMs doesn't have time to reach the "green" state. Because of this, Qubes VM
> Manager will show "yellow" state and the notifications from VMs (such as
> network manager applet from sys-net or "connected to tor" message from
> sys-whonix" will not get to dom0.

You are probably right about the cause. But in theory in 3.1 login
screen still should be shown only after all autostarted VMs are running,
so something is wrong here. Check `sudo systemctl` output for any failed
services.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWdWbqAAoJENuP0xzK19csq4sIAIjQGlEFzP1aBEBzRImkMsBk
XNzGKl+Av0RrH4GR2wUfzJWX8+UWDlRFICUMb9GkH3m+1U25LW8Gw+2b9hvnW9HE
oUv3w8S/4vf8IduXj5QZnUxA/mUj3fdh43KQq1St2Ka181DhYZQ+u3BLDmma8lLb
/BNfCSSEr4F7cU4BcXOJKvoefB6wsp+X92CtA76iR57v6KPaLGfcKpWUUU7qr+gK
3wxc36Kv7/a0umI9E1jdukv8C8vAKX9nEuZHm90vhFTvHAh4TEG02DVuXr5w4icg
z8rML/jLl6GvnZuWwus2WMN5po8T4AfUJN6Bi/3hjTEfIUFHV921AxA/Vv52xAo=
=XOPJ
-----END PGP SIGNATURE-----

[Shilu Pilu]

> You are probably right about the cause. But in theory in 3.1 login
> screen still should be shown only after all autostarted VMs are running,
> so something is wrong here. Check `sudo systemctl` output for any failed
> services.

sudo systemctl reveals the following:

qube...@sys-firewall.service  loaded   failed      failed
qube...@sys-net.service        loaded   failed      failed
systemd-modules-load.services  loaded   failed      failed

the rest seems up and running.

Any of these things may result in a malfunction of pdf conversion aswell?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Dec 19, 2015 at 06:53:21AM -0800, Shilu Pilu wrote:
> > You are probably right about the cause. But in theory in 3.1 login
> > screen still should be shown only after all autostarted VMs are running,
> > so something is wrong here. Check `sudo systemctl` output for any failed
> > services.
>
> sudo systemctl reveals the following:
>
> qube...@sys-firewall.service loaded failed failed
> qube...@sys-net.service loaded failed failed
> systemd-modules-load.services loaded failed failed
>
> the rest seems up and running.

Those two VMs are already started by qubes-netvm service. So it isn't
the problem (but still a bug):
https://github.com/QubesOS/qubes-issues/issues/1528

> Any of these things may result in a malfunction of pdf conversion aswell?

I don't think so.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWdXRrAAoJENuP0xzK19csncAH/RIRNAklMadatDZyTTJglhTc
HFYJk1HVODyKamcLL8410M8s/RsEY+qDkY1Xr1NCB4mr+L71bXQSZ7y7WO+sqDXP
KlQk5MLZaI6x7xD3Ur0ImpBeLicZEA9/O8fEyKUsYZlqAoIS9cg41C8QC1Z7G7YB
M+Cg4EKW9l8gm17EPz/jNzps2AEvsdFCccStv3+5311ipFNbIKN5Mwai7ww7rK6f
aUCxCFDdceNMiLe9+2j7gCgkj8yc9dNV5rBo9AfxjiT78KROjzIPP1ebDxfM9ciI
MtcKD7eM3tO8bZuLwEnrb0eHbMxkA+mdy9gKQTHRKX+FkGVdLpQnI3/foiV7S1E=
=GG/W
-----END PGP SIGNATURE-----

[Tim W]

I just did a bunch of reboots and I was able to duplicate the issues he has started about the autoruns.   If I wait just a bit longer before entering the user and password login screen ( post LUKS)  I get green across the board but if I enter it fast the immediately when it pops up and enter thru I get yellows at least until I use them.  USBVM stays yellow as I am not presently using any usb connections. 

Marek,

If you want any tests and logs run and attached here just post up the commands etc and I am glad to run and upload or in github, where ever.

Cheers.,

Tim

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Dec 19, 2015 at 05:54:10PM -0800, Tim W wrote:
>
>
> On Saturday, December 19, 2015 at 10:14:59 AM UTC-5, Marek
> Marczykowski-Górecki wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Sat, Dec 19, 2015 at 06:53:21AM -0800, Shilu Pilu wrote:
> > > > You are probably right about the cause. But in theory in 3.1 login
> > > > screen still should be shown only after all autostarted VMs are
> > running,
> > > > so something is wrong here. Check `sudo systemctl` output for any
> > failed
> > > > services.
> > >
> > > sudo systemctl reveals the following:
> > >
> > > qube...@sys-firewall.service loaded failed failed
> > > qube...@sys-net.service loaded failed failed
> > > systemd-modules-load.services loaded failed failed
> > >
> > > the rest seems up and running.
> >
> > Those two VMs are already started by qubes-netvm service. So it isn't
> > the problem (but still a bug):
> > https://github.com/QubesOS/qubes-issues/issues/1528
> >
>

> I just did a bunch of reboots and I was able to duplicate the issues he has
> started about the autoruns. If I wait just a bit longer before entering
> the user and password login screen ( post LUKS) I get green across the
> board but if I enter it fast the immediately when it pops up and enter thru
> I get yellows at least until I use them. USBVM stays yellow as I am not
> presently using any usb connections.
>
> Marek,
>
> If you want any tests and logs run and attached here just post up the
> commands etc and I am glad to run and upload or in github, where ever.

Check ~/.xsession-errors for anything related to those VMs in yellow
(USBVM in your case).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWd8aYAAoJENuP0xzK19csUQsH/0IkV65xbiv9Qme/bUj6l6Tg
pXjy4w5aqEM2i4i5zaRWtIlb3zY0nOuWXIeLcklOlmVkMLh0l+9kG+nixDjVXED8
aJfbiMUiqkyEH2FHcjQsjSVkXrFn39xbYQXXb1DMKOQyGeFe0ZJncHBF6wlJ5B6A
yzKHHjhc7THuJnC1wmdT1xceUEj4SmhMjwrjD7j6HjHi2nZ3RvAJAjijMepbqU8T
oy+sQFVcpWRseYoeVLNPWKMvHsut1KMo4AY8gPn4iB3W87dCTaNWtPzAgZateRI5
+pogZh8jRvjcr3+QccbupdhturY5AcLs7pfNEGVx36u/GUJ+gcdTAAarlfLwCCk=
=noqr
-----END PGP SIGNATURE-----

[Tim W]

Output for both sys-usb and sys-firewall both started with yellow state according to VMM

 sys-usb vm .xsession-errors:

 X.Org X Server 1.18.0
Release Date: 2015-11-09
X Protocol Version 11, Revision 0
Build Operating System:  4.2.5-300.fc23.x86_64
Current Operating System: Linux sys-usb 4.1.13-7.pvops.qubes.x86_64 #1 SMP Thu Dec 17 09:47:41 UTC 2015 x86_64
Kernel command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 3 nopat iommu=soft swiotlb=8192
Build Date: 16 November 2015  10:08:25AM
Build ID: xorg-x11-server 1.18.0-2.fc23
Current version of pixman: 0.33.4
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/user/.local/share/xorg/Xorg.0.log", Time: Mon Dec 21 20:41:04 2015
(++) Using config file: "/etc/X11/xorg-qubes.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Warning:          Key <OUTP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KITG> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIDN> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIUP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <RO> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I192> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I193> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I194> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I195> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I196> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I255> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <I149> (keycode 149)
Warning:          No symbols defined for <I154> (keycode 154)
Warning:          No symbols defined for <I168> (keycode 168)
Warning:          No symbols defined for <I178> (keycode 178)
Warning:          No symbols defined for <I183> (keycode 183)
Warning:          No symbols defined for <I184> (keycode 184)
Warning:          No symbols defined for <FK19> (keycode 197)
Warning:          No symbols defined for <FK24> (keycode 202)
Warning:          No symbols defined for <I217> (keycode 217)
Warning:          No symbols defined for <I219> (keycode 219)
Warning:          No symbols defined for <I221> (keycode 221)
Warning:          No symbols defined for <I222> (keycode 222)
Warning:          No symbols defined for <I230> (keycode 230)
Warning:          No symbols defined for <I247> (keycode 247)
Warning:          No symbols defined for <I248> (keycode 248)
Warning:          No symbols defined for <I249> (keycode 249)
Warning:          No symbols defined for <I250> (keycode 250)
Warning:          No symbols defined for <I251> (keycode 251)
Warning:          No symbols defined for <I252> (keycode 252)
Warning:          No symbols defined for <I253> (keycode 253)
** Message: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
vmware-user: could not open /proc/fs/vmblock/dev
Warning:          Key <OUTP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KITG> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIDN> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIUP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <RO> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I192> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I193> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I194> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I195> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I196> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I255> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <I149> (keycode 149)
Warning:          No symbols defined for <I154> (keycode 154)
Warning:          No symbols defined for <I168> (keycode 168)
Warning:          No symbols defined for <I178> (keycode 178)
Warning:          No symbols defined for <I183> (keycode 183)
Warning:          No symbols defined for <I184> (keycode 184)
Warning:          No symbols defined for <FK19> (keycode 197)
Warning:          No symbols defined for <FK24> (keycode 202)
Warning:          No symbols defined for <I217> (keycode 217)
Warning:          No symbols defined for <I219> (keycode 219)
Warning:          No symbols defined for <I221> (keycode 221)
Warning:          No symbols defined for <I222> (keycode 222)
Warning:          No symbols defined for <I230> (keycode 230)
Warning:          No symbols defined for <I247> (keycode 247)
Warning:          No symbols defined for <I248> (keycode 248)
Warning:          No symbols defined for <I249> (keycode 249)
Warning:          No symbols defined for <I250> (keycode 250)
Warning:          No symbols defined for <I251> (keycode 251)
Warning:          No symbols defined for <I252> (keycode 252)
Warning:          No symbols defined for <I253> (keycode 253)
executed (nowait) qubes-desktop-run /usr/share/applications/org.gnome.Nautilus.desktop pid 1055
send exit code 0


sys-firewall:



X.Org X Server 1.18.0
Release Date: 2015-11-09
X Protocol Version 11, Revision 0
Build Operating System:  4.2.5-300.fc23.x86_64
Current Operating System: Linux sys-firewall 4.1.13-7.pvops.qubes.x86_64 #1 SMP Thu Dec 17 09:47:41 UTC 2015 x86_64
Kernel command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 3 nopat
Build Date: 16 November 2015  10:08:25AM
Build ID: xorg-x11-server 1.18.0-2.fc23
Current version of pixman: 0.33.4
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/user/.local/share/xorg/Xorg.0.log", Time: Mon Dec 21 20:42:09 2015
(++) Using config file: "/etc/X11/xorg-qubes.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Warning:          Key <OUTP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KITG> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIDN> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIUP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <RO> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I192> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I193> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I194> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I195> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I196> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I255> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <I149> (keycode 149)
Warning:          No symbols defined for <I154> (keycode 154)
Warning:          No symbols defined for <I168> (keycode 168)
Warning:          No symbols defined for <I178> (keycode 178)
Warning:          No symbols defined for <I183> (keycode 183)
Warning:          No symbols defined for <I184> (keycode 184)
Warning:          No symbols defined for <FK19> (keycode 197)
Warning:          No symbols defined for <FK24> (keycode 202)
Warning:          No symbols defined for <I217> (keycode 217)
Warning:          No symbols defined for <I219> (keycode 219)
Warning:          No symbols defined for <I221> (keycode 221)
Warning:          No symbols defined for <I222> (keycode 222)
Warning:          No symbols defined for <I230> (keycode 230)
Warning:          No symbols defined for <I247> (keycode 247)
Warning:          No symbols defined for <I248> (keycode 248)
Warning:          No symbols defined for <I249> (keycode 249)
Warning:          No symbols defined for <I250> (keycode 250)
Warning:          No symbols defined for <I251> (keycode 251)
Warning:          No symbols defined for <I252> (keycode 252)
Warning:          No symbols defined for <I253> (keycode 253)
** Message: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
vmware-user: could not open /proc/fs/vmblock/dev
Warning:          Key <OUTP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KITG> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIDN> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIUP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <RO> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I192> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I193> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I194> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I195> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I196> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <I255> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <I149> (keycode 149)
Warning:          No symbols defined for <I154> (keycode 154)
Warning:          No symbols defined for <I168> (keycode 168)
Warning:          No symbols defined for <I178> (keycode 178)
Warning:          No symbols defined for <I183> (keycode 183)
Warning:          No symbols defined for <I184> (keycode 184)
Warning:          No symbols defined for <FK19> (keycode 197)
Warning:          No symbols defined for <FK24> (keycode 202)
Warning:          No symbols defined for <I217> (keycode 217)
Warning:          No symbols defined for <I219> (keycode 219)
Warning:          No symbols defined for <I221> (keycode 221)
Warning:          No symbols defined for <I222> (keycode 222)
Warning:          No symbols defined for <I230> (keycode 230)
Warning:          No symbols defined for <I247> (keycode 247)
Warning:          No symbols defined for <I248> (keycode 248)
Warning:          No symbols defined for <I249> (keycode 249)
Warning:          No symbols defined for <I250> (keycode 250)
Warning:          No symbols defined for <I251> (keycode 251)
Warning:          No symbols defined for <I252> (keycode 252)
Warning:          No symbols defined for <I253> (keycode 253)
executed (nowait) qubes-desktop-run /usr/share/applications/org.gnome.Nautilus.desktop pid 1053
send exit code 0

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Output for both sys-usb and sys-firewall both started with yellow state
> according to VMM

I meant ~/.xsession-errors in dom0, I wasn't clear about that.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWeLpqAAoJENuP0xzK19csE/gH/2M1jqK+Fv7rLpLOFt/8PGa7
mgvmqq9WZTkAOFmgHTnX0Gy/G8TbRD+a5YKWEeM39O4P4u/GLkp0IocRyFZS3ZkS
gA2XMJ15GjjXXmV+exzigGg0KV2KQF+GMw9jIzjsVihYpHx6hCWYKccTLohXKP0+
Ov/nfHrsRNVmxyr1mCKsPIkbtbMLRNgI9/R17SASvwR2D6vtT/RF1pFYoh7cJDmA
RXZde7v5kY/tlyjRyXOXbE+gxfMRaFsBaQmnVVjB/QztdOs9SYl6gwKTQ+pJHs2a
9zVQPLQ6vP1ZRVyT0Cm6A+u/C4cSSf1Gy0MQFlDvhChWXt+B49GtTX/43rnqCCE=
=JoIb
-----END PGP SIGNATURE-----

[Tim W]

Sorry about that I should have known better.  thought it was odd.  Will do.

[Tim W]

Attached is the Dom0 .xsession-errors file


Cheers,

Tim

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Attached is the Dom0 .xsession-errors file

Found the problem with sys-firewall:

Running command on VM: 'sys-firewall'...
ERROR(sys-firewall): Domain 'sys-firewall': qrexec not connected.

but nothing about USB VM. Anyway it looks like login is allowed before
sys-firewall is fully started. Will try to find out why.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWeQ4HAAoJENuP0xzK19csfe8H/1AIs/ELSPX6tqpz/pviUZLm
sFbS5QFrTBsCyXVXiQu/T9fgXS9HSbr+hPxqgsp3MnVKx7jMgl8Wjck13EINHKf6
31PpftZndMWSc1PmoV2HKxpU84HtHL9+kPvj6G1C1K2g7QpaIWlScddNIJEONgTx
MxlnOp5PMl0Us1hSSABXHEw8M/RIWDX8f6VVCE+L49TqO3xw8jw1ikLiAxlMFB8k
B7f8uM1qaqkT7gywrwf6vIN0C22YBo6DuSwBbxX3utiQphSvAs5cZ1SPKEFZ1TYH
/dWMBA5L0VLQB4FmKinPfj4OHONkqwo0J3GUNOeVUE2hndowkC81hBVWp8HBuqI=
=dzKZ
-----END PGP SIGNATURE-----

[Tim W]

Great.  Glad you could find it.   

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Great. Glad you could find it.

It looks to be the same as this one:
https://github.com/QubesOS/qubes-issues/issues/1250

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWeXnlAAoJENuP0xzK19csvs4H/RO6j5MyypB5FPe0Td8s9ksI
DTCllXZ0K0y8NqxyOCWTBkxLx5rhvwhnCgjOq4xfKgu2VHZaWcBuyEgMBHPXXY+J
QTMG9txOvgdcdrGdGzf6CQlrB2PjzE0viOWRYOvUOVAutvqcdhZR1aOB2yoavIip
iU+0Rrkq4NeKIWVAICV27hNG9BMbri1R4wn1BZSDjCUYe2YawamW4NLJ0bt95rPo
XLfCOJaNGTlMWdQd3EGYFjOS1xGcKqebHyvD2AfPEgwKwEm95kfgx4BV5lnewKxR
marbW/HCv9b6N72DswCtsJGR9sDTdWRBInGCUhIWW57yCL4hvzc1V+bv8DG0VCg=
=2UYH
-----END PGP SIGNATURE-----

[Tim W]

yes that is basically it.  Also why I stated earlier that its something thats been around for a while.  At least in my experince its not been a large issue in that when a direct action is called from that vm it responds and works.  Maybe it causes more issues for others.  For me if its an easy fix great.....

[Cube]

On Tuesday, December 15, 2015 at 4:33:09 PM UTC-8, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Dec 15, 2015 at 04:18:55PM -0800, Cube wrote:
>
>
> > And the final error is still about "addproc"? If there is no other
> > message, I think it's time to go for --debug option. Be prepared to
> > receive A LOT of output.
> >
> >
> Yes, this IS the result of --debug :)

Ah, indeed...

> Anything else I can try?

Is that still error in "addproc"? If so, there is some error message there,
maybe much earlier...


- --

Thanks, finally tracked it down. Just did a backup of dom0 found a number of bogus files ...

.config/systemd/user
.kde/socket-dom0
home-prerestore/.../.config/systemd/user
 
It was being reported earlier as you said. Problem fixed for now, thanks so much.